Bjarne Stroustrup: C++ - Lex Fridman 知识图谱

Lex Fridman (1:15:37.600)

So it bothered me. Then we tried again, 2002, 2003. Gaby DesRays and I started analyzing the

Bjarne Stroustrup (1:15:47.840)

problem, explained possible solutions. It was not a complete design. A group in University of Indiana,

Bjarne Stroustrup (1:15:57.280)

an old friend of mine, they started a project at Indiana and we thought we could get

Bjarne Stroustrup (1:16:11.360)

a good system of concepts in another two or three years that would have made C++ 11 to C++

Bjarne Stroustrup (1:16:22.000)

06 or 07. Well, it turns out that I think we got a lot of the fundamental ideas wrong. They were

Bjarne Stroustrup (1:16:33.280)

too conventional. They didn't quite fit C++ in my opinion. Didn't serve implicit conversions very

Bjarne Stroustrup (1:16:41.920)

well. It didn't serve mixed type arithmetic, mixed type computations very well. A lot of

Bjarne Stroustrup (1:16:51.120)

stuff came out of the functional community and that community didn't deal with multiple types

Bjarne Stroustrup (1:17:03.200)

in the same way as C++ does, had more constraints on what you could express and didn't have the

Bjarne Stroustrup (1:17:12.480)

draconian performance requirements. And basically we tried. We tried very hard. We had some

Bjarne Stroustrup (1:17:19.760)

successes, but it just in the end wasn't, didn't compile fast enough, was too hard to use and

Bjarne Stroustrup (1:17:31.440)

didn't run fast enough unless you had optimizers that was beyond the state of the art. They still

Bjarne Stroustrup (1:17:40.080)

are. So we had to do something else. Basically it was the idea that a set of parameters has

Bjarne Stroustrup (1:17:49.120)

defined a set of operations and you go through an interaction table just like for virtual functions

Lex Fridman (1:17:55.760)

and then you try to optimize the interaction away to get performance. And we just couldn't

Bjarne Stroustrup (1:18:03.360)

do all of that. But get back to the standardization. We are standardizing C++ under ISO rules,

Bjarne Stroustrup (1:18:12.720)

which are very open process. People come in, there's no requirements for education or experience.

Lex Fridman (1:18:20.160)

So you started to develop C++ and there's a whole, when was the first standard established? What is

Bjarne Stroustrup (1:18:28.960)

that like? The ISO standard, is there a committee that you're referring to? There's a group of

Lex Fridman (1:18:34.960)

people. What was that like? How often do you meet? What's the discussion?

Bjarne Stroustrup (1:18:39.280)

I'll try and explain that. So sometime in early 1989, two people, one from IBM, one from HP,

Bjarne Stroustrup (1:18:52.720)

turned up in my office and told me I would like to standardize C++. This was a new idea to me and

Bjarne Stroustrup (1:19:02.080)

when I pointed out that it wasn't finished yet and it wasn't ready for formal standardization

Lex Fridman (1:19:09.760)

and such. And they say, no, Bjarne, you haven't gotten it. You really want to do this.

Bjarne Stroustrup (1:19:16.400)

Our organizations depend on C++. We cannot depend on something that's owned by another

Bjarne Stroustrup (1:19:23.760)

corporation that might be a competitor. Of course we could rely on you, but you might get run over

Bjarne Stroustrup (1:19:31.040)

by a boss. We really need to get this out in the open. It has to be standardized under formal rules

Lex Fridman (1:19:41.840)

and we are going to standardize it under ISO rules and you really want to be part of it because

Bjarne Stroustrup (1:19:51.120)

basically otherwise we'll do it ourselves. And we know you can do it better. So through a combination

Bjarne Stroustrup (1:20:00.800)

of arm twisting and flattery, it got started. So in late 89, there was a meeting in DC at the,

Bjarne Stroustrup (1:20:15.600)

actually no, it was not ISO then, it was ANSI, the American National Standard doing.

Bjarne Stroustrup (1:20:23.200)

We met there. We were lectured on the rules of how to do an ANSI standard. There was about 25 of us

Bjarne Stroustrup (1:20:30.480)

there, which apparently was a new record for that kind of meeting. And some of the old C guys that

Bjarne Stroustrup (1:20:38.800)

has been standardized in C was there. So we got some expertise in. So the way this works is that

Bjarne Stroustrup (1:20:45.440)

it's an open process. Anybody can sign up if they pay the minimal fee, which is about a thousand

Bjarne Stroustrup (1:20:52.720)

dollars, less than a little bit more now. And I think it's $1,280. It's not going to kill you.

Lex Fridman (1:21:01.680)

And we have three meetings a year. This is fairly standard. We tried two meetings a year for a

Bjarne Stroustrup (1:21:10.880)

couple of years that didn't work too well. So three one week meetings a year and you meet

Lex Fridman (1:21:20.160)

and you have technical discussions, and then you bring proposals forward for votes. The votes are

Bjarne Stroustrup (1:21:28.320)

done one person per, one vote per organization. So you can't have say IBM come in with 10 people

Lex Fridman (1:21:39.040)

and dominate things that's not allowed. And these are organizations that extensively UC

Bjarne Stroustrup (1:21:44.160)

plus plus. Yes. Or individuals or individuals. I mean, it's a bunch of people in the room

Bjarne Stroustrup (1:21:53.280)

deciding the design of a language based on which a lot of the world's systems run.

Bjarne Stroustrup (1:22:00.400)

Right. Well, I think most people would agree it's better than if I decided it

Bjarne Stroustrup (1:22:06.240)

or better than if a single organization like AG&T decides it. I don't know if everyone agrees to

Bjarne Stroustrup (1:22:13.200)

that, by the way. Bureaucracies have their critics too. Yes. Look, standardization is not pleasant.

Bjarne Stroustrup (1:22:23.360)

It's horrifying. It's like democracy. Exactly. As Churchill says, democracy is the worst way,

Bjarne Stroustrup (1:22:31.200)

except for the others. Right. And it's, I would say the same with formal standardization.

Lex Fridman (1:22:36.480)

But anyway, so we meet and we have these votes and that determines what the standard is.

Bjarne Stroustrup (1:22:45.040)

A couple of years later, we extended this so it became worldwide. We have standard organizations

Bjarne Stroustrup (1:22:53.280)

that are active in currently 15 to 20 countries and another 15 to 20 are sort of looking and voting

Bjarne Stroustrup (1:23:08.800)

based on the rest of the work on it. And we meet three times a year. Next week I'll be in Cologne,

Bjarne Stroustrup (1:23:15.680)

Germany, spending a week doing standardization and we'll vote out the committee draft of C++20,

Bjarne Stroustrup (1:23:25.440)

which goes to the national standards committees for comments and requests for changes and

Bjarne Stroustrup (1:23:34.000)

improvements. Then we do that and there's a second set of votes where hopefully everybody

Bjarne Stroustrup (1:23:39.600)

votes in favor. This has happened several times. The first time we finished, we started in the

Bjarne Stroustrup (1:23:47.040)

first technical meeting was in 1990. The last was in 98. We voted it out. That was the standard

Bjarne Stroustrup (1:23:55.760)

that people used until 11 or a little bit past 11. And it was an international standard. All the

Bjarne Stroustrup (1:24:04.000)

countries voted in favor. It took longer with 11. I'll mention why, but all the nations voted in

Bjarne Stroustrup (1:24:13.440)

favor. And we work on the basis of consensus. That is, we do not want something that passes 6040

Bjarne Stroustrup (1:24:24.400)

because then we're going to get dialects and opponents and people complain too much. They

Bjarne Stroustrup (1:24:30.240)

all complain too much, but basically it has no real effect. The standards has been obeyed. They

Bjarne Stroustrup (1:24:37.280)

have been working to make it easier to use many compilers, many computers and all of that kind of

Bjarne Stroustrup (1:24:44.880)

stuff. It was traditional with ISO standards to take 10 years. We did the first one in eight,

