Bjarne Stroustrup, creator of C++, delivered the 20th Donald B. Gillies Memorial Lecture on March 25. After first giving a technical talk on the standard C++ library, Stroustrup presented "Programming Languages--Why Should We Care" to a packed house of over 200 people. Stroustrup discussed the role of programmers and programming languages, the origins, aims, and design rules for C++, and the key language features of C++ and the design and programming techniques they support.
Stroustrup is the designer and original implementer of C++ and the author of several books on the subject. He received his Cand. Scient. in mathematics and CS in 1975 from University of Aarhus, Denmark, and his PhD in computer science in 1979 from Cambridge University. His adviser was David Wheeler, who was on the DCL faculty at Illinois from 1951-53 and was a programmer for ILLIAC I.
Stroustrup currently heads AT&T Bell Labs Large-scale Programming Research department and is a Bell Laboratories Fellow. In 1993, he received the ACM Grace Hopper award and is a Fellow of ACM as well. He lives in Watchung, New Jersey, with his wife and two children. This was Stroustrup's second visit to Illinois. The first was five years ago when he spoke to the Choices research group headed by Professor Roy Campbell. Choices is an object-oriented operating system developed by that group and written in C++.
I had the following conversation with Bjarne Stroustrup shortly before he gave his talk on programming languages.
--Judy Tolliver, editor
Did your involvement with object-oriented programming start in
Aarhus?
Sort of. I mean, I went to university in Aarhus, which was also
my hometown, so that's nice. I tried Simula for a couple of weeks at Aarhus when
I was an undergraduate. Then several years later, I was in Cambridge trying to
get a PhD. And I recognized that I needed a tool and Simula was a good tool for
it, so there I then learned Simula properly. I was trying to simulate a
distributed operating system, trying to distribute services over a network of
computers. I wanted to simulate the kind of different performances and different
strategies for composing systems, different kinds of networking, and shared
memory kind of architectures, trying to figure out how high-level systems could
be supported by lower level architectural things. And those simulations could be
very well designed and implemented in Simula, or so I thought. My early
education in Aarhus taught me what a plausible tool was, and then I just picked
up the tool and in the end it helped with the design, but it couldn't do the
implementation. It was too expensive, so I had to translate it to a lower level
language.
Then when I came to Bell Labs in 1979 and I needed to build some systems. I knew both the strengths of the Simula approach--strongly typed, object-oriented programming and design. I also knew the weaknesses of the Simula approach which were that it simply ran too slow, it was too cumbersome, it couldn't interact well with other software, and it wasn't effective for systems level programming. And so I tried to take the strength of Simula in terms of type system and object-oriented programming and object-oriented design and marry it with the strengths of C which was that it could interact with lots of other software, it was open, and it was good for systems level work. And it was efficient, and that was the origin of the thing.
Aarhus gave me some idea of what Simula could do, and Cambridge gave me the experience and the real learning of those ideas and what were the weaknesses of the approach. And the next step was to actually use that experience to build the first version of C++.
Was the first version built for something specifically within Bell
Labs?
Basically, yes. I was in the business of helping people design
various things: network protocols, board layout, things that require simulation.
And so the early uses--my bread and butter for years--were simulation programs
for help with designs: Trying to figure out buffering capacities in networks,
trying to figure out the behavior of certain networks under saturation
conditions, trying to symbolize board layout by minimizing communication
courses, things like that. That was the call. Then there were lots of other
things because, as it turns out, C++, or C with Classes as it was called in the
early days, was useful for lots more things than its original purpose.
Why did you call it C++?
C with Classes was quite descriptive
because it was C and it had the Class concept from Simula. The point was,
however, that people dropped the word classes because it was such a long name,
so they called it C, which was all right with me. But then they started calling
C Old C or Straight C or Plain C, so I had to find another name, not to be
insulting. And I had a little competition, with me as judge and jury, and I
picked C++, because ++ is the increment operator in C, so in C, C++ means Next
Successor Add 1, things like that, so it's just a programmer's joke.
Since new languages are so hard for people to accept, how come C++ became
accepted as readily as it did, and what did you do to try to get people to use
it?
It's hard to say, really. It's sort of culturally compatible with C.
You can go relatively easy from C to do some of the less radical parts of C++,
and that helps. It is also much more efficient than anything that can do similar
things much better. It's used very simply: If you want to write object-oriented
code, if you want to write highly abstract code, you can use C++ or you can run
ten times slower. That was very important. So were the compatibility with C and
the efficiency. Also, it wasn't specialized. It was just a language, it could
fit in on any computer, you didn't have to use any particular Windows system, or
database system. If you wanted to write system level code, you could do it! And
what I did was I explained to people what it was, I didn't hype it. I also
explained what it couldn't do. I explained very carefully to people what I
didn't promise people, and I think that was important.
So first it was accepted within Bell Labs, and then...
And then it
spread. It spread rather fast. It was worldwide in very small pockets well
before it was called C++. I was asked by the ACM to write a paper on the history
of C++ a couple of years ago and so I researched it again. It spread rather fast
and rather wide. People liked it. It was easy to prove you could get some
benefits from it, and if you worked a bit harder at it, you could get more
benefits. It can be learned incrementally, it can be used incrementally, and
basically your benefits are at least proportional to the effort, as opposed to
having to understand everything first before you can start.
Are you still developing C++?
No, we're just finishing the
international standard for it. That's sort of the end of it as far as I'm
concerned.
There's no next big thing then?
No, I don't want to. It's been too
much and too long. But I think one thing I would like to emphasize here. There
are two theories for how C++ succeeded which are just plain false. The first is
that it succeeded simply because it was first. And it wasn't. Simula was there.
Smalltalk was there. Objective C was there. Eiffel was there, and so was the
Object-Oriented Pascal. It was one of a group, and there were actually several
that were before that. It was not because I was first. Secondly, it is not
because of the marketing might of AT&T. We spent $3,000 popularizing it and
marketing for the first three years when it was commercially available.
I've never seen TV commercials for it.
No, no. I have seen a
magazine ad for it, but that came four years after it was commercially marketed.
We literally only spent three or four thousand dollars in three years! The hype
came when somebody else actually bought the idea and then started trying to make
money off it. It was a grass roots thing.
With the AT&T break up, are projects like this going to go
on?
A lot of things will go on. It's a difficult times for fundamental
research anywhere, from the universities to software engineering. So these are
rough times in general, but research will go on, and what I'm doing here has
always been research with a small "r." Always trying to serve a user community
well. Trying to get fundamental ideas--which I don't claim to be mine. I
borrowed most of my great ideas from Simula with acknowledgment. Trying to
actually engineer them and popularize them and get them into real use. There
never was a C++ project. It was just me building some tools and helping some
people design networks and things like that. It just grew up out of a need and
out of some ideas for fulfilling that need. It was only much later that there
was a project. C++ was not the result of a planned, large, budgeted project. The
first commercial C++ release also was by an order of magnitude the cheapest
product ever produced by Bell Labs.
Do you have any opinion on Java?
Not really. I have one severe
problem. Each time I try to run it on my Sun, it freezes my X server, and I
cannot execute it. It that's security, then it's very secure, because no one can
do anything to my machine when it's using Java.
Java is being hyped as the next generation of--
The next generation
of what?
--Of C++.
Well they claim it to be better than all other languages
in all possible ways, and it's plainly not. It may have a role in the Web and
networking, but that depends on whether they can keep it secure. And as it looks
now, it doesn't look all that secure to me. But we'll see. I think it is not a
language issue or a language design issue, it is a systems and security issue.
And my feeling is that most people up till now just pretend there are no
security problems.
I wanted to ask you about the software crisis. With millions and millions
of lines of code, how can you write a bug-free program and be able to prove that
it's bug-free?
First of all you can't.
Should you even bother?
Well you should try. You try the best you
can. I mean, you can't prove that a car won't crash either, but it doesn't stop
us from having cars. But what you want to do with the software crisis is not
eliminate it because you can't. You'd have the whole earth's population trying
to make error free programs. What you want is to make them more and more error
free and spend disproportional effort on life-critical things. You can write
very reliable programs. When I hear about people programming pacemakers in C++ I
get sort of nervous, but on the other hand, I'd get sort of nervous
independently of which language they were programming in. The idea of pacemakers
and heart monitors and wing tips of airplanes being controlled by processors
should make anybody a bit uneasy, and it should increase the effort of
verification and all the techniques we've got. I mean, we're not helpless. It's
just difficult and expensive.
The Denver airport is a big example of a failed plan...
Well, the
way I've heard it, they had two companies bidding. One said it would take x
years and y dollars, and the other said it would take 2x years and 2.something
dollars, that is, twice the time and more than twice the cost, and they decided
to go with the first company. Not only were they cheaper and faster, but they
were also American. The other company, however, had built such a system before,
and it did take slightly more than 2x times and cost slightly more than 2y
dollars. I think what we saw here was the effect of the procurement process and
the effect of politics. If you want something cheap and fast, you'll get
something cheap and fast. And I think they got exactly what they asked for. They
just didn't want to believe that the problem was as hard as it was.
If you have hundreds of programmers working on one big program, how do you manage that? With great difficulty. First of all, we do it and it works. Two it's too cumbersome, unpleasant and expensive. I think we need a combination of better design techniques, better languages and better management. There are several ideas for the language parts, C++ is one of them. There are better ways of designing programs: object-oriented programming in the more general sense is part of that problems, and I think management is too prone to oversimplify solutions.
Take the movie industry, for example. They don't pretend everyone's the same. Actors act. Cameramen run cameras. Lighting specialists do lighting. I think within the design and programming, we actually probably need more specialization and more cooperation. There's too much emphasis on fitting people into a few rigid categories. Programmers are like this, and you want to get an ANSI standard programmer. And you want to pay him an ANSI standard wage. And you get an analyst who wears a tie and does specifically that. You need to have a much more flexible set of roles, and you have to realize that even within the programming area, people vary. And people measure productivity of programmers and it varies by a factor of ten within a small group very regularly and sometimes by a factor of 100.
The people who manage programmers-- are they themselves
programmers?
Sometimes they are, but when they are they quite often did
their programming fifteen years ago and are a bit out of touch. It is very hard.
It is a very immature discipline, and it has to not only mature, but it has to
mature on its own conditions, not in simple imitation of, say, hardware design.
Software is different and difficult. So we need to look into it. I mean, my job
title is head of large-scale programming research, and if I thought we knew how
to do it, that wouldn't be a research topic, right? So, I'm looking into it; I
think I have some ideas. But I know full well that this is not a mature
engineering discipline. This is difficult--difficult like in research.
How do we teach all this stuff? This field has spread out into so many
different areas, it's impossible to teach everything to every student.
We
do not know how to specialize yet. A lot of attempts to specialize have left out
critical parts that are needed to do a job well.
It probably needs to be a five- or six-year program or something. But then by the time you graduate, the stuff you learned early on would probably be obsolete. Of course it would, but the observation in Denmark was that the traditional degrees took 5.5 to 6.5 years. They would not let you out; they would not consider you a functioning professional in less than 5.5 years. My master's degree took 6.5 years. I was the youngest computer scientist ever in Denmark for about two weeks, until all my friends graduated. But it took that long. And they tried to introduce a bachelor's program and it completely flopped. I think they abandoned the bachelor degree again. This was a novelty. They were trying to use the Anglo-Saxon system, and they just couldn't produce people with sufficient knowledge and skills to be used in industry.
What was your bachelor's in?
I don't have one. This is standard
Danish practice. No bachelors. It is not a useful concept in the science and
engineering disciplines. I have a Candidate of Science--it's like a rather
massive master's degree. But tradition there was that you couldn't build an
engineer or a scientist or good functioning professional in the sciences in less
than 5.5 years. And they did a serious experiment--I mean serious meaning that
the government didn't want to pay for it and all the power of the government and
all the pressure of the European Union and all the Presidents from the U.S. and
England--they tried to build a four-year program to produce something useful in
those fields. It worked more or less in the arts, but it didn't work in the
sciences. It had withered.
So you feel that the Danish system is better?
I think that trying
to produce a good engineer or good scientist in four years is a loser. All the
good ones have to have a master's anyway, and it's going to take them two years
more. Why not realize it? It's probably not feasible bureaucratically here, but
that's as long as it takes, so you find everyone takes a master's that actually
wants to stay in the field.
So getting a PhD in Denmark is not very common?
It's getting more
common now, but it used to be very unusual. I could not have gotten a PhD in
Denmark, it was unheard of. That's why I went to Cambridge. There are a lot of
computer professionals--good ones--for the population. It is very competitive.
There are lots of Danes abroad for that reason. But the system runs at a profit.
If you look at it, the country is doing well. It cannot absorb all the people it
educates, but it ends up exporting some people for that reason. The system
works--we're running a full welfare state at a profit and the current account
surplus per person is roughly equal to that of Japan.
Are you ever tempted to go back?
Yes. I get homesick a lot. I've
lived in Denmark, I've lived in England, I've lived in the States. I can get
homesick for several places at once. It's very confusing. My wife and kids don't
speak Danish. My wife's English and it's very hard to learn a language that's
not your mother's.
Thanks.
After the interview, Stroustrup told me a funny story about Greg Chesson,
PhD'77. (Chesson, who brought UNIX to Illinois while he was a student, is chief
scientist at SGI.) About ten years ago, during a Usenix conference, Chesson was
chair of a session, and in that capacity was responsible for chasing people off
the stage when their time was up. He did this by playing some notes on the grand
piano in the back. "There was a speaker who was running badly over time,"
related Stroustrup, "and he was going on and on about how wonderful the world
was going to be with something or another. Chesson started playing ÔBeautiful
Dreamer,' and the hall collapsed!"
Comments to: alumni@cs.uiuc.edu