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

We are standardizing C++ under ISO rules, which are very open process.

People come in, there's no requirements for education or experience.

So you've started to develop C++ and there's a

The ISO standard, is there a committee that you're referring to?

So sometime in early 1989, 2 people, 1 from IBM, 1 from HP, turned up in my office and told me I would like to standardize C++.

This was a new idea to me and I pointed out that it wasn't finished yet, it wasn't ready for formal standardization and such.

And they say, no, Bjarne, you haven't gotten it.

We cannot depend on something that's owned by another corporation that might be a competitor.

Of course, we could rely on you, but you might get run over by a bus.

We really need to get this out in the open.

It has to be standardized under formal rules and we are going to standardize it under ISO rules.

And you really want to be part of it because basically otherwise we'll do it ourselves.

So through a combination of arm twisting and flattery, It got started.

So in late, in late 89, there was a meeting in DC at the, actually no, it was not ISO then, it was ANSI, the American National Standard we were doing.

We met there, We were lectured on the rules of how to do an NC standard.

There was about 25 of us there, which apparently was a new record for that kind of meeting.

And some of the old C guys that has been standardizing C was there, so we got some expertise in.

So the way this works is that it's an open process.

Anybody can sign up if they pay the minimal fee, which is about a thousand dollars, though less than, it's a little bit more now.

We try 2 meetings a year for a couple of years that didn't work too well.

So 3 1 week meetings a year, and You meet and you have technical discussions, and then you bring proposals forward for votes.

The votes are done 1 vote per organization.

So you can't have, say, IBM come in with 10 people and dominate things.

And these are organizations that extends to the UC++?

I mean, It's a bunch of people in a room deciding the design of a language based on which a lot of the world's systems run.

Well, I think most people would agree it's better than if I decided it or better than if a single organization like AT&T decided it.

I don't know if everyone agrees to that, by the way.

Yes, they're that look, standardization is not pleasant.

But we exactly As Churchill says, democracy is the worst way except for all the others, right?

And it's, I would say, the same with formal standardization.

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

Couple of years later, we extended this so it became worldwide.

We have standard organizations that are active in currently 15 to 20 countries and another 15 to 20 are sort of looking and voting based on the rest of the work on it.

Next week I'll be in Cologne, Germany, spending a week doing standardization.

And we'll vote out the committee draft of C++ 20 which goes to the National Standards Committees for comments and requests for changes and improvements.

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

The first time we finished, we started in the first technical meeting was in 1990.

That was the standard that people used till 11 or a little bit past 11.

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

And we work on the basis of consensus, That is, we do not want something that passes 60-40, because then we're going to get dialects and opponents and people complain too much.

They all complain too much, but basically it has no real effect.

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

And so the first, it was traditional with ISO standards to take 10 years.

And we thought we were going to do the next 1 in 6 because now we are good at it.

Hoping that you would at least get it within

the single, within the odds, the single digits.

I thought we would get, I thought we would get 6, 7 or 8.

Well, the point is that this was sort of like a second system effect.

That is, we now knew how to do it, and so we were going to do it much better, and we got more ambitious.

Furthermore, there is this tendency, because it's a 10-year cycle, or 8, doesn't matter, just before you're about to ship, somebody has a bright idea.

And So we really, really must get that in.

We got the standard library that gives us all the STL stuff.

And then people tried it with other things, and it didn't work so well.

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

So after C++ 11, which was a huge improvement and basically what most people are using today, we decided never again.

And the answer is that you ship more often.

So that if you have a slip on a 10-year cycle, by the time you know it's a slip, there's 11 years till you get it.

Now with a three-year cycle, there is about 3, 4 years till you get it.

Like the delay between feature freeze and shipping.

And so we shipped 14 on time, we shipped 17 on time, and we ship, we will ship 20 on time.

And furthermore, this allow, this gives a predictability that allows the implementers, the compiler implementers, the library implementers, to they have a target and they deliver on it.

11 took 2 years for most compilers were good enough.

14, most compilers were actually getting pretty good in 14.

Well, we are going to have At least almost everybody ship almost everything in 20.

And I know this because they're shipping in 19.


Speaker 0: But get back to the standardization. We are standardizing C++ under ISO rules, which are very open process. People come in, there's no requirements for education or experience. So you've started to develop C++ and there's a

Speaker 1: hope. When was the first standard established? What is that like? The ISO standard, is there a committee that you're referring to? There's a group of people.

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

Speaker 0: I'll try and explain that. So sometime in early 1989, 2 people, 1 from IBM, 1 from HP, turned up in my office and told me I would like to standardize C++. This was a new idea to me and I pointed out that it wasn't finished yet, it wasn't ready for formal standardization and such. And they say, no, Bjarne, you haven't gotten it. You really want to do this.

Our organizations depend on C++. We cannot depend on something that's owned by another corporation that might be a competitor. Of course, we could rely on you, but you might get run over by a bus.

Speaker 1: Right. The old bus.