Bjarne Stroustrup (1:24:54.080)

brilliant. And we thought we were going to do the next one in six because now we are good at it.

Bjarne Stroustrup (1:25:00.400)

Right. It took 13. Yeah. It was named OX. It was named OX. Hoping that you would at least get it

Bjarne Stroustrup (1:25:10.720)

within the single, within the odds, the single digits. I thought we would get, I thought we'd

Bjarne Stroustrup (1:25:15.760)

get six, seven or eight. The confidence of youth. That's right. Well, the point is that this was

Bjarne Stroustrup (1:25:21.920)

sort of like a second system effect. That is, we now knew how to do it. And so we're going to do

Bjarne Stroustrup (1:25:28.160)

it much better. And we've got more ambitious and it took longer. Furthermore, there is this tendency

Bjarne Stroustrup (1:25:35.680)

because it's a 10 year cycle or it doesn't matter. Just before you're about to ship,

Bjarne Stroustrup (1:25:45.200)

somebody has a bright idea. And so we really, really must get that in. We did that successfully

Bjarne Stroustrup (1:25:57.360)

with the STL. We got the standard library that gives us all the STL stuff. That basically,

Bjarne Stroustrup (1:26:05.680)

I think it saved C++. It was beautiful. And then people tried it with other things

Lex Fridman (1:26:11.520)

and it didn't work so well. They got things in, but it wasn't as dramatic and it took longer and

Bjarne Stroustrup (1:26:17.520)

longer and longer. So after C++ 11, which was a huge improvement and what, basically what most

Bjarne Stroustrup (1:26:26.720)

people are using today, we decided never again. And so how do you avoid those slips? And the

Bjarne Stroustrup (1:26:36.400)

answer is that you ship more often. So that if you have a slip on a 10 year cycle, by the time

Bjarne Stroustrup (1:26:46.320)

you know it's a slip, there's 11 years till you get it. Now with a three year cycle, there is

Bjarne Stroustrup (1:26:52.960)

about three or four years till you get it. Like the delay between feature freeze and shipping. So

Bjarne Stroustrup (1:27:02.640)

you always get one or two years more. And so we shipped 14 on time, we shipped 17 on time,

Lex Fridman (1:27:10.880)

and we ship, we will ship 20 on time. It'll happen. And furthermore, this gives a predictability

Bjarne Stroustrup (1:27:21.680)

that allows the implementers, the compiler implementers, the library implementers,

Bjarne Stroustrup (1:27:26.320)

they have a target and they deliver on it. 11 took two years before most compilers were good

Bjarne Stroustrup (1:27:34.640)

enough. 14, most compilers were actually getting pretty good in 14. 17, everybody shipped in 17.

Bjarne Stroustrup (1:27:45.360)

We are going to have at least almost everybody ship almost everything in 20. And I know this

Lex Fridman (1:27:53.200)

and I know this because they're shipping in 19. Predictability is good. Delivery on time is good.

Lex Fridman (1:28:01.040)

And so yeah. That's great. That's how it works.

Bjarne Stroustrup (1:28:05.920)

There's a lot of features that came in in C++ 11. There's a lot of features at the birth of C++

Bjarne Stroustrup (1:28:13.200)

that were amazing and ideas with concepts in 2020. What to you is the most,

Bjarne Stroustrup (1:28:20.240)

just to you personally, beautiful or just you sit back and think, wow, that's just nice and clean

Bjarne Stroustrup (1:28:32.640)

feature of C++? I have written two papers for the History of Programming Languages Conference,

Bjarne Stroustrup (1:28:41.680)

which basically asked me such questions. And I'm writing a third one, which I will deliver

Bjarne Stroustrup (1:28:47.520)

at the History of Programming Languages Conference in London next year. So I've been thinking about

Bjarne Stroustrup (1:28:53.440)

that. And there is one clear answer. Constructors and destructors. The way a constructor can

Bjarne Stroustrup (1:29:00.320)

establish the environment for the use of a type for an object and the destructor that cleans up

Bjarne Stroustrup (1:29:08.400)

any messes at the end of it. That is key to C++. That's why we don't have to use garbage

Bjarne Stroustrup (1:29:15.120)

collection. That's how we can get predictable performance. That's how you can get the minimal

Bjarne Stroustrup (1:29:22.640)

overhead in many, many cases, and have really clean types. It's the idea of constructor destructor

Bjarne Stroustrup (1:29:31.520)

pairs. Sometimes it comes out under the name RAII. Resource acquisition is initialization,

Bjarne Stroustrup (1:29:40.480)

which is the idea that you grab resources in the constructor and release them in destructor.

Bjarne Stroustrup (1:29:46.560)

It's also the best example of why I shouldn't be in advertising. I get the best idea and I call it

Bjarne Stroustrup (1:29:53.200)

resource acquisition is initialization. Not the greatest naming I've ever heard.

Bjarne Stroustrup (1:29:59.520)

Not the greatest naming I've ever heard. So it's types, abstraction of types.

Bjarne Stroustrup (1:30:11.040)

You said, I want to create my own types. So types is an essential part of C++ and making them

Bjarne Stroustrup (1:30:18.000)

efficient is the key part. And to you, this is almost getting philosophical, but the construction

Lex Fridman (1:30:27.760)

and the destruction, the creation of an instance of a type and the freeing of resources from that

Bjarne Stroustrup (1:30:36.400)

instance of a type is what defines the object. It's almost like birth and death is what defines

Bjarne Stroustrup (1:30:45.200)

human life. That's right. By the way, philosophy is important. You can't do good language design

Bjarne Stroustrup (1:30:53.600)

without philosophy because what you are determining is what people can express and how.

Bjarne Stroustrup (1:30:59.200)

This is very important. By the way, constructors destructors came into C++ in 79 in about the

Bjarne Stroustrup (1:31:08.160)

second week of my work with what was then called C of the classes. It is a fundamental idea.

Bjarne Stroustrup (1:31:15.120)

Next comes the fact that you need to control copying because once you control, as you said,

Bjarne Stroustrup (1:31:21.200)

birth and death, you have to control taking copies, which is another way of creating an object.

Lex Fridman (1:31:29.200)

And finally, you have to be able to move things around so you get the move operations. And that's

Bjarne Stroustrup (1:31:35.680)

the set of key operations you can define on a C++ type. And so to you, those things are just

Bjarne Stroustrup (1:31:45.440)

just a beautiful part of C++ that is at the core of it all. Yes. You mentioned that you hope there

Bjarne Stroustrup (1:31:54.240)

will be one unified set of guidelines in the future for how to construct a programming language.

Lex Fridman (1:32:00.000)

So perhaps not one programming language, but a unification of how we build programming languages,

Bjarne Stroustrup (1:32:08.480)

if you remember such statements. I have some trouble remembering it, but I know the origin

Bjarne Stroustrup (1:32:13.840)

of that idea. So maybe you can talk about sort of C++ has been improving. There's been a lot

Bjarne Stroustrup (1:32:19.360)

of programming language. Do you, where does the arc of history taking us? Do you hope that there

Lex Fridman (1:32:25.200)

is a unification about the languages with which we communicate in the digital space?

Bjarne Stroustrup (1:32:32.560)

Well, I think that languages should be designed not by clobbering language features together and

Lex Fridman (1:32:42.400)

and doing slightly different versions of somebody else's ideas, but through the creation of a set of

Bjarne Stroustrup (1:32:53.120)

principles, rules of thumbs, whatever you call them. I made them for C++. And we're trying to

Bjarne Stroustrup (1:33:02.560)

teach people in the standards committee about these rules, because a lot of people come in

Lex Fridman (1:33:07.120)

and says, I've got a great idea. Let's put it in the language. And then you have to ask, why does

Bjarne Stroustrup (1:33:12.720)

it fit in the language? Why does it fit in this language? It may fit in another language and not

Bjarne Stroustrup (1:33:18.240)

here, or it may fit here and not the other language. So you have to work from a set of

