On the 1st of January, 1998, Bjarne Stroustrup gave an interview
to the IEEE's 'Computer' magazine..
Naturally, the editors thought he would be giving a retrospective
view of seven years of object-oriented design, using the language
he created.
By the end of the interview, the interviewer got more than he had
bargained for and, subsequently, the editor decided to suppress its
contents, 'for the good of the industry' but, as with many of these
things, there was a leak..
Here is a complete transcript of what was was said, unedited, and
unrehearsed, so it isn't as neat as planned interviews..
You will find it interesting....
__________________________________________________________________
Interviewer: Well, it's been a few years since you changed the
world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before
you arrived. Do you remember? Everyone was writing 'C'
and, the trouble was, they were pretty damn good at it..
Universities got pretty good at teaching it, too. They were
turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate. That's what caused the
problem..
Interviewer: Problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like
demi-gods. Their salaries were high, and they were treated
like royalty..
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and
invested millions in training programmers, till they were a
dime a dozen..
Interviewer: That's why I got out. Salaries dropped within a year,
to the point where being a journalist actually paid better..
Stroustrup: Exactly. Well, the same happened with 'C' programmers..
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I
thought of this little scheme, which would redress the
balance a little. I thought 'I wonder what would happen, if
there were a language so complicated, so difficult to learn,
that nobody would ever be able to swamp the market with
programmers? Actually, I got some of the ideas from X10,
you know, X windows. That was such a bitch of a graphics
system, that it only just ran on those Sun 3/60 things..
They had all the ingredients for what I wanted. A really
ridiculously complex syntax, obscure functions, and
pseudo-OO structure. Even now, nobody writes raw X-windows
code. Motif is the only way to go if you want to retain
your sanity..
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem..
Unix was written in 'C', which meant that any 'C' programmer
could very easily become a systems programmer. Remember
what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do..
Stroustrup: OK, so this new language had to divorce itself from
Unix, by hiding all the system calls that bound the two
together so nicely. This would enable guys who only knew
about DOS to earn a decent living too..
Interviewer: I don't believe you said that....
Stroustrup: Well, it's been long enough, now, and I believe most
people have figured out for themselves that C++ is a waste
of time but, I must say, it's taken them a lot longer than I
thought it would..
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought
people would take the book seriously. Anyone with half a
brain can see that obkect-oriented programming is
counter-intuitive, illogical and inefficient..
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear
of a company re-using its code?
Interviewer: Well, never, actually, but....
Stroustrup: There you are then. Mind you, a few tried, in the
early days. There was this Oregon company - Mentor
Graphics, I think they were called - really caught a cold
trying to rewrite everything in C++ in about '90 or '91. I
felt sorry for them really, but I thought people would learn
from their mistakes..
Interviewer: Obviously, they didn't?
Stroustrup: Not in the slightest. Trouble is, most companies
hush-up all their major blunders, and explaining a $30
million loss to the shareholders would have been difficult..
Give them their due, though, they made it work in the end..
Interviewer: They did? Well, there you are then, it proves O-O
works..
Stroustrup: Well, almost. The executable was so huge, it took
five minutes to load, on an HP workstation, with 128MB of
RAM. Then it ran like treacle. Actually, I thought this
would be a major stumbling-block, and I'd get found out
within a week, but nobody cared. Sun and HP were only too
glad to sell enormously powerful boxes, with huge resources
just to run trivial programs. You know, when we had our
first C++ compiler, at AT&T, I compiled 'Hello World', and
couldn't believe the size of the executable. 2.1MB
Interviewer: What? Well, compilers have come a long way, since
then..=
Stroustrup: They have? Try it on the latest version of g++ - you
won't get much change out of half a megabyte. Also, there
are several quite recent examples for you, from all over the
world. British Telecom had a major disaster on their hands
but, luckily, managed to scrap the whole thing and start
again. They were luckier than Australian Telecom. Now I
hear that Siemens is building a dinosaur, and getting more
and more worried as the size of the hardware gets bigger, to
accommodate the executables. Isn't multiple inheritance a
joy?
Interviewer: Yes, but C++ is basically a sound language..
Stroustrup: You really believe that, don't you? Have you ever sat
down and worked on a C++ project? Here's what happens:
First, I've put in enough pitfalls to make sure that only
the most trivial projects will work first time. Take
operator overloading. At the end of the project, almost
every module has it, usually, because guys feel they really
should do it, as it was in their training course. The same
operator then means something totally different in every
module. Try pulling that lot together, when you have a
hundred or so modules. And as for data hiding. God, I
sometimes can't help laughing when I hear about the problems
companies have making their modules talk to each other. I
think the word 'synergistic' was specially invented to twist
the knife in a project manager's ribs..
Interviewer: I have to say, I'm beginning to be quite appalled at
all this. You say you did it to raise programmers'
salaries? That's obscene..
Stroustrup: Not really. Everyone has a choice. I didn't expect
the thing to get so much out of hand. Anyway, I basically
succeeded. C++ is dying off now, but programmers still get
high salaries - especially those poor devils who have to
maintain all this crap. You do realise, it's impossible to
maintain a large C++ software module if you didn't actually
write it?
Interviewer: How come?
Stroustrup: You are out of touch, aren't you? Remember the typedef?
Interviewer: Yes, of course..
Stroustrup: Remember how long it took to grope through the header
files only to find that 'RoofRaised' was a double precision
number? Well, imagine how long it takes to find all the
implicit typedefs in all the Classes in a major project..
Interviewer: So how do you reckon you've succeeded?
Stroustrup: Remember the length of the average-sized 'C' project?
About 6 months. Not nearly long enough for a guy with a
wife and kids to earn enough to have a decent standard of
living. Take the same project, design it in C++ and what do
you get? I'll tell you. One to two years. Isn't that
great? All that job security, just through one mistake of
judgement. And another thing. The universities haven't
been teaching 'C' for such a long time, there's now a
shortage of decent 'C' programmers. Especially those who
know anything about Unix systems programming. How many guys
would know what to do with 'malloc', when they've used 'new'
all these years - and never bothered to check the return
code. In fact, most C++ programmers throw away their return
codes. Whatever happened to good ol' '-1'? At least you
knew you had an error, without bogging the thing down in all
that 'throw' 'catch' 'try' stuff..
Interviewer: But, surely, inheritance does save a lot of time?
Stroustrup: Does it? Have you ever noticed the difference between
a 'C' project plan, and a C++ project plan? The planning
stage for a C++ project is three times as long. Precisely
to make sure that everything which should be inherited is,
and what shouldn't isn't. Then, they still get it wrong..
Whoever heard of memory leaks in a 'C' program? Now finding
them is a major industry. Most companies give up, and send
the product out, knowing it leaks like a sieve, simply to
avoid the expense of tracking them all down..
Interviewer: There are tools.....
Stroustrup: Most of which were written in C++..
Interviewer: If we publish this, you'll probably get lynched, you
do realise that?
Stroustrup: I doubt it. As I said, C++ is way past its peak now,
and no company in its right mind would start a C++ project
without a pilot trial. That should convince them that it's
the road to disaster. If not, they deserve all they get..
You know, I tried to convince Dennis Ritchie to rewrite Unix
in C++..
Interviewer: Oh my God. What did he say?
Stroustrup: Well, luckily, he has a good sense of humor. I think
both he and Brian figured out what I was doing, in the early
days, but never let on. He said he'd help me write a C++
version of DOS, if I was interested..
Interviewer: Were you?
Stroustrup: Actually, I did write DOS in C++, I'll give you a demo
when we're through. I have it running on a Sparc 20 in the
computer room. Goes like a rocket on 4 CPU's, and only
takes up 70 megs of disk..
Interviewer: What's it like on a PC?
Stroustrup: Now you're kidding. Haven't you ever seen Windows '95?
I think of that as my biggest success. Nearly blew the game
before I was ready, though..
Interviewer: You know, that idea of a Unix++ has really got me
thinking. Somewhere out there, there's a guy going to try
it..
Stroustrup: Not after they read this interview..
Interviewer: I'm sorry, but I don't see us being able to publish
any of this..
Stroustrup: But it's the story of the century. I only want to be
remembered by my fellow programmers, for what I've done for
them. You know how much a C++ guy can get these days?
Interviewer: Last I heard, a really top guy is worth $70 - $80 an
hour..
Stroustrup: See? And I bet he earns it. Keeping track of all the
gotchas I put into C++ is no easy job. And, as I said
before, every C++ programmer feels bound by some mystic
promise to use every damn element of the language on every
project. Actually, that really annoys me sometimes, even
though it serves my original purpose. I almost like the
language after all this time..
Interviewer: You mean you didn't before?
Stroustrup: Hated it. It even looks clumsy, don't you agree? But
when the book royalties started to come in... well, you get
the picture..
Interviewer: Just a minute. What about references? You must
admit, you improved on 'C' pointers..
Stroustrup: Hmm. I've always wondered about that. Originally, I
thought I had. Then, one day I was discussing this with a
guy who'd written C++ from the beginning. He said he could
never remember whether his variables were referenced or
dereferenced, so he always used pointers. He said the
little asterisk always reminded him..
Interviewer: Well, at this point, I usually say 'thank you very
much' but it hardly seems adequate..
Stroustrup: Promise me you'll publish this. My conscience is
getting the better of me these days..
Interviewer: I'll let you know, but I think I know what my editor
will say..
Stroustrup: Who'd believe it anyway? Although, can you send me a
copy of that tape?
Interviewer: I can do that..
-Who knows what evil lurks in the hearts of Men?-
__________________________________________________________________
AND - From The RISKS Forum November 4th 1999
Complexity in operating systems and programming languages
Diomidis Spinellis
Mon, 18 Oct 1999 12:02:11 +0300
A number of contributors to previous digests have stressed the risks
associated with increasingly bloated software applications. Unfortunately
the same issues permeate a number of facets of the software industry.
Consider operating systems and programming languages which are becoming
increasingly complicated and their implementations less trustworthy. The
following table [1] contains the number of documented system calls for some
popular Un*x system versions:
Operating System Year Number of
system calls
First Edition Unix 1971 33
Seventh Edition Unix 1979 47
SunOS 4.1 1989 171
4.3 BSD Net 2 1991 136
HP-UX 9.05 1992 219
SunOS 5.4 1994 163
Linux 1.2 1996 211
SunOS 5.6 1997 190
Linux 2.0 1998 229
The Windows platform with 3433 API calls (up to NT4 SP3) belongs to a
different league; the associated problems are documented elsewhere [2].
A system call defines an interface to the operating system; more system
calls increase the complexity of the operating system needed to support
them, provide additional opportunities for unwanted interactions between
them, and increase the chances of overlooked security loopholes.
This increasing complexity has important implications for the reliability of
software developed for a specific platform. Complicated interfaces are
difficult to learn and use effectively. As a result of their size and
complexity, modern operating systems exhibit an increasing number of bugs;
demonstrated by the numerous "fixes" distributed by their vendors.
Developers of robust applications have to take this into account coding
around them, or insist on the installation of all relevant fixes. Some
fixes may introduce new errors or render other system components
inoperative. The bottom-line of this situation is, that the application
developer is practically rarely singly responsible for the reliability of an
application.
Similarly to operating systems, programming languages also have a tendency
to grow in size and complexity as they mature. Taking as a rough measure the
page number of the language's canonical description the following table
provides an illustration of the evolution of the C and C++ programming
languages:
Book Title Year Pages
The C Programming Language (Kernighan and Ritchie) 1978 228
The C Programming Language; second edition 1988 272
The C++ Programming Language (Stroustrup) 1986 328
The C++ Programming Language; second edition 1991 669
The C++ Programming Language; third edition 1997 910
This trend has important implications for the developers of high-reliability
systems. Large languages are difficult to learn and use [3]. It is nowadays
not uncommon for programming teams to lack people who understand the whole
language at a level sufficient to advise other members on issues regarding
the interrelationship between language elements. Subtle bugs arising from
the misunderstanding of language features can thus survive code
walkthroughs. In addition, language complexity and advanced optimisation
techniques combined with processor complexity results in an increased number
of bugs in modern compilers. This is clearly an additional risk factor for
high-reliability designs.
[1] Diomidis Spinellis. Software reliability: Modern challenges. In G.
I. Schueller and P. Kafka, editors, Proceedings ESREL 1999 - The Tenth
European Conference on Safety and Reliability, pages 589-592,
Munich-Garching, Germany, September 1999. ESRA, VDI, TUM, A. A. Balkema.
[2] Diomidis Spinellis. A critique of the Windows application
programming interface. Computer Standards & Interfaces, 20:1-8, November 1998.
[3] C. A. R. Hoare. Hints on programming language design. In Ellis
Horowitz, editor, Programming Languages: A Grand Tour, pages 31-40.
Computer Science Press, 1983. Reprinted from Sigact/Sigplan Symposium on
Principles of Programming Languages, October 1973.
Diomidis Spinellis, University of the Aegean