Bjarne Stroustrup: Journey to C++ from Fortran, Algol, Simula, and C

And what was the first programming language, if I may ask it this way, that you fell in love with?

I think I'll call 60. And after that, I remember Snowball, I remember Fortran didn't fall in love with that. I remember Pascal didn't fall in love with that. It all got in the way of me. And then I discovered assembler and that was much more fun. And from there I went to microcode.

So you were drawn to the. You found the low level stuff beautiful.

I went through a lot of languages and then I spent significant time in assembler and microcode. That was sort of the first really profitable things. And I paid for my master's actually. And then I discovered Simula, which was absolutely great.

Simula.

Simula was the extension of Algol 60, done primarily for simulation, but basically they invented object oriented programming at inheritance and runtime polymorphism while they were doing it. And that was the language that taught me that you could have the sort of the problems of a program grow with size of the program rather than with the square of the size of the program. That is, you can actually modularize very nicely. And that was a surprise to me. It was also a surprise to me that a stricter type system than Pascal's was helpful, whereas Pascal's type system got in my way all the time. So you need a strong type system to organize your code well, but it has to be extensible and flexible.

Let's get into the details a little bit. If you remember, what kind of type system did Pascal have? What type system typing system did Algol 60 have?

Basically, Pascal was one of the simplest language that Nikolaus Wirk could define, that served the needs of Nikolas Viet at the time. And it has a sort of a highly moral tone to it. That is, if you can say it in Pascal, it's good, and if you can't, it's not so good. Whereas Simula allowed you is basically to build your own type system. So instead of trying to fit your yourself into Niklaus Wirz's world, Christ Nugol's language and language allowed you to build your own. So it's sort of close to the original idea of you build a domain specific language. As a matter of fact, what you build is a set of types and relations among types that allows you to express something that's suitable for an application.

So when you say types, the stuff you're saying has echoes of object oriented programming.

Yes, they invented it. Every language that uses the word class for type is a descendant of Simula directly or indirectly. Kristen Nygo and Ol Johandahl were mathematicians and they didn't think in terms of types. They. But they understood sets and classes of elements. And so they called their types classes. And basically in C, as in simuli, classes are user defined type.

So can you try the impossible task and give a brief history of programming languages from your perspective? So we started with Algol 60, Simula, Pascal, but that's just the 60s and.

70S I can try. The most sort of interesting and major improvement of programming languages was Fortran, the first Fortran, because before that all code was written for a specific machine, and each specific machine had a language, a simply language or, or some extension of that idea. But you are writing for a specific machine in the language of that machine. And Bachus and his team at IBM built a language that would allow you to write what you really wanted. That is, you could write it in a language that was natural for people. Now these people happen to be engineers and physicists, so the language that came out was somewhat unusual for the rest of the world. But basically they said formula translation because they wanted to have the mathematical formulas translated into the machine. And as a side effect they got portability because now they are writing in the terms that the humans used and the way humans thought. And then they had a program that translated it into the machine's needs. And that was new and that was great. And it's something to remember. We want to raise the language to the human level, but we don't want to lose the efficiency.

And that was the first step towards the human.

That was the first step. And of course there were very particular kind of humans, business people were different, so they got Cobol instead, et cetera, et cetera. And Simula came out, no, let's not go to Simula yet, let's go to Algol. Fortran didn't have at the time the notions of not a precise notion of type, not a precise notion of scope, not a set of translation phases. That was what we have today, lexical syntax, semantics. It was sty of a bit of a model in the early days, but hey, they'd just done the biggest breakthrough in the history of programming, right? So you can't criticize them for not having gotten all the technical details right. So we got alcohol. That was very pretty. And most people in commerce and science considered it useless because it was not flexible enough and it wasn't efficient enough and et cetera, et cetera. But that was a breakthrough from the technical point of view. Then Simula came along to make that idea More flexible and you could define your own types. And that's where I got very interested. Preston Nugong, who's the main idea man behind Simula that was late 60s, this was late 60s, was a visiting professor in Auschwitz. And so I learned object oriented programming by sitting around and well, in theory discussing with Kreist Nugel, but Greyston wants to get started and in full flow. It's very hard to get a word in edgeways with.

You're just listening.

So it was great. I learned it from there.

Not to romanticize the notion, but it seems like a big leap to think about object oriented programming. It's really a leap of abstraction.

Yes.

And was that as big and beautiful of a leap as it seems from now in retrospect, or was it an obvious one at the time?

It was not obvious. And many people have tried to do something like that and most people didn't come up with something as wonderful as similar. Lots of people got their PhDs and made their careers out of forgetting about Simula or never knowing it. For me, the key idea was basically I could get my own types. And that's the idea that goes further into C, where I can get better types and more flexible types and more efficient types. But it's still the fundamental idea. When I want to write a program, I want to write it with my types of that is appropriate to my problem and under the constraints that I'm under. The idea people picked up on the class hierarchies and the version was only part of. Was an interesting and major part, and still a major part in a lot of graphic stuff. But it was not the most fundamental. It was when you wanted to relate one type to another, you don't want them all to be independent. The classical example is that you don't actually want to write city simulation with vehicles where you say, well, if it's a bicycle, write the code for turning a bicycle to the left. If it's a normal car, turn right the normal car way. If it's a fire engine, turn right the fire engine way. Da da da da da da. You get these big case statements and bunches of if statements and such. Instead you tell the base class that's the vehicle saying turn left the way you want to. This is actually a real example. They used it to simulate and optimize the emergency. The emergency services for somewhere in Norway back in the 60s.

Wow.

So this was one of the early examples for why you needed inheritance and you needed a runtime polymorphism because you wanted to handle this set of Vehicles in a manageable way. You can't just rewrite your code each time a new kind of vehicle comes along.

Yeah, that's a beautiful, powerful idea and of course it stretches through your work with C, as we'll talk about. But I think you structured nicely what other breakthroughs came along in the history of programming languages if we were to tell the history in that way.

Obviously I'm better telling the part of the history that that is the path I'm on as opposed to all the path.

Yeah, you skipped the hippie John McCarthy and Lisp, one of my favorite languages.

But Lisp. But Lisp is not one of my favorite languages. It's obviously important, it's obviously interesting. Lots of people write code in it and then they rewrite it into C or C when they want to go to production. Yes, it's in the world I'm at which are constrained by performance, reliability issues, deployability, cost of hardware. I don't like things to be too dynamic. It is really hard to write a piece of code that's perfectly flexible that you can also deploy on a small computer and that you can also put in, say, a telephone switch in Bogota. What's the chance if you get an error and you find yourself in the debugger that the telephone switch in Bogota on late Sunday night has a programmer around? The chance is zero. And so a lot of things I think most about can't afford that flexibility. I'm quite aware that maybe 70, 80% of all code are not under the kind of constraints I'm interested in. But somebody has to do the job I'm doing because you have to get from these high level flexible languages to.

The hardware, the stuff that lasts for 10, 20, 30 years is robust, operates under very constrained conditions. Yes, absolutely, that's right. And it's fascinating and beautiful in its own way. It's C's one of my favorite languages and so is Lisp. So I can, I can embody two for different reasons as, as a programmer.

I, I understand why Lisp is popular and I can see the beauty of the ideas. And similarly with, with small talk, it's just not relative bank. It is not as relevant in my world. And by the way, I distinguish between those, my functional languages where I go to things like ML and Haskell, different, different kind of languages, they have a different kind of beauty and they're very interesting. And I actually try to learn from all the languages I encounter to see what is there that would make working on the kind of problems I'm interested in with the kind of constraints that I'm interested in, what can actually be done better, because we can surely do better than we do today. Sa.