Bjarne Stroustrup (1:33:23.520)

principles and you have to develop that set of principles. And one example that I sometimes

Bjarne Stroustrup (1:33:33.920)

remember is I was sitting down with some of the designers of Common Lisp and we were talking about

Bjarne Stroustrup (1:33:43.600)

languages and language features. And obviously we didn't agree about anything because, well,

Bjarne Stroustrup (1:33:50.880)

Lisp is not C++ and vice versa. It's too many parentheses. But suddenly we started making

Bjarne Stroustrup (1:33:58.160)

progress. I said, I had this problem and I developed it according to these ideas. And

Bjarne Stroustrup (1:34:06.560)

they said, why? We had that problem, different problem, and we developed it with the same kind

Bjarne Stroustrup (1:34:11.680)

of principles. And so we worked through large chunks of C++ and large chunks of Common Lisp

Lex Fridman (1:34:21.440)

and figured out we actually had similar sets of principles of how to do it. But the constraints

Bjarne Stroustrup (1:34:29.840)

on our designs were very different and the aims for the usage was very different. But there was

Bjarne Stroustrup (1:34:37.600)

commonality in the way you reason about language features and the fundamental principles you are

Bjarne Stroustrup (1:34:45.200)

trying to do. So do you think that's possible? So there, just like there is perhaps a unified

Bjarne Stroustrup (1:34:52.240)

theory of physics, of the fundamental forces of physics, that I'm sure there is commonalities

Bjarne Stroustrup (1:35:00.880)

among the languages, but there's also people involved that help drive the development of these

Bjarne Stroustrup (1:35:06.960)

languages. Do you have a hope or an optimism that there will be a unification? If you think about

Lex Fridman (1:35:16.880)

physics and Einstein towards a simplified language, do you think that's possible?

Bjarne Stroustrup (1:35:24.560)

Let's remember sort of modern physics, I think, started with Galileo in the 1300s. So they've had

Bjarne Stroustrup (1:35:32.640)

700 years to get going. Modern computing started in about 49. We've got, what is it, 70 years. They

Bjarne Stroustrup (1:35:43.920)

have 10 times. Furthermore, they are not as bothered with people using physics the way

Bjarne Stroustrup (1:35:52.640)

we are worried about programming is done by humans. So each have problems and constraints

Bjarne Stroustrup (1:36:01.680)

the others have, but we are very immature compared to physics. So I would look at sort of the

Bjarne Stroustrup (1:36:09.680)

philosophical level and look for fundamental principles. Like you don't leak resources,

Bjarne Stroustrup (1:36:18.080)

you shouldn't. You don't take errors at runtime that you don't need to. You don't violate some

Bjarne Stroustrup (1:36:29.280)

kind of type system. There's many kinds of type systems, but when you have one, you don't break it,

Bjarne Stroustrup (1:36:35.760)

etc., etc. There will be quite a few, and it will not be the same for all languages. But I think

Bjarne Stroustrup (1:36:44.560)

if we step back at some kind of philosophical level, we would be able to agree on sets of

Bjarne Stroustrup (1:36:52.000)

principles that applied to sets of problem areas. And within an area of use, like in C++'s case,

Lex Fridman (1:37:05.280)

what used to be called systems programming, the area between the hardware and the fluffier parts

Bjarne Stroustrup (1:37:12.480)

of the system, you might very well see a convergence. So these days you see Rust having

Bjarne Stroustrup (1:37:19.200)

adopted RAII and sometimes accuse me for having borrowed it 20 years before they discovered it.

Lex Fridman (1:37:27.120)

But we're seeing some kind of convergence here instead of relying on garbage collection all the

Bjarne Stroustrup (1:37:38.080)

time. The garbage collection languages are doing things like the dispose patterns and such that

Bjarne Stroustrup (1:37:46.160)

imitate some of the construction destruction stuff. And they're trying not to use the garbage

Bjarne Stroustrup (1:37:52.480)

collection all the time and things like that. So there's a conversion. But I think we have to step

Bjarne Stroustrup (1:37:58.320)

back to the philosophical level, agree on principles, and then we'll see some conversions,

Lex Fridman (1:38:04.320)

convergences. And it will be application domain specific.

Lex Fridman (1:38:10.720)

So a crazy question, but I work a lot with machine learning, with deep learning. I'm not sure if you

Bjarne Stroustrup (1:38:16.560)

touch that world that much, but you could think of programming as a thing that takes some input.

Bjarne Stroustrup (1:38:24.480)

A programming is the task of creating a program and a program takes some input and produces some

Bjarne Stroustrup (1:38:29.120)

output. So machine learning systems train on data in order to be able to take an input and produce

Bjarne Stroustrup (1:38:37.600)

output. But they're messy, fuzzy things, much like we as children grow up. We take some input,

Bjarne Stroustrup (1:38:48.640)

we make some output, but we're noisy. We mess up a lot. We're definitely not reliable. Biological

Bjarne Stroustrup (1:38:53.760)

system are a giant mess. So there's a sense in which machine learning is a kind of way of

Bjarne Stroustrup (1:39:01.120)

programming, but just fuzzy. It's very, very, very different than C++. Because C++ is just like you

Bjarne Stroustrup (1:39:11.360)

said, it's extremely reliable, it's efficient, you can measure it, you can test it in a bunch of

Bjarne Stroustrup (1:39:18.240)

different ways. With biological systems or machine learning systems, you can't say much except sort

Bjarne Stroustrup (1:39:26.080)

of empirically saying that 99.8% of the time, it seems to work. What do you think about this fuzzy

Lex Fridman (1:39:34.400)

kind of programming? Do you even see it as programming? Is it totally another kind of world?

Bjarne Stroustrup (1:39:41.760)

I think it's a different kind of world. And it is fuzzy. And in my domain, I don't like fuzziness.

Bjarne Stroustrup (1:39:48.640)

That is, people say things like they want everybody to be able to program. But I don't

Bjarne Stroustrup (1:39:56.560)

want everybody to program my airplane controls or the car controls. I want that to be done by

Bjarne Stroustrup (1:40:06.400)

engineers. I want that to be done with people that are specifically educated and trained for doing

Bjarne Stroustrup (1:40:13.520)

building things. And it is not for everybody. Similarly, a language like C++ is not for

Bjarne Stroustrup (1:40:20.400)

everybody. It is generated to be a sharp and effective tool for professionals, basically,

Lex Fridman (1:40:30.240)

and definitely for people who aim at some kind of precision. You don't have people doing

Bjarne Stroustrup (1:40:37.680)

calculations without understanding math. Counting on your fingers is not going to cut it if you want

Bjarne Stroustrup (1:40:44.560)

to fly to the moon. And so there are areas where an 84% accuracy rate, 16% false positive rate,

Bjarne Stroustrup (1:40:56.560)

is perfectly acceptable and where people will probably get no more than 70. You said 98%. What

Bjarne Stroustrup (1:41:09.360)

I have seen is more like 84. And by really a lot of blood, sweat, and tears, you can get up to 92.5.

Lex Fridman (1:41:16.320)

So this is fine if it is, say, prescreening stuff before the human look at it. It is not good enough

Bjarne Stroustrup (1:41:27.920)

for life threatening situations. And so there's lots of areas where the fuzziness is perfectly

Bjarne Stroustrup (1:41:36.000)

acceptable and good and better than humans, cheaper than humans, cheaper than humans.

Lex Fridman (1:41:40.400)

But it's not the kind of engineering stuff I'm mostly interested in. I worry a bit about

Bjarne Stroustrup (1:41:48.000)

machine learning in the context of cars. You know much more about this than I do.

Bjarne Stroustrup (1:41:53.200)

I worry too.

Lex Fridman (1:41:54.160)

But I'm sort of an amateur here. I've read some of the papers, but I've not ever done it. And the

Bjarne Stroustrup (1:42:02.880)

idea that scares me the most is the one I have heard, and I don't know how common it is, that

Bjarne Stroustrup (1:42:14.640)

