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 whole, what 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? I'll try and explain that. So sometime in early 1989, two people, one from IBM, one 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 and it wasn't ready for formal standardization and such. And they said, "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." Right. The old bus ride. "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.

But we know you can do it better." So through a combination of arm twisting and flattery, it got started. So 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're doing. We met there, we were lectured on the rules of how to do an ANSI 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. Everybody can sign up if they pay the minimal fee, which is about a thousand dollars, though less then, it's a little bit more now.

And I think it's $1,280. It's not going to kill you. And we have three meetings a year. This is fairly standard. We tried two meetings a year for a couple of years that didn't work too well. So three one week meetings a year, and you meet and you have technical discussions, and then you bring proposals forward for votes.

The votes are done one vote per organization. So you can't have, say, IBM come in with 10 people and dominate things, that's not allowed. And these are organizations that extends to the UC++? Yes. Or individuals. 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.

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 decides it. I don't know if everyone agrees to that, by the way. Bureaucracies have their critics too. Yes. They're the, look, standardization is not pleasant. It's horrifying.

It's like democracy. But we, exactly. As Churchill says, democracy is the worst way except for all the others. 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. A 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 three times a year. Next week I'll be in Cologne, Germany, spending a week doing standardization.

And we will vote out the committee draft of C++20, which goes to the National Standards Committee 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. 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, and 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 has 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 one in '08, brilliant. And we thought we were going to do the next one in '06 because now we are good at it. It took 13. Yeah, it was named OX. It was named OX.

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 six, seven or eight. The confidence of youth. Yeah, that's right. 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're going to do it much better. And we got more ambitious. And it took longer. Furthermore, there is this tendency because it's a 10 year cycle or eight, 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. That basically, I think it saved C++. It was beautiful. 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 what 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 three, four years till you get it. Like the delay between feature freeze and shipping. So you always get one or two years more. And so we shipped 14 on time. We shipped 17 on time and we will ship 20 on time.

It'll happen. And furthermore, this gives a predictability that allows the implementers, the compiler implementers, the library implementers, they have a target and they deliver on it. 11 took two years for most compilers were good enough. 14, most compilers actually getting pretty good in 14. 17, everybody shipped in 17.

We are going to have at least almost everybody ship almost everything in 20. And I know this because they're shipping in 19. Reliability is good. Delivery on time is good. And so, yeah. That's great. So that's how it works.