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 it 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.

I paid for my master's, actually. And then I discovered Simula, which was absolutely great. Simula? Simula was the extension of Algor60, done primarily for simulation. But basically, they invented object-oriented programming at inheritance and runtime polymorphism when they were... 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 Algor60 have? Basically, Pascal was sort of the simplest language that Niklaus Wirt could define that served the needs of Niklaus Wirt 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. And this simula allowed you basically to build your own type system. So instead of trying to fit yourself into Niklaus Wirt's world, Christian Nygaard's language and Ole Johan Dahl's 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. We are indirectly. Christian Nygaard and Ole Johan Dahl were mathematicians and they didn't think in terms of types, but they understood sets and classes of elements. And so they called their types classes.

And basically in C++, as in simula, 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 macro assembler or some extension of that idea. But you are writing for a specific machine in the language of that machine. And Bacchus 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 happened 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 machines 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.

So that's- And that was the first step towards the human. That was the first step. And of course, they were very particular kind of humans. Business people were different, so they got Cobol instead and et cetera, et cetera. And Simula came out. No, let's not go to Simula yet.

Let's go to Algor. 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 sort of a bit of a model in the early days, but hey, they had 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 Algor. 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 a 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 Nugent, who's the main idea man behind Simula. That was late '60s. This was late '60s. Well, I was a visiting professor in Aarhus. And so I learned object-oriented programming by sitting around and well, in theory, discussing with Preston Nugent.

But Preston, once you get started and in full flow, it's very hard to get a word in edgeways. 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 Simula.

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 that is appropriate to my problem and under the constraints that I'm under with hardware, software, environment, etc. And that's the key idea. People picked up on the class hierarchies and the virtual functions and the inheritance.

And that was only part of it. It 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 a 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.

You get these big case statements and bunches of if statements and such. Instead, you tell the base class that that's the vehicle and say turn left the way you want to. And this is actually a real example. They used it to simulate and optimize the emergency services for somewhere in Norway back in the 60s.

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, C++, as we'll talk about. But I think you've structured it 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 at telling the part of the history that is the path I'm on as opposed to all the paths.

Yeah, you skipped the hippie John McCarthy in Lisp, one of my favorite languages. 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.

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++ is one of my favorite languages, and so is Lisp. So I can embody it too, for different reasons, as a programmer. I understand why Lisp is popular, and I can see the beauty of the ideas, and similarly with Smalltalk. It's just not as relevant in my world.

And by the way, I distinguish between those and the functional languages where I go to things like ML and Haskell. 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. 1