you have this AI system, machine learning, all of these trained neural nets. And when there's

Bjarne Stroustrup (1:42:24.960)

something that's too complicated, they ask the human for help. But the human is reading a book or

Bjarne Stroustrup (1:42:32.560)

asleep, and he has 30 seconds or three seconds to figure out what the problem was that the AI

Bjarne Stroustrup (1:42:41.040)

system couldn't handle and do the right thing. This is scary. I mean, how do you do the cutting

Bjarne Stroustrup (1:42:48.400)

work between the machine and the human? It's very, very difficult. And for the designer of

Bjarne Stroustrup (1:42:58.000)

one of the most reliable, efficient, and powerful programming languages, C++, I can understand why

Bjarne Stroustrup (1:43:05.120)

that world is actually unappealing. It is for most engineers. To me, it's extremely

Bjarne Stroustrup (1:43:11.920)

appealing because we don't know how to get that interaction right. But I think it's possible. But

Bjarne Stroustrup (1:43:18.080)

it's very, very hard. It is. And I was stating a problem, not a solution. That is impossible.

Bjarne Stroustrup (1:43:24.320)

I mean, I would much rather never rely on the human. If you're driving a nuclear reactor,

Bjarne Stroustrup (1:43:29.120)

if you're or an autonomous vehicle, it's much better to design systems written in C++ than

Bjarne Stroustrup (1:43:35.920)

never ask human for help. Let's just get one fact in. Yeah. All of this AI stuff is on top of C++.

Lex Fridman (1:43:47.760)

So that's one reason I have to keep a weather eye out on what's going on in that field. But

Bjarne Stroustrup (1:43:53.360)

I will never become an expert in that area. But it's a good example of how you separate

Bjarne Stroustrup (1:43:58.400)

different areas of applications and you have to have different tools, different principles. And

Bjarne Stroustrup (1:44:05.920)

then they interact. No major system today is written in one language. And there are good

Bjarne Stroustrup (1:44:11.200)

reasons for that. When you look back at your life work, what is a moment? What is a

Bjarne Stroustrup (1:44:20.800)

event creation that you're really proud of? They say, damn, I did pretty good there.

Bjarne Stroustrup (1:44:29.040)

Is it as obvious as the creation of C++? It's obvious. I've spent a lot of time with C++. And

Bjarne Stroustrup (1:44:37.920)

there's a combination of a few good ideas, a lot of hard work, and a bit of work that I've done.

Lex Fridman (1:44:43.120)

And I've tried to get away from it a few times, but I get dragged in again, partly because I'm

Bjarne Stroustrup (1:44:50.800)

most effective in this area and partly because what I do has much more impact if I do it in

Bjarne Stroustrup (1:44:58.400)

the context of C++. I have four and a half million people that pick it up tomorrow if I

Bjarne Stroustrup (1:45:05.120)

get something right. If I did it in another field, I would have to start learning, then I have to

Bjarne Stroustrup (1:45:13.840)

build it and then we'll see if anybody wants to use it. One of the things that has kept me going

Bjarne Stroustrup (1:45:21.760)

for all of these years is one, the good things that people do with it and the interesting things

Bjarne Stroustrup (1:45:29.280)

they do with it. And also, I get to see a lot of interesting stuff and talk to a lot of interesting

Bjarne Stroustrup (1:45:36.160)

people. I mean, if it has just been statements on paper on a screen, I don't think I could have kept

Bjarne Stroustrup (1:45:46.400)

going. But I get to see the telescopes up on Mauna Kea and I actually went and see how Ford built

Bjarne Stroustrup (1:45:54.400)

cars and I got to JPL and see how they do the Mars rovers. There's so much cool stuff going on. And

Bjarne Stroustrup (1:46:05.440)

most of the cool stuff is done by pretty nice people and sometimes in very nice places.

Bjarne Stroustrup (1:46:10.480)

Cambridge, Sophia, Silicon Valley. There's more to it than just code. But code is central.

Bjarne Stroustrup (1:46:25.360)

On top of the code are the people in very nice places. Well, I think I speak for millions of

Bjarne Stroustrup (1:46:32.480)

people, Yaron, in saying thank you for creating this language that so many systems are built on

Bjarne Stroustrup (1:46:40.800)

top of that make a better world. So thank you and thank you for talking today. Yeah, thanks.

Lex Fridman (1:46:47.360)

And we'll make it even better. Good.

Bjarne Stroustrup (20:04.240)

away out the clever bits and see if it still runs fast. And sometimes it runs faster. So I need the

Bjarne Stroustrup (20:13.360)

abstraction mechanisms or something like C++ to write compact high performance code. There was a

Bjarne Stroustrup (20:20.960)

beautiful keynote by Jason Turner at the CppCon a couple of years ago where he decided he was going

Bjarne Stroustrup (20:27.680)

to program Pong on Motorola 6800, I think it was. And he says, well, this is relevant because it

Bjarne Stroustrup (20:40.320)

looks like a microcontroller. It has specialized hardware. It has not very much memory and it's

Bjarne Stroustrup (20:46.400)

relatively slow. And so he shows in real time how he writes Pong starting with fairly straightforward

Bjarne Stroustrup (20:56.000)

low level stuff, improving his abstractions and what he's doing. He's writing C++ and it translates

Bjarne Stroustrup (21:06.560)

into 86 assembler, which you can do with Clang and you can see it in real time. It's

Bjarne Stroustrup (21:14.640)

the compiler explorer, which you can use on the web. And then he wrote a little program

Bjarne Stroustrup (21:19.360)

that translated 86 assembler into Motorola assembler. And so he types and you can see this

Bjarne Stroustrup (21:27.840)

thing in real time. Wow. You can see it in real time. And even if you can't read the assembly code,

Bjarne Stroustrup (21:33.840)

you can just see it. His code gets better. The code, the assembler gets smaller.

Lex Fridman (21:39.600)

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

Bjarne Stroustrup (21:45.440)

This code gets cleaner. It gets easier maintainable. The code shrinks and it keeps shrinking. And

Bjarne Stroustrup (21:55.120)

I could not in any reasonable amount of time write that assembler as good as the compiler

Bjarne Stroustrup (22:02.240)

generated from really quite nice modern C++. And I'll go as far as to say the thing that looked

Bjarne Stroustrup (22:09.360)

like C was significantly uglier and smaller and larger when it became machine code.

Lex Fridman (22:22.160)

So the abstractions that can be optimized are important.

Lex Fridman (22:27.280)

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

Bjarne Stroustrup (22:30.880)

Yeah. That might be beautiful.

Lex Fridman (22:31.920)

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

Bjarne Stroustrup (22:38.000)

Right. So that's C and C++.

Lex Fridman (22:40.240)

So my two languages would be machine code and C++. And then I think you can learn a

Bjarne Stroustrup (22:47.120)

lot from the functional languages. So PIC has gloy ML. I don't care which. I think actually

Bjarne Stroustrup (22:54.800)

you learn the same lessons of expressing especially mathematical notions really clearly

Lex Fridman (23:03.200)

and having a type system that's really strict. And then you should probably have a language for sort

Bjarne Stroustrup (23:11.520)

of quickly churning out something. You could pick JavaScript. You could pick Python. You could pick

Bjarne Stroustrup (23:19.280)

Ruby. What do you make of JavaScript in general? So you're talking in the platonic sense about

Bjarne Stroustrup (23:26.800)

languages, about what they're good at, what their philosophy of design is. But there's also a large

Bjarne Stroustrup (23:32.880)

user base behind each of these languages and they use it in the way sometimes maybe it wasn't

Bjarne Stroustrup (23:38.400)

really designed for. That's right. JavaScript is used way beyond probably what it was designed for.

Bjarne Stroustrup (23:44.240)

Let me say it this way. When you build a tool, you do not know how it's going to be used.

Bjarne Stroustrup (23:49.440)

You try to improve the tool by looking at how it's being used and when people cut their fingers

