The following is a conversation with Bjarne Stroustrup.

He's the creator of C++, a programming language that after 40 years is still 1 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, for example, many of the critical back-end components 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 1 day will land us on Mars.

C++ also happens to be the language that I use more than any other in my life.

I've written several hundred thousand lines of C++ source code.

Of course, lines of source code don't mean much, but they do give hints of my personal journey through the world of software.

I've enjoyed watching the development of C++ as a programming language, leading up to the big update in the standard in 2011, and those that followed in 14, 17, and toward the new C++ 20 standard hopefully coming out next year.

This is the Artificial Intelligence Podcast.

If you enjoy it, subscribe on YouTube, give it 5 stars on iTunes, support it on Patreon, or simply connect with me on Twitter at Lex Friedman, spelled F-R-I-D-M-A-N.

And now, here's my conversation with Bjorn Stroustrup.

What was the first program you've ever written?

It was my second year in university, first year of computer science, and it was an Alcor

I calculated the shape of a super ellipse and then connected points on the perimeter, creating star patterns.

It was with a wet ink on a paper printer.

I learned to program the second year in university.

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 I Remember snowball I Remember Fortran didn't fall in love with that.

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.

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

What type system, typing system did Algol 60 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.

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

So instead of trying to fit yourself into Niklaus Wirth's world, Christen Nygård'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?

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.

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

So that's- And that was the first step towards the human.

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

Business people were different, so they got cobalt instead, et cetera, et cetera.

And Simula came out, no, let's not go to Simula yet.

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.

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 Nygård, 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.

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

They used it to simulate and optimize 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 is the path I'm on as opposed to all the paths.

Yeah, you skipped the hippie John McCarthy in Lisp, 1 of my favorite languages.

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.

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, yes, Absolutely.

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

You've said that it's good for any professional programmer to know at least 5 languages.

Speaking about a variety of languages that you've taken inspiration from.

And you've listed yours as being, at least at the time, C++ obviously, Java, Python, Ruby, and JavaScript.

Can you, first of all, update that list, modify it?

You don't have to be constrained to just 5, but can you describe what you picked up also from each of these languages?

How you see them as inspirations for even you working with C++?

So about languages, you should know languages.

I reckon I knew about 25 or thereabouts when I did C++.

It was easier in those days because the languages were smaller and you didn't have to learn a whole programming environment and such to do it.

You could learn the language quite easily.

And it's good to learn so many languages.

I imagine just like with natural language for communication, there's different paradigms that emerge in all of them.

The important thing that the number is not 1.

It's like I don't like, I mean, if you're a monoglot, you are likely to think that your own culture is the only 1 superior to everybody else's.

A good learning of a foreign language and a foreign culture is important.

It helps you think and be a better person.

With programming languages, you become a better programmer, better designer with the second language.

Now, once you've got 2, the wait of 5 is not that long.

And then when I had to pick 5, I sort of thinking what kinds of languages are there?

The C++ optimizers write better machine code than I do.

but I don't think I could appreciate them if I actually didn't understand machine code and machine architecture.

At least in my position, I have to understand a bit of it because you mess up the cache and you're off in performance by a factor of

It shouldn't be that if you are interested in either performance or the size of the computer you have to deploy.

I used to mention C, but these days going low level is not actually what gives you the performance.

It is to express your ideas so cleanly that you can think about it and the optimizer can understand what you're up to.

My favorite way of optimizing these days is to throw out the clever bits and see if it still runs fast.

So I need the abstraction mechanisms or something like C++ to write compact, high performance code.

There was a beautiful keynote by Jason Turner at the CPP Con a couple of years ago, where he decided he was going to program Pong on Motorola

And he says, well, this is relevant because it looks like a microcontroller.

It has specialized hardware, it has not very much memory and it's relatively slow.

And so he shows in real time how he writes Pong starting with fairly straightforward low level stuff, improving his abstractions.

And what He's doing, he's writing C++ and it translates into

Assembler, which you can do with Clang and you can see it in real time.

It's the compiler explorer which you can use on the web.

