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
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