Bjarne Stroustrup (23:55.200)

off and try and stop that from happening. But really you have no control over how something

Bjarne Stroustrup (24:01.360)

is used. So I'm very happy and proud of some of the things C++ is being used at and some of the

Bjarne Stroustrup (24:07.840)

things I wish people wouldn't do. Bitcoin mining being my favorite example uses as much energy as

Bjarne Stroustrup (24:15.120)

Switzerland and mostly serves criminals. But back to the languages, I actually think that having

Bjarne Stroustrup (24:25.440)

JavaScript run in the browser was an enabling thing for a lot of things. Yes, you could have

Bjarne Stroustrup (24:33.440)

done it better, but people were trying to do it better and they were using more principles,

Bjarne Stroustrup (24:41.520)

language designs, but they just couldn't do it right. And the nonprofessional programmers that

Bjarne Stroustrup (24:49.280)

write lots of that code just couldn't understand them. So it did an amazing job for what it was.

Bjarne Stroustrup (24:58.640)

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

Lex Fridman (25:05.200)

let's not be bigots here. So what was the origin story of C++?

Bjarne Stroustrup (25:10.400)

Yeah, you basically gave a few perspectives of your inspiration of object oriented programming.

Lex Fridman (25:19.280)

That's you had a connection with C and performance efficiency was an important

Bjarne Stroustrup (25:24.400)

thing you were drawn to. Efficiency and reliability. Reliability. You have to get both.

Bjarne Stroustrup (25:30.720)

What's reliability? I really want my telephone calls to get through and I want the quality

Bjarne Stroustrup (25:38.640)

of what I am talking, coming out at the other end. The other end might be in London or wherever.

Lex Fridman (25:48.400)

And you don't want the system to be crashing. If you're doing a bank, you mustn't crash. It might

Bjarne Stroustrup (25:55.760)

be your bank account that is in trouble. There's different constraints like in games, it doesn't

Lex Fridman (26:02.640)

matter too much if there's a crash, nobody dies and nobody gets ruined.

Lex Fridman (26:06.560)

But I am interested in the combination of performance, partly because of sort of speed

Bjarne Stroustrup (26:14.560)

of things being done, part of being able to do things that is necessary to have reliability

Bjarne Stroustrup (26:24.320)

of larger systems. If you spend all your time interpreting a simple function call,

Bjarne Stroustrup (26:32.560)

a simple function call, you are not going to have enough time to do proper signal processing to get

Bjarne Stroustrup (26:39.280)

the telephone calls to sound right. Either that or you have to have ten times as many computers

Lex Fridman (26:46.000)

and you can't afford your phone anymore. It's a ridiculous idea in the modern world because

Bjarne Stroustrup (26:51.760)

we have solved all of those problems. I mean, they keep popping up in different ways because

Bjarne Stroustrup (26:58.160)

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

Lex Fridman (27:03.120)

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

Bjarne Stroustrup (27:09.680)

important things. And one of the things it enables is reliability, is dependability.

Bjarne Stroustrup (27:18.720)

When I press the pedal, the brake pedal of a car, it is not actually connected directly

Lex Fridman (27:24.800)

to anything but a computer. That computer better work.

Bjarne Stroustrup (27:31.680)

Let's talk about reliability just a little bit. So modern cars have ECUs, have millions of lines

Bjarne Stroustrup (27:39.520)

of code today. So this is certainly especially true of autonomous vehicles where some of the

Bjarne Stroustrup (27:46.560)

aspects of the control or driver assistance systems that steer the car, that keep it in the

Bjarne Stroustrup (27:50.720)

lane and so on. So how do you think, you know, I talked to regulators, people in government

Bjarne Stroustrup (27:56.800)

who are very nervous about testing the safety of these systems of software. Ultimately software

Lex Fridman (28:03.360)

that makes decisions that could lead to fatalities. So how do we test software systems like these?

Bjarne Stroustrup (28:11.920)

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

Bjarne Stroustrup (28:21.840)

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

Bjarne Stroustrup (28:28.800)

That's all right. I don't need to do that. Yeah, that piece of code is secure. I'll buy

Bjarne Stroustrup (28:34.480)

your operator. If you want to have reliability, if you want to have performance, if you want to

Bjarne Stroustrup (28:41.600)

have security, you have to look at the whole system. I did not expect you to say that,

Lex Fridman (28:46.640)

but that's very true. Yes, I'm dealing with one part of the system and I want my part to be really

Bjarne Stroustrup (28:52.480)

good, but I know it's not the whole system. Furthermore, if making an individual part perfect,

Bjarne Stroustrup (29:00.320)

may actually not be the best way of getting the highest degree of reliability and performance and

Bjarne Stroustrup (29:05.680)

such. There's people that say C++ is not type safe. You can break it. Sure. I can break anything

Bjarne Stroustrup (29:14.080)

that runs on a computer. I may not go through your type system. If I wanted to break into your

Bjarne Stroustrup (29:20.800)

computer, I'll probably try SQL injection. And it's very true. If you think about

Bjarne Stroustrup (29:26.400)

safety or even reliability at the system level, especially when a human being is involved,

Bjarne Stroustrup (29:34.080)

it starts becoming hopeless pretty quickly in terms of proving that something is

Bjarne Stroustrup (29:43.840)

safe to a certain level. Yeah. Because there's so many variables. It's so complex. Well, let's get

Bjarne Stroustrup (29:48.800)

back to something we can talk about and actually talk about it. Yeah.

Bjarne Stroustrup (29:54.000)

Talk about and actually make some progress on. Yes. We can look at C++ programs and we can

Bjarne Stroustrup (30:01.680)

try and make sure they crash this often. The way you do that is largely by simplification.

Bjarne Stroustrup (30:14.640)

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

Bjarne Stroustrup (30:21.440)

It's not by runtime testing everything. It is not by big test frameworks that you are using.

Bjarne Stroustrup (30:28.960)

Yes, we do that also. But the first step is actually to make sure that when you want to

Bjarne Stroustrup (30:35.600)

express something, you can express it directly in code rather than going through endless loops

Lex Fridman (30:43.120)

and convolutions in your head before it gets down the code. The way you are thinking about

Bjarne Stroustrup (30:51.360)

a problem is not in the code. There is a missing piece that's just in your head. And the code,

Bjarne Stroustrup (30:59.360)

you can see what it does, but it cannot see what you thought about it unless you have expressed

Bjarne Stroustrup (31:05.920)

things directly. When you express things directly, you can maintain it. It's easier to find errors.

Bjarne Stroustrup (31:13.120)

It's easier to make modifications. It's actually easier to test it. And lo and behold, it runs

Bjarne Stroustrup (31:19.280)

faster. And therefore, you can use a smaller number of computers, which means there's less

Lex Fridman (31:26.720)

hardware that could possibly break. So I think the key here is simplification.

Lex Fridman (31:34.000)

But it has to be, to use the Einstein quote, as simple as possible and no simpler.

Lex Fridman (31:40.080)

Not simpler.

Bjarne Stroustrup (31:41.600)

There are other areas with under constraints where you can be simpler than you can be in C++.

Lex Fridman (31:46.880)

But in the domain I'm dealing with, that's the simplification I'm after.

Lex Fridman (31:53.360)

So how do you inspire or ensure that the Einstein level of simplification is reached?

Lex Fridman (32:03.280)

So can you do code review? Can you look at code? If I gave you the code for the Ford F150

Lex Fridman (32:11.840)

and said, here, is this a mess or is this okay? Is it possible to tell? Is it possible to regulate?

Bjarne Stroustrup (32:23.040)

An experienced developer can look at code and see if it smells. Mixed metaphors deliberately.

Bjarne Stroustrup (32:31.680)

Yes. The point is that it is hard to generate something that is really obviously clean and

Bjarne Stroustrup (32:46.880)

can be appreciated. But you can usually recognize when you haven't reached that point.

Lex Fridman (32:52.160)

And so I've never looked at the F150 code, so I wouldn't know. But I know what I ought to be