And then he wrote a little program that translated 86Assembler into Motorola Assembler.

And even if you can't read the assembly code, you can just see it, his code gets better, the code, the assembler gets smaller.

He increases the abstraction level, uses C++ 11 as it were better.

This code gets cleaner, it gets easier to maintain, the code shrinks and it keeps shrinking.

And I could not in any reasonable amount of time write that assembler as good as the compiler generated from really quite nice modern C++.

And I'll go as far as to say that the thing that looked like C was significantly uglier and smaller when it became, and larger when it became machine code.

So the abstractions that can be optimized are important.

I would love to see that kind of visualization in larger code bases.

But you can't show a larger code base in a 1 hour talk and have it fit on screen.

So my 2 languages would be machine code and C++.

And Then I think you can learn a lot from the functional languages.

I think actually you learn the same lessons of expressing especially mathematical notions really clearly and having a type system that's really strict.

And then you should probably have a language for sort of quickly churning out something.

You could pick JavaScript, you could pick Python, you could pick Ruby.

What do you make of JavaScript in general?

So you're talking in the platonic sense about languages, about what they're good at, what their philosophy of design is, but there's also a large user base behind each of these languages and they use it in a way sometimes maybe it wasn't really designed for.

JavaScript is used way beyond probably what it was designed for.

When you build a tool, you do not know how it's going to be used.

You try to improve the tool by looking at how it's being used and when people cut their fingers or from trying to stop that from happening.

But really, you have no control over how something is used.

So I'm very happy and proud of some of the things C++ being used at, and some of the things I wish people wouldn't do.

Bitcoin mining being my favorite example, uses as much energy as Switzerland and mostly serves criminals.

But back to the languages, I actually think that having JavaScript run in the browser was an enabling thing for a lot of things.

Yes, you could have done it better, but people were trying to do it better and they were using sort of more principles, language designs, but they just couldn't do it right.

And the non-professional programmers that write lots of that code just couldn't understand them.

So it did an amazing job for what it was.

It's not the prettiest language and I don't think it ever will be the prettiest language, but let's not be bigots here.

You basically gave a few perspectives of your inspiration of object-oriented programming.

That's you had a connection with C and performance efficiency was an important thing you were drawn to.

I really want my telephone calls to get through and I want the quality of what I am talking coming out at the other end.

The other end might be in London or wherever.

So, and you don't want the system to be crashing.

If you're doing a bank, you mustn't crash.

It might be your bank account that is in trouble.

There's different constraints like in games, it doesn't matter too much if there's a crash, nobody dies and nobody gets ruined.

But I'm interested in the combination of performance, partly because of sort of speed of things being done, part of being able to do things that is necessary to have reliability of larger systems.

If you spend all your time interpreting a simple function call, you are not going to have enough time to do proper signal processing to get the telephone calls to sound right.

Either that, or you have to have 10 times as many computers and you can't afford your phone anymore.

It's a ridiculous idea in the modern world because we have solved all

I mean, they keep popping up in different ways.

Because we tackle bigger and bigger problems, So efficiency remains always an important aspect.

But you have to think about efficiency, not just as speed, but as an enabler to important things.

And 1 of the things it enables is reliability, is dependability.

When I press the pedal, the brake pedal of a car, it is not actually connected directly to anything but a computer.

Let's talk about reliability just a little bit.

So modern cars have ECUs, have millions of lines of code today.

So this is certainly especially true of autonomous vehicles where some of the aspect of the control or driver assistance systems that steer the car, that keep it in the lane and so on.

So how do you think, you know, I talked to regulators, people in the government who are very nervous about testing the safety of these systems of software, ultimately software that makes decisions that could lead to fatalities.

So how do we test software systems like these?

First of all, safety, like performance and like security, is a system's property.

People tend to look at 1 part of a system at a time and saying something like, this is secure.

If you want to have reliability, if you want to have performance, if you want to have security, you have to look at the whole system.

See all Lex Fridman transcripts on Youtube

Bjarne Stroustrup: C++ | Lex Fridman Podcast #48