You certainly wouldnt be immune from this in Java for example. If you needed anything more than the default shallow copying of references, then you have to provide a clone() method. If your class was responsible for managing a resource then you'd provide a dispose() or close() method.

The vast majority of the need for writing copy ctors and op= involves sorting out ownership. In a GC system like Java, this problem vanishes. C++ Example:

class Foo { Something* _c; public: Foo(Something* c) : _c(c){} ~Foo() { delete _c; }}

Inadvertent copying of Foo (inadvertent copying in C++ happens a *lot*) will result in a double free.

You can fix this using a reference counting pointer - but that typically requires additional support in the class you are counting and if its not your class you're stuck.

"Although in Python I tend to write in a structured design style, not an OO style"
Now you are making me curious ;-)
Why is it that you tend to program in a structured style with Python?

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

The paper on generics is available at http://www.osl.iu.edu/publications/pubs/2003/comparing_generic_programming03.pdf and the code is available here http://www.osl.iu.edu/research/comparing/ . I would be very interested in seeing a Smalltalk version of this library which is more compact and elegant than the BGL.

[snip]

> > If you have an online pointer to the paper in question,
> I
> > would be interested in seeing it.
>
> OOPSLA 2003 Garcia, et al: A comparative study of language
> support for generic programming. pp 115-134.
>
> I don't know if it's online.
>

It seems to be available here:

http://www.osl.iu.edu/publications/pubs/2003/comparing_generic_programming03.pdf

Google cache for this paper:

http://www.google.com/search?q=cache:CNwEcvMa0lcJ:www.osl.iu.edu/publications/pubs/2003/comparing_generic_programming03.pdf+%22+A+comparative+study+of+language+support+for+generic+programming%22&hl=en&ie=UTF-8

The paper is in my read list so I can't comment on it. But after skimming through the examples and the conclusions it seems that the authors have some bias toward C++, as they try use the C++ solution to the problem to every other language.

IMHO it would be better to present a problem to different groups using different languages and see they implementing it. This approach was used in "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity" (available at http://citeseer.nj.nec.com/hudak94haskell.html). In this paper the Naval Surface Warfare Center (NSWC) required a prototype for a Geometric Region Server from ten different groups (contractor and academics). The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The resukts are shown below:

Language               LOC  L. of doc.  Dev. time (hours)
(1) Haskell             85     465         10
(2) Ada                767     714         23
(3) Ada9X              800     200         28
(4) C++               1105     130          –
(5) Awk/Nawk           250     150          –
(6) Rapide             157       0         54
(7) Griffin            251       0         34
(8) Proteus            293      79         26
(9) Relational Lisp    274      12          3
(10) Haskell           156     112          8

An interesting fact is that the tenth program was written by a newly hired college graduate with no experience in Haskell, other than a previous ten-day self study of the Haskell Report.

We could also use the sources for each ICFP available, as several different languages are used to solve the same problem, each using a different design.

There's also a relevant paper called "DSL Implementation in MetaOCaml, Template Haskell, and C++", comparing meta-programming techniques in the three languages.

http://www.cs.rice.edu/~taha/publications/preprints/2003-12-01.pdf


> The old short study, which I do not have a reference to,
> ws by Tom Love (of Stepstone fame).
>
> -- Bjarne Stroustrup: http://www.research.att.com/~bs

Best regards,
Daniel Yokomizo.