Bjarne Stroustrup (33:03.360)

looking for. I'll be looking for some tricks that correlate with bugs and elsewhere. And I have tried

Bjarne Stroustrup (33:12.080)

to formulate rules for what good code looks like. And the current version of that is called the C++

Bjarne Stroustrup (33:22.480)

core guidelines. One thing people should remember is there's what you can do in a language and what

Bjarne Stroustrup (33:32.240)

you should do. In a language, you have lots of things that is necessary in some context,

Lex Fridman (33:39.600)

but not in others. There's things that exist just because there's 30 year old code out there and

Bjarne Stroustrup (33:45.680)

you can't get rid of it. But you can't have rules that says when you create it, try and follow these

Bjarne Stroustrup (33:51.200)

rules. This does not create good programs by themselves, but it limits the damage from mistakes.

Bjarne Stroustrup (34:02.480)

It limits the possibilities of mistakes. And basically, we are trying to say, what is it that

Bjarne Stroustrup (34:08.960)

a good programmer does? At the fairly simple level of where you use the language and how you use it.

Bjarne Stroustrup (34:16.240)

Now, I can put all the rules for chiseling in marble. It doesn't mean that somebody who follows

Bjarne Stroustrup (34:24.640)

all of those rules can do a masterpiece by Michelangelo. That is, there's something else

Bjarne Stroustrup (34:32.160)

to write a good program. Just is there something else to create an important work of art? That is,

Bjarne Stroustrup (34:40.640)

there's some kind of inspiration, understanding, gift. But we can approach the sort of technical,

Bjarne Stroustrup (34:53.920)

the craftsmanship level of it. The famous painters, the famous sculptures was among other things,

Bjarne Stroustrup (35:03.440)

superb craftsmen. They could express their ideas using their tools very well. And so these days,

Bjarne Stroustrup (35:14.320)

I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is

Bjarne Stroustrup (35:20.000)

to use our tools very well. For a really good piece of code, you need a spark of inspiration,

Lex Fridman (35:29.280)

and you can't, I think, regulate that. You cannot say that I'll take a picture only,

Bjarne Stroustrup (35:37.200)

I'll buy your picture only if you're at least Van Gogh. There are other things you can regulate,

Lex Fridman (35:45.600)

but not the inspiration. I think that's quite beautifully put. It is true that there is as an

Bjarne Stroustrup (35:55.200)

experienced programmer, when you see code that's inspired, that's like Michelangelo, you know it

Bjarne Stroustrup (36:04.640)

when you see it. And the opposite of that is code that is messy, code that smells, you know,

Bjarne Stroustrup (36:12.240)

when you see it. And I'm not sure you can describe it in words, except vaguely through guidelines and

Lex Fridman (36:17.760)

so on. Yes, it's easier to recognize ugly than to recognize beauty in code. And for the reason is

Bjarne Stroustrup (36:27.040)

that sometimes beauty comes from something that's innovative and unusual. And you have to sometimes

Bjarne Stroustrup (36:34.000)

think reasonably hard to appreciate that. On the other hand, the messes have things that are

Lex Fridman (36:41.040)

in common. And you can have static checkers and dynamic checkers that find

Bjarne Stroustrup (36:52.080)

a large number of the most common mistakes. You can catch a lot of sloppiness mechanically. I'm

Bjarne Stroustrup (37:02.400)

a great fan of static analysis in particular, because you can check for not just the language

Bjarne Stroustrup (37:09.920)

rules, but for the usage of language rules. And I think we will see much more static analysis

Bjarne Stroustrup (37:16.880)

in the coming decade. Can you describe what static analysis is? You represent a piece of code

Lex Fridman (37:25.840)

so that you can write a program that goes over that representation and look for things that are

Lex Fridman (37:33.760)

are right and not right. So, for instance, you can analyze a program to see if

Bjarne Stroustrup (37:46.000)

resources are leaked. That's one of my favorite problems. It's not actually all that hard and

Bjarne Stroustrup (37:54.240)

modern C++, but you can do it. If you are writing in the C level, you have to have a malloc and a

Bjarne Stroustrup (38:00.320)

free. And they have to match. If you have them in a single function, you can usually do it very

Bjarne Stroustrup (38:08.880)

easily. If there's a malloc here, there should be a free there. On the other hand, in between can be

Bjarne Stroustrup (38:16.320)

showing complete code and then it becomes impossible. If you pass that pointer to the

Bjarne Stroustrup (38:22.000)

memory out of a function and then want to make sure that the free is done somewhere else,

Bjarne Stroustrup (38:31.600)

now it gets really difficult. And so for static analysis, you can run through a program and you

Bjarne Stroustrup (38:38.000)

can try and figure out if there's any leaks. And what you will probably find is that you will find

Bjarne Stroustrup (38:47.120)

some leaks and you'll find quite a few places where your analysis can't be complete. It might

Bjarne Stroustrup (38:54.240)

depend on runtime. It might depend on the cleverness of your analyzer and it might take a

Bjarne Stroustrup (39:02.880)

long time. Some of these programs run for a long time. But if you combine such analysis

Bjarne Stroustrup (39:11.120)

with a set of rules that says how people could use it, you can actually see why the rules are

Bjarne Stroustrup (39:17.120)

violated. And that stops you from getting into the impossible complexities. You don't want to

Bjarne Stroustrup (39:25.040)

solve the halting problem. So static analysis is looking at the code without running the code.

Bjarne Stroustrup (39:31.040)

Yes. And thereby it's almost not a production code, but it's almost like an education tool

Bjarne Stroustrup (39:38.880)

of how the language should be used. It guides you like it at its best, right? It would

Bjarne Stroustrup (39:45.440)

guide you in how you write future code as well. And you learn together.

Bjarne Stroustrup (39:50.320)

Yes. So basically you need a set of rules for how you use the language. Then you need a static

Bjarne Stroustrup (39:56.400)

analysis that catches your mistakes when you violate the rules or when your code ends up

Bjarne Stroustrup (40:05.120)

doing things that it shouldn't, despite the rules, because there is the language rules.

Bjarne Stroustrup (40:09.200)

We can go further. And again, it's back to my idea that I'd much rather find errors before

Bjarne Stroustrup (40:16.000)

I start running the code. If nothing else, once the code runs, if it catches an error at run times,

Bjarne Stroustrup (40:23.280)

I have to have an error handler. And one of the hardest things to write in code is error handling

Lex Fridman (40:30.160)

code, because you know something went wrong. Do you know really exactly what went wrong?

Bjarne Stroustrup (40:36.640)

Usually not. How can you recover when you don't know what the problem was? You can't be 100% sure

Lex Fridman (40:42.960)

what the problem was in many, many cases. And this is part of it. So yes, we need good languages,

Bjarne Stroustrup (40:52.480)

we need good type systems, we need rules for how to use them, we need static analysis. And the

Bjarne Stroustrup (41:02.240)

ultimate for static analysis is of course program proof, but that still doesn't scale to the kind

Bjarne Stroustrup (41:08.320)

of systems we deploy. Then we start needing testing and the rest of the stuff.

Lex Fridman (41:15.200)

So C++ is an object oriented programming language that creates, especially with its newer versions,

Lex Fridman (41:22.960)

as we'll talk about, higher and higher levels of abstraction. So how do you design?

Bjarne Stroustrup (41:30.400)

Let's even go back to the origin of C++. How do you design something with so much abstraction

Bjarne Stroustrup (41:35.040)

that's still efficient and is still something that you can manage, do static analysis on,

Bjarne Stroustrup (41:45.200)

you can have constraints on, they can be reliable, all those things we've talked about.

Bjarne Stroustrup (41:50.480)

To me, there's a slight tension between high level abstraction and efficiency.

Bjarne Stroustrup (41:59.440)

That's a good question. I could probably have a year's course just trying to answer it.

Bjarne Stroustrup (42:06.080)

Yes, there's a tension between efficiency and abstraction, but you also get the interesting

