This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. You can watch the full conversation here: https://www.youtube.com/watch?v=uTxRF5ag27A
(more links below)

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

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

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 aspects 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 talk to regulators, people in 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.

I did not expect you to say that, but that's very true.

I'm dealing with 1 part of the system and I want my part to be really good, but I know it's not the whole system.

Furthermore, making an individual part perfect may actually not be the best way of getting the highest degree of reliability and performance and such.

There's people who say C++ is type safe, not type safe, you can break it.

Sure, I can break anything that runs on a computer.

If I wanted to break into your computer, I'll probably try SQL injection.

If you think about safety or even reliability at a system level, especially when a human being is involved, it starts becoming hopeless pretty quickly in terms of proving that something is safe to a certain level.

Because there's so many variables, it's so complex.

Well, let's get back to something we can talk about and actually make some progress on.

We can look at C++ programs and we can try and make sure they crash less often.

The way you do that is largely by simplification.

It is not, the first step is to simplify the code, have less code, have code that are less likely to go wrong.

It is not by big test frameworks that you're using.

But the first step is actually to make sure that when you want to express something, you can express it directly in code rather than going through endless loops and convolutions in your head before it gets down the code.

That if the way you are thinking about a problem is not in the code, There is a missing piece that's just in your head.

And the code you can see what it does, but it cannot see what you thought about it unless you have expressed things directly.

When you express things directly, you can maintain it.

And therefore, you can use a smaller number of computers, which means there's less hardware that could possibly break.

So I think the key here is simplification, but it has to be, to use the Einstein quote, as simple as possible and no simpler.


Speaker 0: What was the origin story of C++? You basically gave a few perspectives of your inspiration of object-oriented programming. You had a connection with C and performance, efficiency was an important thing you were drawn to. Efficiency and reliability. Reliability.

You have to get both. What's reliability?

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

Speaker 0: of those problems. I mean, they keep popping up in different ways. Because we tackle bigger and bigger problems, so efficiency remains always an important aspect.

Speaker 1: 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. That computer better work.

Speaker 0: 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 aspects 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 talk to regulators, people in 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?

Speaker 1: 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. That's all right. I don't need to do that. Yeah, that piece of code is secure.

I'll buy your operator. 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.

Speaker 0: I did not expect you to say that, but that's very true.

Speaker 1: Yes. I'm dealing with 1 part of the system and I want my part to be really good, but I know it's not the whole system. Furthermore, making an individual part perfect may actually not be the best way of getting the highest degree of reliability and performance and such. There's people who say C++ is type safe, not type safe, you can break it. Sure, I can break anything that runs on a computer.

I may not go through your type system. If I wanted to break into your computer, I'll probably try SQL injection.

Speaker 0: And it's very true. If you think about safety or even reliability at a system level, especially when a human being is involved, it starts becoming hopeless pretty quickly in terms of proving that something is safe to a certain level. Yeah. Because there's so many variables, it's so complex.

Speaker 1: Well, let's get back to something we can talk about and actually make some progress on. Yes. We can look at C++ programs and we can try and make sure they crash less often. The way you do that is largely by simplification. It is not, the first step is to simplify the code, have less code, have code that are less likely to go wrong.

It's not by runtime testing everything. It is not by big test frameworks that you're using. Yes, we do that also. But the first step is actually to make sure that when you want to express something, you can express it directly in code rather than going through endless loops and convolutions in your head before it gets down the code. That if the way you are thinking about a problem is not in the code, There is a missing piece that's just in your head.

And the code you can see what it does, but it cannot see what you thought about it unless you have expressed things directly. When you express things directly, you can maintain it. It's easier to find errors. It's easier to make modifications. It's actually easier to test it.

And lo and behold, it runs faster. And therefore, you can use a smaller number of computers, which means there's less hardware that could possibly break. So I think the key here is simplification, but it has to be, to use the Einstein quote, as simple as possible and no simpler.

Speaker 0: Not simpler. But there are

See all Lex Fridman transcripts on Youtube

Bjarne Stroustrup: Simplification is the Key to Reliability and Efficiency in Code