Winter 96 Index     Main Index

A conversation with Bjarne Stroustrup, Gillies lecturer and inventor of C++

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