Bjarne Stroustrup (42:13.200)

situation that you get the best efficiency out of the best abstraction. And my main tool

Bjarne Stroustrup (42:21.600)

for efficiency for performance actually is abstraction. So let's go back to how C++ was

Bjarne Stroustrup (42:28.320)

got there. You said it was object oriented programming language. I actually never said that.

Bjarne Stroustrup (42:35.040)

It's always quoted, but I never did. I said C++ supports object oriented programming and other

Bjarne Stroustrup (42:42.880)

techniques. And that's important because I think that the best solution to most complex,

Bjarne Stroustrup (42:51.520)

interesting problems require ideas and techniques from things that has been called object oriented

Bjarne Stroustrup (43:02.880)

data abstraction, functional, traditional C style code, all of the above. And so when I was designing

Bjarne Stroustrup (43:14.960)

C++, I soon realized I couldn't just add features. If you just add what looks pretty or what people

Bjarne Stroustrup (43:24.560)

ask for or what you think is good, one by one, you're not going to get a coherent whole. What

Bjarne Stroustrup (43:32.080)

you need is a set of guidelines that that guides your decisions. Should this feature be in or should

Lex Fridman (43:40.560)

this feature be out? How should a feature be modified before it can go in and such?

Lex Fridman (43:48.640)

And in the book I wrote about that, the design evolution of C++, there's a whole bunch of rules

Bjarne Stroustrup (43:56.080)

like that. Most of them are not language technical. They're things like don't violate static type

Bjarne Stroustrup (44:04.400)

system because I like static type system for the obvious reason that I like things to be reliable

Bjarne Stroustrup (44:12.480)

on reasonable amounts of hardware. But one of these rules is the zero overhead principle.

Lex Fridman (44:21.280)

The what kind of principle?

Lex Fridman (44:22.000)

The zero overhead principle. It basically says that if you have an abstraction,

Bjarne Stroustrup (44:29.600)

it should not cost anything compared to write the equivalent code at a lower level.

Lex Fridman (44:38.960)

So if I have, say, a matrix multiply, it should be written in such a way that you could not drop to

Bjarne Stroustrup (44:50.000)

the C level of abstraction and use arrays and pointers and such and run faster.

Lex Fridman (44:54.800)

And so people have written such matrix multiplications, and they've actually gotten

Bjarne Stroustrup (45:01.920)

code that ran faster than Fortran because once you had the right abstraction, you can eliminate

Bjarne Stroustrup (45:08.640)

temporaries and you can do loop fusion and other good stuff like that. That's quite hard to do by

Bjarne Stroustrup (45:16.560)

hand and in a lower level language. And there's some really nice examples of that.

Lex Fridman (45:21.600)

And the key here is that that matrix multiplication, the matrix abstraction,

Bjarne Stroustrup (45:29.120)

allows you to write code that's simple and easy. You can do that in any language.

Lex Fridman (45:34.000)

But with C++, it has the features so that you can also have this thing run faster than if you hand

Bjarne Stroustrup (45:39.840)

coded it. Now, people have given that lecture many times, I and others, and a very common

Bjarne Stroustrup (45:47.680)

question after the talk where you have demonstrated that you can outperform Fortran for

Bjarne Stroustrup (45:52.800)

dense matrix multiplication, people come up and says, yeah, but that was C++.

Bjarne Stroustrup (45:57.680)

If I rewrote your code in C, how much faster would it run? The answer is much slower.

Bjarne Stroustrup (46:06.080)

This happened the first time actually back in the 80s with a friend of mine called Doug McElroy,

Bjarne Stroustrup (46:11.920)

who demonstrated exactly this effect. And so the principle is you should give programmers the tools

Lex Fridman (46:22.080)

so that the abstractions can follow the zero void principle. Furthermore, when you put in a language

Bjarne Stroustrup (46:28.560)

feature in C++ or a standard library feature, you try to meet this. It doesn't mean it's absolutely

Bjarne Stroustrup (46:35.680)

optimal, but it means if you hand code it with the usual facilities in the language in C++ in C,

Bjarne Stroustrup (46:45.040)

you should not be able to better it. Usually you can do better if you use embedded assembler for

Bjarne Stroustrup (46:53.360)

machine code for some of the details to utilize part of a computer that the compiler doesn't know

Bjarne Stroustrup (47:00.000)

about. But you should get to that point before you beat to the abstraction. So that's a beautiful

Bjarne Stroustrup (47:06.880)

ideal to reach for. And we meet it quite often. Quite often. So where's the magic of that coming

Bjarne Stroustrup (47:14.640)

from? There's some of it is the compilation process. So the implementation of C++, some of it

Bjarne Stroustrup (47:20.560)

is the design of the feature itself, the guidelines. So I think it's important that you

Bjarne Stroustrup (47:27.280)

think about the guidelines. So I've recently and often talked to Chris Latner, so Clang.

Bjarne Stroustrup (47:36.320)

What, just out of curiosity, is your relationship in general with the different implementations of

Bjarne Stroustrup (47:44.160)

C++ as you think about you and committee and other people in C++, think about the design of

Bjarne Stroustrup (47:50.480)

features or design of previous features. In trying to reach the ideal of zero overhead,

Lex Fridman (47:59.840)

does the magic come from the design, the guidelines, or from the implementations?

Lex Fridman (48:06.480)

And not all. You go for programming technique,

Bjarne Stroustrup (48:13.840)

programming language features, and implementation techniques. You need all three.

Lex Fridman (48:18.000)

And how can you think about all three at the same time?

Bjarne Stroustrup (48:22.640)

It takes some experience, takes some practice, and sometimes you get it wrong. But after a while,

Bjarne Stroustrup (48:28.160)

you sort of get it right. I don't write compilers anymore. But Brian Kernighan pointed out that one

Bjarne Stroustrup (48:37.840)

of the reasons C++ succeeded was some of the craftsmanship I put into the early compilers.

Lex Fridman (48:49.760)

And of course, I did the language assign. Of course, I wrote a fair amount of code using

Bjarne Stroustrup (48:54.080)

this kind of stuff. And I think most of the successes involve progress in all three areas

Bjarne Stroustrup (49:02.720)

together. A small group of people can do that. Two, three people can work together to do something

Bjarne Stroustrup (49:10.400)

like that. It's ideal if it's one person that has all the skills necessary. But nobody has all the

Bjarne Stroustrup (49:16.160)

skills necessary in all the fields where C++ is used. So if you want to approach my ideal in, say,

Bjarne Stroustrup (49:23.840)

concurrent programming, you need to know about algorithms from current programming. You need to

Bjarne Stroustrup (49:30.240)

know the trigger of lock free programming. You need to know something about compiler techniques.

Lex Fridman (49:36.960)

And then you have to know some of the application areas where this is, like some forms of graphics

Bjarne Stroustrup (49:46.720)

or some forms of what we call web server kind of stuff. And that's very hard to get into a single

Bjarne Stroustrup (49:57.440)

head. But small groups can do it too. So is there differences in your view, not saying which is

Bjarne Stroustrup (50:06.800)

better or so on, but differences in the different implementations of C++? Why are there several

Bjarne Stroustrup (50:13.680)

sort of maybe naive questions for me? GCC, clang, so on? This is a very reasonable question. When

Bjarne Stroustrup (50:23.680)

I designed C++, most languages had multiple implementations. Because if you run on an IBM,

Bjarne Stroustrup (50:35.520)

if you run on a Sun, if you run on a Motorola, there was just many, many companies and they each

Bjarne Stroustrup (50:41.440)

have their own compilation structure and their own compilers. It was just fairly common that

Bjarne Stroustrup (50:47.200)

there was many of them. And I wrote C Front assuming that other people would write compilers

Bjarne Stroustrup (50:54.720)

with C++ if successful. And furthermore, I wanted to utilize all the backend infrastructures that

Bjarne Stroustrup (51:04.320)

were available. I soon realized that my users were using 25 different linkers. I couldn't write my