Speaker 0: We really need to get this out in the open. It has to be standardized under formal rules and we are going to standardize it under ISO rules. And you really want to be part of it because basically otherwise we'll do it ourselves. And we know you can do it better. So through a combination of arm twisting and flattery, It got started.

So in late, in late 89, there was a meeting in DC at the, actually no, it was not ISO then, it was ANSI, the American National Standard we were doing. We met there, We were lectured on the rules of how to do an NC standard. There was about 25 of us there, which apparently was a new record for that kind of meeting. And some of the old C guys that has been standardizing C was there, so we got some expertise in. So the way this works is that it's an open process.

Anybody can sign up if they pay the minimal fee, which is about a thousand dollars, though less than, it's a little bit more now. And I think it's $1280. It's not going to kill you. And we have 3 meetings a year. This is fairly standard.

We try 2 meetings a year for a couple of years that didn't work too well. So 3 1 week meetings a year, and You meet and you have technical discussions, and then you bring proposals forward for votes. The votes are done 1 vote per organization. So you can't have, say, IBM come in with 10 people and dominate things. That's not allowed.

Speaker 1: And these are organizations that extends to the UC++? Yes.

Speaker 0: Because it's basically... Or individuals.

Speaker 1: Or individuals. I mean, It's a bunch of people in a room deciding the design of a language based on which a lot of the world's systems run.

Speaker 0: That's right. Well, I think most people would agree it's better than if I decided it or better than if a single organization like AT&T decided it.

Speaker 1: I don't know if everyone agrees to that, by the way. Bureaucracies have their critics, too.

Speaker 0: Yes, they're that look, standardization is not pleasant. It's it's it's it's horrifying. It's like democracy. But we exactly As Churchill says, democracy is the worst way except for all the others, right? And it's, I would say, the same with formal standardization.

But anyway, so we meet and we have these votes and that determines what the standard is. Couple of years later, we extended this so it became worldwide. We have standard organizations that are active in currently 15 to 20 countries and another 15 to 20 are sort of looking and voting based on the rest of the work on it. And we meet 3 times a year. Next week I'll be in Cologne, Germany, spending a week doing standardization.

And we'll vote out the committee draft of C++ 20 which goes to the National Standards Committees for comments and requests for changes and improvements. Then we do that and there's a second set of votes where hopefully everybody votes in favor. This has happened several times. The first time we finished, we started in the first technical meeting was in 1990. The last was in 98.

We voted it out. That was the standard that people used till 11 or a little bit past 11. And it was an international standard. All the countries voted in favor. It took longer with 11, I'll mention why, but all the nations voted in favor.

And we work on the basis of consensus, That is, we do not want something that passes 60-40, because then we're going to get dialects and opponents and people complain too much. They all complain too much, but basically it has no real effect. The standards have been obeyed. They have been working to make it easier to use many compilers, many computers and all of that kind of stuff. And so the first, it was traditional with ISO standards to take 10 years.

We did the first 1 in 8. Brilliant. And we thought we were going to do the next 1 in 6 because now we are good at it. Right. It took 13.

Speaker 1: Yeah, it was named OX.

Speaker 0: It was named OX. Hoping that you would at least get it within

Speaker 1: the single, within the odds, the single digits.

Speaker 0: I thought we would get, I thought we would get 6, 7 or 8.

Speaker 1: The confidence of youth. Yeah, that's Right.

Speaker 0: Well, the point is that this was sort of like a second system effect. That is, we now knew how to do it, and so we were going to do it much better, and we got more ambitious. Ambitious. And it

Speaker 1: took longer.

Speaker 0: Furthermore, there is this tendency, because it's a 10-year cycle, or 8, doesn't matter, just before you're about to ship, somebody has a bright idea. And So we really, really must get that in. We did that successfully with the STL. We got the standard library that gives us all the STL stuff. Basically, I think it saved C++.

It was beautiful.

Speaker 1: Yeah, it

Speaker 0: was a beautiful thing. And then people tried it with other things, and it didn't work so well. They got things in, but it wasn't as dramatic, and it took longer and longer and longer. So after C++ 11, which was a huge improvement and basically what most people are using today, we decided never again. And so how do you avoid those slips?

And the answer is that you ship more often. So that if you have a slip on a 10-year cycle, by the time you know it's a slip, there's 11 years till you get it. Now with a three-year cycle, there is about 3, 4 years till you get it. Like the delay between feature freeze and shipping. So you always get 1 or 2 years more.

And so we shipped 14 on time, we shipped 17 on time, and we ship, we will ship 20 on time. It'll happen. And furthermore, this allow, this gives a predictability that allows the implementers, the compiler implementers, the library implementers, to they have a target and they deliver on it. 11 took 2 years for most compilers were good enough. 14, most compilers were actually getting pretty good in 14.

17, everybody shipped in 17. Well, we are going to have At least almost everybody ship almost everything in 20. And I know this because they're shipping in 19. Predictability is good. Delivery on time is good.

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

See all Lex Fridman transcripts on Youtube

Bjarne Stroustrup: C++ Standards - C++03, C++11, C++14, C++17, C++20