From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: bs@research.att.com (Bjarne Stroustrup) Subject: Re: What is wrong with OO ? Date: 1997/01/11 Message-ID: #1/1 X-Deja-AN: 209750893 references: organization: AT&T Research, Murray Hill, NJ, USA newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-11T00:00:00+00:00 List-Id: jsa@alexandria (Jon S Anthony) writes: > > In article Matt Austern 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