Full episode with Bjarne Stroustrup (Nov 2019): https://www.youtube.com/watch?v=uTxRF5ag27A
Please subscribe to new clips channel (Lex Clips): https://www.youtube.com/lexclips
Once it reaches 20,000 subscribers, I'll start posting the clips there instead. 
(more links below)

For now, new full episodes are released once or twice a week and a few new clips or a new non-podcast video is released on all other days.

Podcast full episodes playlist:
https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4

Podcasts clips playlist:
https://www.youtube.com/playlist?list=PLrAXtmErZgOeciFP3CBCIEElOJeitOr41

Podcast website:
https://lexfridman.com/ai

Podcast on Apple Podcasts (iTunes):
https://apple.co/2lwqZIr

Podcast on Spotify:
https://spoti.fi/2nEwCF8

Podcast RSS:
https://lexfridman.com/category/ai/feed/

Note: I select clips with insights from these much longer conversation with the hope of helping make these ideas more accessible and discoverable. Ultimately, this podcast is a small side hobby for me with the goal of sharing and discussing ideas. I did a poll and 92% of people either liked or loved the posting of daily clips, 2% were indifferent, and 6% hated it, some suggesting that I post them on a separate YouTube channel. I hear the 6% and partially agree, so am torn about the whole thing. I tried creating a separate clips channel but the YouTube algorithm makes it very difficult for that channel to grow. So for a little while, I'll keep posting clips on this channel. I ask for your patience and to see these clips as supporting the dissemination of knowledge contained in nuanced discussion. If you enjoy it, consider subscribing, sharing, and commenting.

Bjarne Stroustrup is the creator of C++, a programming language that after 34 years is still one of the most popular and powerful languages in the world. Its focus on fast, stable, robust code underlies many of the biggest systems in the world that we have come to rely on as a society. If you're watching this on YouTube, many of the critical back-end component of YouTube are written in C++. Same goes for Google, Facebook, Amazon, Twitter, most Microsoft applications, Adobe applications, most database systems, and most physical systems that operate in the real-world like cars, robots, rockets that launch us into space and one day will land us on Mars.

Subscribe to this YouTube channel or connect on:
- Twitter: https://twitter.com/lexfridman
- LinkedIn: https://www.linkedin.com/in/lexfridman
- Facebook: https://www.facebook.com/lexfridman
- Instagram: https://www.instagram.com/lexfridman
- Medium: https://medium.com/@lexfridman
- Support on Patreon: https://www.patreon.com/lexfridman

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

I remember Pascal, didn't fall in love with that.

And then I discovered Assembler and that was much more fun.

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 then I discovered Simula, which was absolutely great.

Simula was the extension of Algor60, 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.

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.

What kind of if you remember, what kind of type system did Pascal have?

What type system, typing system did Algol 60 have?

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.

Whereas Simula allowed you basically to build your own type system.

So instead of trying to fit yourself into Niklaus Wirth'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.

Every language that uses the word class for type is a descendant of Simula.

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

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 term, in the language of that machine.

Bacchus and his team at IBM built a language that would allow you to 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 machines needs.

We want to raise the language to the human level, but we don't want to lose the efficiency.

And of course, they were very particular kind of humans.

Business people were different, so they got Cobalt instead and etc.

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.

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.

Christen Nygård, who's the main idea man behind Simula.

Well, I was a visiting professor in Aarhus.

And so I learned object-oriented programming by sitting around and, well, in theory, discussing with Christen Nyggaard, but Christen, once you get started and in full flow, it's very hard to get a word in edgeways.

Not to romanticize the notion, but it seems like a big leap to think about object-oriented programming.

And was that as big and beautiful of a leap as it seems from now in retrospect, or was it an obvious 1 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, et cetera.

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 1 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, 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 and say, turn left the way you want to.

They used it to simulate and optimize the Emergency, the emergency services for somewhere in Norway, back in the 60s.

So this was 1 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.

And of course it stretches through your work, OC++ as we'll talk about.

What other breakthroughs came along in the history of programming languages?

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

Yeah, You skipped the hippie John McCarthy and Lisp, 1 of my favorite languages.

But Lisp is not 1 of my favorite languages.

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.

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.

And so a lot of things I think most about can't afford that flexibility.

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.

And it's fascinating and beautiful in its own way.

It's C++ is 1 of my favorite languages and so is Lisp.

So I can embody it too for different reasons

I understand why Lisp is popular and I can see the beauty of the ideas and similarly with Smalltalk.

And by the way, I distinguish between those in 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.


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

Speaker 1: I think I'll call it 60. And after that, I remember Snowball. I remember Fortran. Didn't fall in love with that.

Speaker 2: I remember Pascal. Didn't fall in love with that.

Speaker 1: 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.

Speaker 2: So you were drawn to the, you found the low level stuff beautiful.

Speaker 1: 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 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.

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

Speaker 1: 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. Whereas Simula allowed you basically to build your own type system. So instead of trying to fit yourself into Niklaus Wirth'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.

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

Speaker 1: Yes, they invented it. Every language that uses the word class for type is a descendant of Simula. Directly or indirectly. Christen 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.

Speaker 2: 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.

Speaker 1: 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 term, in the language of that machine. And.

Bacchus and his team at IBM built a language that would allow you to 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 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

Speaker 2: the first step towards the human.

Speaker 1: That was the first step. And of course, they were very particular kind of humans. Business people were different, so they got Cobalt instead and etc. Etc. 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 Alco. 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. Christen Nygård, who's the main idea man behind Simula.

Speaker 2: That was late 60s.

Speaker 1: 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 Christen Nyggaard, but Christen, once you get started and in full flow, it's very hard to get a word in edgeways.

Speaker 2: Where you're just listening. So

Speaker 1: it was great. I learned it from there.

Speaker 2: 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 1 at the time?

Speaker 1: 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, et cetera.

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 1 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, 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 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, the emergency services for somewhere in Norway, back in the 60s. Wow. So this was 1 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.

Speaker 2: Yeah, that's a beautiful, powerful idea. And of course it stretches through your work, OC++ 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

Speaker 1: in that way? Obviously, I'm better at telling the part of the history that that is the path I'm on as opposed to all the paths.

Speaker 2: Yeah, You skipped the hippie John McCarthy and Lisp, 1 of my favorite languages.

Speaker 1: But Lisp is not 1 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. Right. Their chance is 0. And so a lot of things I think most about can't afford that flexibility.

I'm quite aware that maybe

Speaker 0: 70, 80%

Speaker 1: 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.

Speaker 2: The stuff that lasts for 10, 20, 30 years is robust, operates under very constrained conditions. Yes, absolutely.

Speaker 1: That's right.

Speaker 2: And it's fascinating and beautiful in its own way. It's C++ is 1 of my favorite languages and so is Lisp. So I can embody it too for different reasons

Speaker 1: 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 in 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. You

See all Lex Fridman transcripts on Youtube

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