|
Re: Elegance and Other Design Ideals
|
Posted: Feb 26, 2004 3:27 PM
|
|
> > When Bjarne made the claim in the interview, I imagined > him to be talking more about algorithms than program > infrastructure. Bjarne, you can correct me if I was wrong > about that. So for example, looking at what code -- the > while loops and for loops and data structures -- it would > take to implement an algorithm that does something > specific.
If I remember correctly, I was thinking of programs written with adequate support from modern libraries. One related thing that I sometimes mention is that "In the language itself, just about anything is hard; with a suitable library, just about anything becomes easy - that's true for any language". Obviously, the distinction between "the language" and "a library" is sharper in some languages than in others.
> I can't remember who said this and in what context, but > somewhere I heard someone talking about how it is ironic > that the bigger the language, the smaller the code in that > language. In other words, the more features a language has > in it, the more ways a programmer can say what needs to be > said -- including possibly a very succinct way -- so and > the smaller the programmer can make the code. I thought it > was Matz who said this about Ruby in his interview, but I > can't find it. Regardless, C++ has a lot of features, and > perhaps that helps make code shorter.
There's something to that. For example, a C++ class offers support for both value types and object types. If you think all types should be object types (or conversely that all types should be value types), you'll find C++'s support overelaborate. However if you write a program that uses both kinds, say a complex number type and a graphics hierarchy, the support in C++ will favor users compared to users of a language that supports only the one or the other. Obviously, my opinion is that most programs can benefit from both kinds of types.
> After one of Bjarne's talks at the JAOO conference where > we did the interview, someone in the audience asked Bjarne > about readability. And Bjarne's answer was that many > people confuse readability with familiarity.
I think that's a separate issue. I think "shorter" is a fairly objective notion.
> Languages that enable more > terse code probably also assume the readers of the code > are going to have spent more effort becoming familiar with > all the various aspects of the language.
Maybe, but complex z2 = z2*4+z4; is readable without any training (in programming) - even if the code implementing the complex library is not.
> I'm curious, Bjarne, if you were talking about C++ > compared to scripting languages like Ruby and Python and > Perl, or just C++ compared to systems languages like Java > and C# and Eiffel. And if it is more about comparing just > the algorithms versus an entire application. Because my > experience is that at the application level, Java was less > verbose than C++, and Python is less verbose than Java. > Although in Python I tend to write in a structured design > style, not an OO style, so it is kind of an apples to > oranges comparison. Whereas I have built the same kind of > OO sytems in Java that I used to do in C++. That said, I > was programming in C++ long before the STL, so I was not > using a modern C++ style.
I was thinking about languages such as C, C++, Java, and C#. The OOPSLA paper that I referred to elsewhere considered ML, Haskell, C++, etc. and C# and java extended with generics. The old OOPSLA experiment included languages that were popular 10 years ago, such as Smalltalk, Objective C and C++.
I did not think of scripting languages as such. They have an inherent advantage from requiring less "boiler plate", though C++ comes out pretty well give the STL, a regular expression library (e.g. see boost).
I did a course on distributed computing using Java, C#, and C++. I found C++ on average shorter on the algorithmic and data representation parts, but - as for all single person comparisons - that could simply have been my greater experience with C++.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
|
|