Bjarne Stroustrup (51:10.240)

own linker. Yes, I could, but I couldn't write 25 linkers and also get any work done on the language.

Lex Fridman (51:20.080)

And so it came from a world where there was many linkers, many optimizers, many

Bjarne Stroustrup (51:27.120)

compiler front ends, not to start, but many operating systems. The whole world was not an

Bjarne Stroustrup (51:36.080)

86 and a Linux box or something, whatever is the standard today. In the old days, they set a VAX.

Lex Fridman (51:45.040)

So basically, I assumed there would be lots of compilers. It was not a decision that there should

Bjarne Stroustrup (51:51.520)

be many compilers. It was just a fact. That's the way the world is. And yes, many compilers

Bjarne Stroustrup (52:00.400)

emerged. And today, there's at least four front ends, Clang, GCC, Microsoft, and EDG,

Bjarne Stroustrup (52:13.600)

it is design group. They supply a lot of the independent organizations and the embedded

Bjarne Stroustrup (52:21.440)

systems industry. And there's lots and lots of backends. We have to think about how many dozen

Bjarne Stroustrup (52:29.040)

backends there are. Because different machines have different things, especially in the embedded

Bjarne Stroustrup (52:35.760)

world, the machines are very different, the architectures are very different. And so having

Bjarne Stroustrup (52:43.920)

a single implementation was never an option. Now, I also happen to dislike monocultures.

Bjarne Stroustrup (52:53.120)

Monocultures.

Bjarne Stroustrup (52:54.320)

They are dangerous. Because whoever owns the monoculture can go stale. And there's no

Bjarne Stroustrup (53:01.920)

competition. And there's no incentive to innovate. There's a lot of incentive to put barriers in the

Bjarne Stroustrup (53:09.360)

way of change. Because hey, we own the world. And it's a very comfortable world for us. And who are

Bjarne Stroustrup (53:15.680)

you to mess with that? So I really am very happy that there's four front ends for C++. Clang's

Bjarne Stroustrup (53:26.400)

great. But GCC was great. But then it got somewhat stale. Clang came along. And GCC is much better

Bjarne Stroustrup (53:36.320)

now. Microsoft is much better now. So at least a low number of front ends puts a lot of pressure on

Bjarne Stroustrup (53:51.040)

standards compliance and also on performance and error messages and compile time speed,

Bjarne Stroustrup (53:57.760)

all this good stuff that we want.

Lex Fridman (53:59.360)

Do you think, crazy question, there might come along, do you hope there might come along

Lex Fridman (54:08.800)

implementation of C++ written, given all its history, written from scratch?

Lex Fridman (54:16.400)

So written today from scratch?

Bjarne Stroustrup (54:18.960)

Well, Clang and the LLVM is more or less written from scratch.

Lex Fridman (54:24.880)

But there's been C++ 11, 14, 17, 20. You know, there's been a lot of

Bjarne Stroustrup (54:30.960)

I think sooner or later somebody's going to try again. There has been attempts to write

Bjarne Stroustrup (54:36.480)

new C++ compilers and some of them has been used and some of them has been absorbed into

Bjarne Stroustrup (54:42.400)

others and such. Yeah, it'll happen.

Lex Fridman (54:45.200)

So what are the key features of C++? And let's use that as a way to sort of talk about

Bjarne Stroustrup (54:52.960)

the evolution of C++, the new features. So at the highest level, what are the features

Lex Fridman (54:59.360)

that were there in the beginning? What features got added?

Bjarne Stroustrup (55:03.200)

Let's first get a principle or an aim in place. C++ is for people who want to use hardware

Lex Fridman (55:13.600)

really well and then manage the complexity of doing that through abstraction.

Lex Fridman (55:18.720)

And so the first facility you have is a way of manipulating the machines at a fairly low

Bjarne Stroustrup (55:27.120)

level. That looks very much like C. It has loops, it has variables, it has pointers like

Bjarne Stroustrup (55:36.560)

machine addresses, it can access memory directly, it can allocate stuff in the absolute minimum

Bjarne Stroustrup (55:45.040)

of space needed on the machine. There's a machine facing part of C++ which is roughly

Bjarne Stroustrup (55:52.560)

equivalent to C. I said C++ could beat C and it can. It doesn't mean I dislike C. If I

Bjarne Stroustrup (55:59.120)

disliked C, I wouldn't have built on it. Furthermore, after Dennis Ritchie, I'm probably the major

Bjarne Stroustrup (56:07.760)

contributor to modern C. I had lunch with Dennis most days for 16 years and we never

Bjarne Stroustrup (56:18.160)

had a harsh word between us. So these C versus C++ fights are for people who don't quite

Bjarne Stroustrup (56:26.960)

understand what's going on. Then the other part is the abstraction. The key is the class.

Bjarne Stroustrup (56:34.800)

There, the key is the class which is a user defined type. My idea for the class is that

Bjarne Stroustrup (56:42.480)

you should be able to build a type that's just like the building types in the way you

Bjarne Stroustrup (56:48.400)

use them, in the way you declare them, in the way you get the memory and you can do

Bjarne Stroustrup (56:54.480)

just as well. So in C++ there's an int as in C. You should be able to build an abstraction,

Bjarne Stroustrup (57:03.680)

a class which we can call capital int that you can use exactly like an integer and run

Bjarne Stroustrup (57:11.360)

just as fast as an integer. There's the idea right there. And of course you probably don't

Bjarne Stroustrup (57:18.080)

want to use the int itself but it has happened. People have wanted integers that were range

Bjarne Stroustrup (57:25.600)

checked so that you couldn't overflow and such, especially for very safety critical

Bjarne Stroustrup (57:29.840)

applications like the fuel injection for a marine diesel engine for the largest ships.

Bjarne Stroustrup (57:37.040)

This is a real example by the way. This has been done. They built themselves an integer

Bjarne Stroustrup (57:43.360)

that was just like integer except that couldn't overflow. If there was an overflow you went

Bjarne Stroustrup (57:49.200)

into the error handling. And then you built more interesting types. You can build a matrix

Lex Fridman (57:56.880)

which you need to do graphics or you could build a gnome for a video game.

Lex Fridman (58:04.400)

And all these are classes and they appear just like the built in types.

Lex Fridman (58:07.760)

Exactly.

Lex Fridman (58:08.240)

In terms of efficiency and so on. So what else is there?

Lex Fridman (58:11.120)

And flexibility.

Lex Fridman (58:12.320)

So I don't know, for people who are not familiar with object oriented programming there's inheritance.

Bjarne Stroustrup (58:20.400)

There's a hierarchy of classes. You can just like you said create a generic vehicle that can turn

Bjarne Stroustrup (58:27.040)

left.

Lex Fridman (58:27.600)

So what people found was that you don't actually know. How do I say this? A lot of types are

Bjarne Stroustrup (58:40.320)

related. That is the vehicles, all vehicles are related. Bicycles, cars, fire engines, tanks. They

Bjarne Stroustrup (58:52.960)

have some things in common and some things that differ. And you would like to have the common

Bjarne Stroustrup (58:57.600)

things common and having the differences specific. And when you didn't want to know about

Bjarne Stroustrup (59:04.160)

the differences, just turn left. You don't have to worry about it. That's how you get the traditional

Bjarne Stroustrup (59:12.640)

object oriented programming coming out of Simula adopted by Smalltalk and C++ and all the other

Bjarne Stroustrup (59:19.520)

languages. The other kind of obvious similarity between types comes when you have something like

Bjarne Stroustrup (59:25.840)

a vector. Fortran gave us the vector as called array of doubles. But the minute you have a

Bjarne Stroustrup (59:35.760)

vector of doubles, you want a vector of double precision doubles and for short doubles for

Bjarne Stroustrup (59:42.720)

graphics. And why should you not have a vector of integers while you're added or a vector of

Bjarne Stroustrup (59:50.640)

vectors and a vector of vectors of chess pieces? Now you have a board, right? So this is you