Re: What is wrong with OO ?

[bs@research.att.com (Bjarne Stroustrup)]

jsa@alexandria (Jon S Anthony) writes:

 > 
 > In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:
 > 
 > > jsa@alexandria (Jon S Anthony) writes:
 > > 
 > > > Oh, I don't know.  I think C++ was created simply because BS was
 > > > saddled with C (at ATT) and wanted _something_ that had a least _some_
 > > > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
 > > > "usable" than several other options is highly open to question.  And
 > > > in fact, in general I would say the answer is "no".
 > > 
 > > It's not necessary to speculate on why Bjarne Stroustrup made the
 > > design decisions that he did: he discusses them, in a fair amount
 > > of detail, in _The Design and Evolution of C++_.
 > 
 > He also gave various descriptions of this process while it was
 > happening cira 87-89 and I happened to attend some of these.

What was happening circa 87-89 was the refinements of C++ version 2
(abstract classes, multiple inheritance, etc.) and beyond (templates,
exceptions, etc.). The initial work was much earlier (1979-1983).


 > > he was trying to create a language that, like C, made it possible to
 > > write low-level programs, but that also, like Simula, included
 > > high-level abstraction facilities.  
 > 
 > Exactly.  This came from his direct experience of having to recode a
 > Simula program for his thesis into BCPL.  The resulting nightmare was
 > not something he wished to have to go through again.  When getting to
 > ATT and seeing that it was C or nothing, he decided to "fix it" before
 > suffering the same experience.
 
This description is misleading on two counts:

(1)	I wanted something from both Simula and BCPL. Both have strengths
	and weaknesses relatively to my needs.

		Simula, had classes and a (much) stronger type system.

		BCPL had speed, easy porting of implementations, and the
		ability to easily cooperate with code fragments written
		in other languages (it was ``open'').

	The issue was not as simple as ``Simula was ideal except for
	efficiency concerns.'' That was the case for my Cambridge
	simulations, but not for the work I wanted to do later.

	The lessons I drew from my experiences in Cambridge was that I
	needed both sets of "good aspects" (and that there were "bad
	aspects" to both that I'd rather do without) NOT that one was
	strictly better than the other. This is documented in D&E and
	in papers written earlier than '87-'89. What I synthesized from
	my Cambridge rogramming experience was an initial set of criteria
	for a tool for higher-level systems programming.

(2) It was not "C or nothing" at AT&T. I was in a research organization
	that did not dictate what languages to use and several languages
	were used in various parts of AT&T at the time. The alternatives
	I knew of during the first years included C, Simula, Algol68, BCPL,
	Pascal, Modula-2, and Lisp. Naturally, I knew of more languages,
	but not every language I knew was an alternative for the work I
	was doing.

	I chose C because I rated it the best systems programming language
	at the time. It had obvious flaws, but I rated them secondary and
	manageable, whereas I considered the other alternatives to have
	more fundamental flaws relative to my needs. Being in THE hotbed
	of C at the time of course helped me appreciate the strengths of
	C and taught me how the experts compensated for its weaknesses,
	but that is a far cry from "C or nothing."


Why is any of this relevant now? Why do I bother with this debate on
"innovation?" Because some of what is said related directly to what C++
is and should be, and that again affects where it is reasonable to use
it and how it is best used. If you misunderstand some of the fundamentals
of a language, the code you write in it is going to be suboptimal in several
ways.
	
	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html