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

1. 0:00 – 15:00

   The following is a…

   1. LFLex Fridman0:00

      The following is a conversation with Bjarne Stroustrup. He's the creator of C++, a programming language that after 40 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, for example, many of the critical backend components of YouTube are written in C++. Same goes for Google, Facebook, Amazon, Twitter, most Microsoft applications, Adobe applications, most database systems, and most physical systems that operate in the real world, like cars, robots, rockets that launch us into space and one day will land us on Mars. C++ also happens to be the language that I use more than any other in my life. I've written several hundred thousand lines of C++ source code. Of course, lines of source code don't mean much, but they do give hints of my personal journey through the world of software. I've enjoyed watching the development of C++ as a programming language, leading up to the big update in the standard in 2011 and those that followed in '14, '17 and toward the new C++ 20 standard hopefully coming out next year. This is The Artificial Intelligence Podcast. If you enjoy it, subscribe on YouTube, give it five stars on iTunes, support it on Patreon, or simply connect with me on Twitter @lexfridman, spelled F-R-I-D-M-A-N. And now, here's my conversation with Bjarne Stroustrup. What was the first program you've ever written? Do you remember?

   2. BSBjarne Stroustrup1:45

      It was my second year in university, first year of computer science. And it was in Algol 60. I calculated the shape of a super ellipse and then connected points on the, on the perimeter, uh, creating star patterns. It was with a- w- with a wet ink on a paper printer. (laughs)

   3. LFLex Fridman2:11

      And that was in college, in university?

   4. BSBjarne Stroustrup2:13

      Yeah, yeah. I learned to program the second year in university.

   5. LFLex Fridman2:18

      And what was the first programming language, if I may ask it this way, that you fell in love with?

   6. BSBjarne Stroustrup2:26

      I, I think Algol 60. And after that, I remember... I remember SNOBOL. I remember Fortran, didn't fall in love with that. I remember Pascal, didn't fall in love with that. It all got in the way of me. Uh, and then I discovered Assembler and that was much more fun. And from there, I went to micro, um, microcode.

   7. LFLex Fridman2:54

      So you were drawn to the... You found the low-level stuff beautiful.

   8. BSBjarne Stroustrup3:01

      I, I went through a lot of languages and then I spent significant time in, in Assembler and microcode. That was sort of the first really profitable things and that paid for my master's actually. And then I discovered Simula, which was absolutely great.

   9. LFLex Fridman3:19

      Simula?

   10. BSBjarne Stroustrup3:20

       Simula was the extension of Algol 60, uh, done primarily for simulation, but basically they invented object-oriented programming and inheritance and runtime polymorphism when they were, while they were doing it. And, uh, that was a language that taught me that you could have the, sort of the problems of a program grow with size of the program rather than with the square of the size of the program. That is, you can actually modularize very nicely. And that, that, that was a surprise to me. It was also a surprise to me that a stricter type system than Pascal's was helpful, whereas Pascal's type system got in my way all the time. So you need a, a strong type system to organize your code well, but it has to be extensible and flexible.

   11. LFLex Fridman4:21

       Let's get into the details a little bit. What kind... If you remember, what kind of type system did Pascal have? What type system, typing system did Algol 60 have?

   12. BSBjarne Stroustrup4:31

       Basically, Pascal was sort of the simplest language that Niklaus Wirth could define that served the needs of Niklaus Wirth at the time, and it- it has a sort of a highly, uh, moral tone to it. That is, if you can say it, uh, in Pascal, it's good, and if you can't, it's not so good. Whereas Simula allows you basically to build your own type system. So instead of trying to fit yourself into, uh, Niklaus Wirth's world, Kristen Nygaard's language and Ole Johan Dahl's language allowed you to build your own. So it's sort of close to the original idea of, of you- you- you build a domain-specific language. As a matter of fact, what you build is a set of types and relations among types that allows you to express, uh, something that's suitable for an application.

   13. LFLex Fridman5:36

       So when you say types, stuff you're saying has echoes of object-oriented programming. (laughs) So-

   14. BSBjarne Stroustrup5:42

       Yes, they invented it. Every language that uses the word "class" for type is a descendant of Simula. Directly or indirectly. Kristen Nygaard and Ole Johan Dahl were mathematicians, um, and they didn't think in terms of types, they, um, but they understood sets and classes of, uh, elements and so they called their types classes. And basically, in C++, as in Simula, a class is a user-defined type.

   15. LFLex Fridman6:18

       So can you try the impossible task and give a brief history of programming languages from your perspective? So we started with ALGOL 60, Simula, Pascal, but that's-

   16. BSBjarne Stroustrup6:31

       I- I- I can-

   17. LFLex Fridman6:31

       ... just the '60s and '70s.

   18. BSBjarne Stroustrup6:33

       ... I can try. The most sort of interesting and major improvement of programming languages was, um, Fortran, the first Fortran. Because before that, all code was written for a specific machine and each, uh, specific machine had a language, assembly language or, uh, microassembler or some extension of that idea. But it- you are writing for a specific machine in the ter- in the language of that machine.

   19. LFLex Fridman7:06

       Mm-hmm.

   20. BSBjarne Stroustrup7:07

       And Backus and his team at IBM built a language that would allow you to, to write what you really wanted. That is, y- you could write it in a language that was natural for people. Now, these people happened to be engineers and physicists, so the language that came out was somewhat unusual for the rest of the world. But basically, they said formula translation because they wanted to have the mathematical formulas translated into the machine.

   21. LFLex Fridman7:38

       Mm-hmm.

   22. BSBjarne Stroustrup7:38

       And as a side effect, they got portability, because now they're writing in the terms that the humans use and the way humans thought, and then they had a program that translated it into the machine's needs. And, and that was new, and that was, uh, great, and it's something to, to remember. We want to raise the language to the human level, but we don't want to lose the efficiency. So-

   23. LFLex Fridman8:10

       And that was the first step towards the human?

   24. BSBjarne Stroustrup8:12

       That was the first step, um, and of course, they were very particular kind of humans. Businesspeople-

   25. LFLex Fridman8:19

       Mathematicians.

   26. BSBjarne Stroustrup8:19

       ... were different, so they got COBOL instead and-

   27. LFLex Fridman8:22

       (laughs)

   28. BSBjarne Stroustrup8:22

       ... et cetera, et cetera. And Simula came out... Uh, no, let's not go to Simula yet. Let's go to ALGOL. Uh, Fortran didn't have, at the time, the notions of... not a precise notion of type, not a precise notion of scope, uh, not a, um, a, a set of translation phases that was, uh, what we have today, lexical, syntax, semantics. It was sort of a bit of a model in the early days, but hey, they'd just done the biggest, uh, breakthrough in the history of programming, right? So you can't criticize them for not having gotten all the technical details right. So we got ALGOL. That was, uh, very pretty, and most people in commerce and science considered it useless because it was not flexible enough and it wasn't efficient enough and et cetera, et cetera. Uh, but that was a breakthrough from a technical point of view. Then Simula came along to make that idea more flexible, and you could define your own types, and that's w- where, where I got very interested. Kristen Nygaard, who's the main idea man behind, uh, Simula-

   29. LFLex Fridman9:44

       That was late '60s.

   30. BSBjarne Stroustrup9:45

       This was late '60s. Well, I was a visiting professor in, uh, Aarhus, and so I learned object-oriented programming by sitting around and, well, in theory, discussing with Ole Ju- uh, with, with Kristen Nygaard. But Kristen, once he gets started i- in, in full flow, it's very hard to get a word in edgeways with.
2. 15:00 – 30:00

   The stuff that'll last…

   1. BSBjarne Stroustrup15:01

      Um, I'm quite aware that maybe 70, 80% of all code are not under the kind of constraints I'm interested in. But somebody has to do the, the, the job I'm doing, uh, because you have to get from these high-level flexible languages to the hardware.

   2. LFLex Fridman15:23

      The stuff that'll last for 10, 20, 30 years is robust-

   3. BSBjarne Stroustrup15:27

      Yeah.

   4. LFLex Fridman15:27

      ... operates under very constrained conditions. Yes. Absolutely.

   5. BSBjarne Stroustrup15:31

      That's right.

   6. LFLex Fridman15:31

      And it's fascinating and beautiful in its own way. It's, uh, C++ is-

   7. BSBjarne Stroustrup15:36

      Yeah.

   8. LFLex Fridman15:36

      ... uh, one of my favorite languages and so is Lisp. So I can-

   9. BSBjarne Stroustrup15:40

      Yeah.

   10. LFLex Fridman15:40

       ... I can embody two for different reasons-

   11. BSBjarne Stroustrup15:43

       Yeah.

   12. LFLex Fridman15:43

       ... uh, as, um, as a programmer.

   13. BSBjarne Stroustrup15:47

       I, I understand why Lisp is popular and I can see, uh, the beauty of the ideas and similarly with, um, with Smalltalk.

   14. LFLex Fridman15:56

       There's more to talk and all the functional languages.

   15. BSBjarne Stroustrup15:57

       It's just not as relative lang- it is not as relevant in my world. And by the way, I distinguish between those and the functional languages where I go to things like ML and Haskell.

   16. LFLex Fridman16:12

       Haskell.

   17. BSBjarne Stroustrup16:13

       Uh, different, different kind of languages. Uh, they have a different kind of beauty and they're very interesting. And I actually try to learn from all the languages I encounter to see what is there that would make working on the kind of problems I'm interested in with the kind of constraints, um, that, that I'm interested in, wha- what can actually be done better?

   18. LFLex Fridman16:40

       Mm-hmm.

   19. BSBjarne Stroustrup16:41

       Because sh- we can surely do better than we do today.

   20. LFLex Fridman16:46

       You've, uh, you've said that it's good for any professional programmer to know at least five languages. That's speaking about a variety of languages that you've taken inspiration from. And you've listed th- yours as being, uh, at least at the time, C++, obviously, Java, Python, Ruby, and JavaScript. Can you, first of all, update that list, modify it? Uh, you don't have to be constrained to just five, but can you describe what you picked up also from each of these languages, how you see them as inspirations for even your work in, with C++?

   21. BSBjarne Stroustrup17:26

       This is a very hard question to answer. So about languages, you should know languages. I, I reckon I knew about 25 or thereabouts when I did C++. It was easier in those days because the languages were smaller and, uh, you didn't have to learn a whole programming environment and such to do it. You, you could learn a language quite easily. And, uh, it's, it's good to learn so many languages and-

   22. LFLex Fridman17:56

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

   23. BSBjarne Stroustrup18:05

       Yeah.

   24. LFLex Fridman18:06

       That there's commonalities and so on.

   25. BSBjarne Stroustrup18:09

       So I picked five out of a hat as a number.

   26. LFLex Fridman18:11

       You picked five out of a hat. Let's look at languages-

   27. BSBjarne Stroustrup18:12

       Obviously. The important thing that the number is not one.

   28. LFLex Fridman18:17

       (laughs) That's right.

   29. BSBjarne Stroustrup18:18

       Um, it's like, I don't like ... I mean, if you are monoglot, you are likely to think that your own culture is the only one that's superior to everybody else's. A good learning of a foreign language and a foreign culture is important. It helps you think and be a better person. With programming languages, you become a better programmer, a better designer with a second language. Now, once you've got two, the way to five is not-... that long. It's the second one that's most important. And then when I had to pick five, um, I sort of thinking, "What kinds of languages are there?" Well, there's a really low-level stuff. It's good, it's actually good to know machine code. Most pe-

   30. LFLex Fridman19:05

       Even still? Sorry to interrupt but-
3. 30:00 – 45:00

   Yeah. …

   1. BSBjarne Stroustrup30:00

      programs and we can try and make sure they, um, crash less often.

   2. LFLex Fridman30:07

      Yeah.

   3. BSBjarne Stroustrup30:07

      The way you do that-

   4. LFLex Fridman30:08

      Mm-hmm.

   5. BSBjarne Stroustrup30:09

      ... 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, um, big test frameworks that you are 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, if, if the way you are thinking about a problem is not in the code-

   6. LFLex Fridman30:54

      Mm-hmm.

   7. BSBjarne Stroustrup30:55

      ... 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, a smaller number of computers, which means there's less hardware that could possibly break. Um, so I think the key here is simplification, but it has to be, um, to use the Einstein quote, "As simple as possible and no simpler."

   8. LFLex Fridman31:40

      No simpler. But how do you-

   9. BSBjarne Stroustrup31:41

      There are other areas with under constraints where you can be simpler than you can be in C++. But in the domain I'm dealing with, that's the simplification I'm after.

   10. LFLex Fridman31:53

       So how do you inspire or ensure that, uh, the Einstein level of simplification is reached? So c- can you do code review? Can you look at code? Is there... If I gave you the code for the Ford F-150 and said, "Here." (laughs) Is this a mess or is this okay? Is it possible to tell? Is it possible to regulate?

   11. BSBjarne Stroustrup32:23

       An experienced developer can do a code and see if it smells.

   12. LFLex Fridman32:29

       (laughs)

   13. BSBjarne Stroustrup32:29

       And, uh, I mix metaphors deliberately.

   14. LFLex Fridman32:31

       Yes.

   15. BSBjarne Stroustrup32:32

       Uh, the, the point is that it is hard to generate something th- that is really obviously clean and, uh, um, can be appreciated. But you can usually recognize when you haven't reached that point. And so, i- if I... I've never looked at, uh, the F150 code, so I wouldn't know, but I know what I would be looking for. There... I'd be looking for some tricks that correlates with bugs and elsewhere and, uh, I, I have tried to formulate, uh, rules for what good code looks like. Um, and the, the current, uh, version of that is called the C++ Core Guidelines. One thing people should remember is there's what you can do in a language and what you should do. In a language, you have lots of things that is necessary in some context, but not in others. There's things that exist just because there's 30-year-old code out there and you can't get rid of it. But you can have rules that says, "When you create it, try and follow these rules." This does not create good programs by themselves, but it limits the damage and, uh, o- from mistakes, it limits the possibilities of the mistakes. And basically, we are trying to say, what is it that a good programmer does-

   16. LFLex Fridman34:12

       Mm.

   17. BSBjarne Stroustrup34:12

       ... at the fairly simple level of where you use the language and how you use it? Now, I can put all the rules for chiseling in mar- marble. It doesn't mean that somebody who follows all of those rules, uh, can do a masterpiece by Michelangelo. That is, there's something else to write a good program, just as there's something else to create a, a important work of art. That is, there's a... There's some kind of inspiration, understanding, gift. But we can approach the sort of technical, the craftsmanship level of it. The, the, the famous painters, the famous cultures was, among other things, superb craftsmen. They could express their ideas using, um, their tools very well. And so these days, I think what I'm doing, what a lot of people are doing, we are still trying to figure out how it is to use our tools very well. For a really good piece of code, you, you need a spark of inspiration and you can't, I think, regulate that. You, you, you cannot say that, um, "I'll take a picture only... Uh, I'll buy your picture only if, uh, you're at least van Gogh." Um-

   18. LFLex Fridman35:45

       (laughs)

   19. BSBjarne Stroustrup35:45

       ... there are other things you can regulate but, but not the inspiration.

   20. LFLex Fridman35:50

       I think that's quite beautifully put. It is true that there is... As, as an experienced programmer, when you see code that's inspired, that's, uh, like Michelangelo, you know it when you see it. And, uh, the opposite of that is code that is messy, code that smells, you know when you see it. And I'm not sure you can describe it in words, except vaguely through guidelines and so on.

   21. BSBjarne Stroustrup36:20

       Yes. It's easier to recognize ugly than to recognize beauty in code. And for the reason is that sometimes beauty comes from something that's innovative and unusual, and you have to sometimes think reasonably hard to appreciate that. On the other hand, a me- uh, the messes have things in common.

   22. LFLex Fridman36:43

       (laughs)

   23. BSBjarne Stroustrup36:44

       And you can... You can have static checkers and dynamic checkers that finds, uh, a large number of the-... most common mistakes. Uh, you can catch a lot of sloppiness mechanically. I'm a great fan of static analysis, in particular, uh, because you can check for not just the language rules, but for the usage of language rules. And I think we will see much more static analysis in the coming decade. We-

   24. LFLex Fridman37:19

       Can you describe what static analysis is?

   25. BSBjarne Stroustrup37:21

       You represent a piece of code so that you can write a program that goes over, uh, that representation and look for things that are, um, right and not right. So for instance, you can an- an- analyze a, a program to see if, um, resources are leaked. That's one of my favorite, uh, problems. It's not actually all that hard in modern C++, but you can do it. If you're writing in the C level, you have to have a malloc and a free, and, uh, they have to match. If you have them in a single function, you can usually do it very easily. If there's a, um, malloc here, there should be a free there. On the other hand, in between can be true in complete code, and then-

   26. LFLex Fridman38:17

       (laughs)

   27. BSBjarne Stroustrup38:18

       ... it becomes impossible.

   28. LFLex Fridman38:19

       Yeah.

   29. BSBjarne Stroustrup38:19

       If you pass that pointer to the, uh, memory out of a function and then want to make sure that the free is done, uh, somewhere else, now it gets really difficult. And so-

   30. LFLex Fridman38:33

       Mm-hmm.
4. 45:00 – 1:00:00

   Mm-hmm. …

   1. BSBjarne Stroustrup45:00

      um, matrix multiplications and they've actually gotten code that ran faster than Fortran because-

   2. LFLex Fridman45:07

      Mm-hmm.

   3. BSBjarne Stroustrup45:07

      ... once you had the right abstraction, you can eliminate, um, you can eliminate temporaries and you can do, um, uh, loop fusion and other good stuff like that that's quite hard to do by hand and... in a lower level language. And there's some really nice examples of that. And the key here is that that matrix op- uh, multiplication, the matrix abstraction allows you to write code that's simple and easy. You can do that in any language. But with C++, it has the features so that you can also have this thing run faster than if you hand-coded it.

   4. LFLex Fridman45:45

      Mm-hmm.

   5. BSBjarne Stroustrup45:45

      Now, people have given that lecture many times, I and others. And a very common on- uh, question after the talk, where you have demonstrated that you can outperform Fortran for, uh, dense matrix multiplication, people come up and says, "Yeah, but that was C++. If I rewrote your code in C, how much faster would it run?" And the answer is much slower. This happened the first time actually back in the '80s with a friend of mine called Doug McIlroy who demonstrated the... exactly this effect. And, um, so the, the principle is you should give programmers the tools so that the abstractions can follow the zero overhead principle. Furthermore, when you put in a language feature in C++ or a standard library feature, you try to meet this. It doesn't mean it's absolutely optimal, but it means if you hand-code it with the usual th- uh, facilities in the language, in C++, in C, you should not be able to better it. Usually, you can do better if you use embedded Assembler for, uh, machine code for, for some of the details to utilize part of a computer that the compiler doesn't know about. But you should get to that point before you beat the abstraction.

   6. LFLex Fridman47:09

      So that's, that's a beautiful ideal to reach for. Uh-

   7. BSBjarne Stroustrup47:13

      And we meet it quite often.

   8. LFLex Fridman47:14

      Quite often. So where's the magic of that coming from? There's some of it is the com- compilation process, so the implementations in C++. Some of it is the design of the feature itself, the guidelines. So I've, uh, recently and often talked to Chris Lattner-

   9. BSBjarne Stroustrup47:33

      Mm-hmm.

   10. LFLex Fridman47:33

       ... so Clang. What, just out of curiosity, is your relationship in general with the different implementations in C++ as you think about you and committee and other people in C++ think about the design of new features or design of previous features, th- uh... W- uh, in, in trying to reach the ideal of zero overhead, w- does the magic come from the design, the guidelines or from the implementations?

   11. BSBjarne Stroustrup48:06

       And.

   12. LFLex Fridman48:07

       And?

   13. BSBjarne Stroustrup48:08

       Not or.

   14. LFLex Fridman48:09

       (laughs)

   15. BSBjarne Stroustrup48:09

       You ha- you, you are... You, you, you, you go for programming technique, program language features, and implementation techniques. You need all three.

   16. LFLex Fridman48:19

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

   17. BSBjarne Stroustrup48:23

       It takes some experience, takes some practice, and sometimes you get it wrong. But after a while, you sort of get it right. I don't write compilers anymore, but Brian Kernighan pointed out that one of the reason C++ succeeded was some of the craftsmanship I put into the early compilers. And of course, I did the language design, and of course, I wrote a fair amount of code using this kind of stuff. And I think most of the successes involves progress in all three areas together.... a small group of people can do that. Two, three people can, can work together to do something like that. It's ideal if it's one person that has all the skills necessary, but nobody has all the skills necessary in all the fields where C++ is used. So if you want to approach my ideal in, say, concurrent programming, you need to know about algorithms from concurrent programming. You need to know the, the trickery of lock-free programming. You need to know something about, uh, compiler techniques. And then you have to know some of the program area- uh, the, uh, sorry, the application areas where this is, um, like, some forms of graphics or some forms of, um, uh, what do you call it? Um, a web server kind of stuff. And that's very hard to get into a single head. But small groups can do it too.

   18. LFLex Fridman50:01

       S- is- so is there differences in your view, not saying which is better or so on, but difference in the different implementations of C++? Why are there several? Sort of maybe a naive question for me. Um, GC- GCC, Clang, and so on.

   19. BSBjarne Stroustrup50:21

       You know, this is a very reasonable question. When I designed C++... Most languages have multiple implementations because if you run on an IPM, if you run on a Sun, if you run on a Motorola, there, there was just many, many companies and they each have their own compilation structure and their old compilers. It, it was just fairly common that there was many of them. And I wrote Cfront assuming that other people would write compilers for C++ if I was successful. And furthermore, I wanted to utilize all the backend infrastructures that were available. I soon realized that my users were using 25 different linkers. I couldn't write my own linker. Yes, I could, but I couldn't write 25 linkers and also get any work done on the language. And so, it came from a world where there was many linkers, many optimizers, many, uh, compiler frontends. Um, not to- not to start, um, but operat- many operating systems. The whole world was not an 86 and a, and a Linux box or something. Whatever is the standard today, in the old days, they said, uh, uh, set of backs. So basically, I assumed there would be lots of compilers. It was not a decision that there should be many compilers. It was just a fact. That's the way the world is.

   20. LFLex Fridman51:55

       Mm-hmm.

   21. BSBjarne Stroustrup51:56

       And yes, many compilers emerged. And today, there's at least four frontends, uh, Clang, GCC, Microsoft, and EDG, Eddie's Design Group. They, they supply a lot of the independent o- organizations and the embedded systems industry. And there's lots and lots of, of backends. We have to think about how many dozen backends there are. Uh, because different machines have different things. Especially in the n- m- embedded world, the machines are very different. The architectures are very different. And, um, so having a single implementation was never a, uh, an option. Now, I also happen to dislike monocultures.

   22. LFLex Fridman52:53

       Monocultures?

   23. BSBjarne Stroustrup52:54

       They are dangerous because whoever owns the mo- monoculture can go stale and, uh, there's no competition and there's no incentive to innovate.

   24. LFLex Fridman53:06

       Mm-hmm.

   25. BSBjarne Stroustrup53:06

       There's a lot of incentive to put barriers in the way of change because, "Hey, we own the world and, uh, it's a very comfortable world for us, and who are you to, um, to mess with that?" So, I really am very happy that there's four, uh, frontends for C++. Clang's great, but... GCC was great, but then it got somewhat stale. Clang came along and GCC is much better now.

   26. LFLex Fridman53:37

       (laughs) Competition is good.

   27. BSBjarne Stroustrup53:38

       Mi- Microsoft is much better now. So, a, a low... Uh, at least a low number of frontend puts a lot of pressure on standards compliance and also on performance and error messages and s- compile time speed. All this good stuff that we want.

   28. LFLex Fridman54:00

       (laughs) Do you think, crazy question, there might come along... Do you hope there might come along, uh, implementation of C++, written, given all of its history, written from scratch? So written today from scratch?

   29. BSBjarne Stroustrup54:19

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

   30. LFLex Fridman54:25

       But there's been C++11, 14, 17, 20, you know? There's been a lot of feature-
5. 1:00:00 – 1:15:00

   Mm-hmm. With the templates…

   1. BSBjarne Stroustrup1:00:00

      is... You express the re- uh, the commonality, uh, as, as the idea of a vector, and the variations come through parameterization! And so, here we get the two fundamental ways of abstracting, or of having similarities of types in C++. There's the inheritance and there's the parameterization. There's the object-oriented programming, and there's the generic programming.

   2. LFLex Fridman1:00:28

      Mm-hmm. With the templates for the generic programming.

   3. BSBjarne Stroustrup1:00:30

      Yep.

   4. LFLex Fridman1:00:31

      So, you, you've, uh, presented it very nicely, but now you have to make all that happen and make it efficient. So, generic programming with templates, there's all kinds of magic going on, especially r- recently, uh, that you can help catch up on. But it feels to me like you can do way more than what you just said with templates.

   5. BSBjarne Stroustrup1:00:55

      Mm-hmm. Mm-hmm.

   6. LFLex Fridman1:00:55

      You can start doing this kind of meta-programming, this kind of-

   7. BSBjarne Stroustrup1:00:58

      You can do meta-programming also. Uh, I, I didn't go there in, in that explanation. Uh, we're trying to be very basics. But go back onto the implementation.

   8. LFLex Fridman1:01:08

      Implementation.

   9. BSBjarne Stroustrup1:01:08

      If you couldn't implement this efficiently, if you couldn't use it...... so that it became efficient, it has no place in C++ because it will violate the zero-overhead principle.

   10. LFLex Fridman1:01:21

       Sure.

   11. BSBjarne Stroustrup1:01:21

       So, when I had to get object-oriented programming inheritance, I took the idea of virtual functions from Simula. Virtual functions is a Simula term, class is a Simula term. Uh, if you ever use those words, say thanks to, uh, Christian Nygaard and Ole Yvann Dahl. And I did the simplest implementation I knew of, which was basically a jump table. So, you get the virtual function table, the function goes in, uh, do- does an indirection through a table and get the right function. That's how you pick the right thing there. And, uh, I thought that was trivial. It's close to optimal. It's ... and it was obvious. It turned out that Simula had a more complicated way of doing it, and therefore was slower. And, um, it turns out that most languages have something that's a little bit more complicated, sometimes more flexible, but you pay for it.

   12. LFLex Fridman1:02:21

       Mm-hmm.

   13. BSBjarne Stroustrup1:02:22

       And one of the strengths of C++ was that you could actually do this object-oriented stuff and your overhead compared to- to ordinary functions, there's no indirections. It's sort of in 5%, 10%, 25%. Uh, just the call. It's- it's down there. It's not two.

   14. LFLex Fridman1:02:42

       Right.

   15. BSBjarne Stroustrup1:02:42

       And that means you can afford to use it. Furthermore, in C++, you have the distinction between a virtual function and a non-virtual function. If you don't want any overhead, if you don't need the indirection, uh, that gives you the flexibility in object-oriented programming, just don't ask for it.

   16. LFLex Fridman1:03:01

       (laughs)

   17. BSBjarne Stroustrup1:03:02

       Um, so the- the- the idea is that you only use virtual functions if you actually need the flexibility, so it's not zero overhead, but it's zero overhead compared to any other way of achieving the flexibility.

   18. LFLex Fridman1:03:15

       Mm-hmm.

   19. BSBjarne Stroustrup1:03:16

       Now, auto-parameterization. Basically, the compiler looks at, at the, the template, uh, say the vector, and it looks at the, um, parameter, and then combines the two and generates a piece of code that is exactly as if you had written a vector of that specific type.

   20. LFLex Fridman1:03:44

       Yes.

   21. BSBjarne Stroustrup1:03:44

       So that's the- that- that's the minimal overhead. If you have many template parameters, you can actually combine code that the compiler couldn't usually see at the same time, and therefore get code that is faster than if you had handwritten the stuff, uh, unless you are very, very clever.

   22. LFLex Fridman1:04:05

       So, the thing is, parameterized code, the compiler fills stuff in during the compilation process, not during runtime.

   23. BSBjarne Stroustrup1:04:14

       That's right.

   24. LFLex Fridman1:04:16

       So-

   25. BSBjarne Stroustrup1:04:16

       And furthermore, it gives all the information it's gotten, which is the template, the parameter, and the context of use. It combines the three and generates good code.

   26. LFLex Fridman1:04:30

       Yeah. But it can generate ... now, it's a little outside of what I'm even comfortable thinking about, but it can generate a lot of code.

   27. BSBjarne Stroustrup1:04:40

       Yes.

   28. LFLex Fridman1:04:41

       And how do you ... now, I remember being both amazed at the power of that idea and how ugly the debugging looked. (laughs)

   29. BSBjarne Stroustrup1:04:53

       Yes, uh, debugging can be truly horrid. Come back to this because I have a solution.

   30. LFLex Fridman1:04:59

       Okay. (laughs)
6. 1:15:00 – 1:30:00

   Mm-hmm. …

   1. BSBjarne Stroustrup1:15:01

      And neither I nor anybody else at the time knew how to get all three. And I thought, for C++, I must have the two first. Otherwise it's not C++. And it bothered me for another couple of decades that I couldn't solve the third one. I mean, I was the one that put function argument type checking into C. I know the value of good interfaces. I didn't invent that idea, it's very common, but I did it, and I wanted to do the same for templates of course, and I couldn't. So it bothered me. Then we tried again 2002, 2003, 2003. Uh, Gabby Dres and I started analyzing the problem, uh, explained possible solutions. There was not a complete design. Uh, a group in University of Indiana, an old friend of mine, uh, they started a, a project at Indiana and we, we thought we could get a good system of concepts in another two or three years, that would have made C++ ele- uh, 11 to C++. Well, it, it turned out that I think we got a lot of the fundamental, uh, ideas wrong. They were too con- uh, conventional. Um, they didn't quite fit C++ in my opinion. Didn't serve implicit conversions very well. It didn't serve mixed, mixed type arithmetic, mixed type competation, uh, computations very well. A lot of stuff came out of the functional community and it... that community didn't deal with multiple types in, in the same way as C++ does, had more constraints on, on what you could express and didn't have the draconian, uh, performance requirements. And basically we tried, we tried very hard. We had some successes, but it just in the end wasn't... (sighs) didn't compile fast enough, was too hard to use and, uh, didn't run fast enough unless you had s- uh, optimizers that was beyond the, uh, state of the art. They still are. So we had to do something else. Basically it was the idea that a set of parameters has, uh, defines a set of operations and you go through an indirection table just like for virtual functions, and then you try to optimize the, um, indirection away, uh, to get performance.

   2. LFLex Fridman1:18:02

      Mm-hmm.

   3. BSBjarne Stroustrup1:18:02

      And we just couldn't do all of that. Uh, 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.

   4. LFLex Fridman1:18:21

      So you've started to develop C++ and there's a hope w- when was the first standard established? What is that like? Uh, the ISO standard, is there a committee that you're referring to?

   5. BSBjarne Stroustrup1:18:34

      Sure.

   6. LFLex Fridman1:18:34

      There's a group of people. What i- what's that like? How often do you meet?

   7. BSBjarne Stroustrup1:18:39

      Okay.

   8. LFLex Fridman1:18:39

      What's the discussion like?

   9. BSBjarne Stroustrup1:18:39

      I'll, I'll try and explain that. So sometime in early 1989, um, 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, uh, I pointed out that w- 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, you really want to do this. Um, our organizations depend on C++. We cannot, uh, 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.

   10. LFLex Fridman1:19:32

       Right, the old, the old bus, right?

   11. BSBjarne Stroustrup1:19:33

       "We really need to get this out in the open. It has to be, uh, standardized under formal rules, and, uh, we w- are going to standardize it, um, 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." Uh, so, uh, through a, a combination of arm-twisting and, uh, flattery, um-

   12. LFLex Fridman1:20:04

       A carrot and stick.

   13. BSBjarne Stroustrup1:20:05

       ... it got started.

   14. LFLex Fridman1:20:05

       Yep.

   15. BSBjarne Stroustrup1:20:05

       So in late, in late '89, there was a meeting in DC at the, um... 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. Um, and, um, 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, can sign up if they pay the minimal fee, which is just about a thousand dollars. It was less then, it's a little bit more now. And, uh, I think it's $1,280.

   16. LFLex Fridman1:20:59

       (laughs)

   17. BSBjarne Stroustrup1:20:59

       It's not, it's not going to kill you.

   18. LFLex Fridman1:21:01

       Right.

   19. BSBjarne Stroustrup1:21:01

       And y- we have three meetings a year, is, is fairly standard. Uh, we tried two meetings a year for a couple of years, that didn't work too well. So three meet- uh, three one-week meetings a year, and you meet and you have technical d- m- meet, uh, technical discussions, and then you bring proposals forward for votes. The votes are done one person per... one vote per organization. So you can't have, uh, say, IBM come in with 10 people and, uh, dominate things. That's not allowed.

   20. LFLex Fridman1:21:42

       And these are organizations that extensively use C++? 'Cause-

   21. BSBjarne Stroustrup1:21:46

       Yes.

   22. LFLex Fridman1:21:47

       'Cause, 'cause it's basically-

   23. BSBjarne Stroustrup1:21:47

       Or, or individuals.

   24. LFLex Fridman1:21:48

       Or individuals. I mean, it's, uh, it's a, 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.

   25. BSBjarne Stroustrup1:22:00

       That's right. Well, hmm, 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.

   26. LFLex Fridman1:22:12

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

   27. BSBjarne Stroustrup1:22:17

       Yes. They, they're there... Look, standardization is not pleasant.

   28. LFLex Fridman1:22:23

       Yeah.

   29. BSBjarne Stroustrup1:22:23

       It's, it's, it's, it's, it's horrifying.

   30. LFLex Fridman1:22:25

       It's like democracy, right?
7. 1:30:00 – 1:45:00

   (laughs) Uh, so it's…

   1. BSBjarne Stroustrup1:30:00

      greatest naming I've ever heard.

   2. LFLex Fridman1:30:02

      (laughs) Uh, so it's types, abstraction of types, uh, you said, "I want to create my own types." So types is an essential part of C++-

   3. BSBjarne Stroustrup1:30:16

      Yes.

   4. LFLex Fridman1:30:16

      ... and making them efficient is the ef- is the key part. And to you the... This is almost getting philosophical, but the construction and the destruction, the creation of an instance of a type and the freeing of resources from that instance of a type is what defines the object. Is, uh, that's almost like-

   5. BSBjarne Stroustrup1:30:43

      Um, a, a little bit-

   6. LFLex Fridman1:30:43

      ... birth and death is what defines human life. (laughs)

   7. BSBjarne Stroustrup1:30:46

      Yeah. That's right. By the way, philosophy is important. You can't do good language design without philosophy, because what you are determining is what people can express and how. This is very important. By the way, constructors/destructors came into C++ in '79-

   8. LFLex Fridman1:31:06

      Hmm.

   9. BSBjarne Stroustrup1:31:07

      ... in about the second week of my work with what was then called civil classes. It is a fundamental idea. Uh, next comes the fact that you need to control copying, because once you control, as you said, birth and death-

   10. LFLex Fridman1:31:22

       Mm-hmm.

   11. BSBjarne Stroustrup1:31:22

       ... you have to control taking copies, uh, which is another way of creating an object. And finally, you have to be able to move things around.

   12. LFLex Fridman1:31:32

       Mm-hmm.

   13. BSBjarne Stroustrup1:31:33

       So you get the move operations, and that's the set of key operations you can define on a C++ type.

   14. LFLex Fridman1:31:42

       And so to you, c-... those things are just a beautiful part of C++, that is at the core of it all.

   15. BSBjarne Stroustrup1:31:51

       Yes.

   16. LFLex Fridman1:31:53

       You mentioned that you hope there will be one unified set of guidelines in the future for how to construct a programming language. So perhaps not one programming language, but a unification of how we build programming languages, if you remember such statements.

   17. BSBjarne Stroustrup1:32:10

       Yeah. I, I have some trouble remembering it, but I know the origin of that idea.

   18. LFLex Fridman1:32:15

       So, maybe you can talk about ... So C++ has been improving. There's been a lot of programming language. Do you ... Where does the arc of history taking us? Do you hope that there is a unification about the languages with which we communicate in the digital space?

   19. BSBjarne Stroustrup1:32:32

       Well, I, I think that languages should be designed not by, uh, clobbering language features together and doing slightly different versions of somebody else's ideas, but through the creation of a set of, um, principles, rules of thumbs, whatever you call them. Um, I, I made them for C++. And we're trying to teach people in the standards committee about these rules, because a lot of people come in and says, "I've got a great idea, let's put it in language." And then you have to ask, "Why does it fit in the language? Why does it fit in this language? It may fit in another language and not here, or it may fit here and not the other language." So, you have to work from a set of principles and you have to develop that set of principles. And sp- ... One example that, that I sometimes remember is I was sitting down with some of the designers of Common Lisp.

   20. LFLex Fridman1:33:40

       Mm-hmm.

   21. BSBjarne Stroustrup1:33:41

       And we were talking about languages and language features, and obviously we didn't agree about anything, uh, because, well, Lisp is not C++ and vice versa.

   22. LFLex Fridman1:33:53

       There's too many parentheses.

   23. BSBjarne Stroustrup1:33:55

       But suddenly we started making progress. I said, "I had this problem and I developed it according to these ideas." And they said, "What? Why? We had that problem, different problem, and we developed it with the same kind of principles." And so we worked through large chunks of C++ and large chunks of Common Lisp, and figured out we actually had similar sets of principles of how to do it. But the constraints on our designs were very different, and the aims for the usage was very different. But there, there, there was commonality I- in the way you reason about language features and the fundamental principles you're trying to do.

   24. LFLex Fridman1:34:46

       So do you think that's possible to ar- ... So there ... Just like there is perhaps a unified theory of physics, of the fundamental forces of physics, (laughs) I'm sure there is, uh, commonalities among the languages, but there's also people involved-

   25. BSBjarne Stroustrup1:35:05

       Yeah.

   26. LFLex Fridman1:35:05

       ... that help drive the development of these languages. Do you have a hope or an optimism that there will be a unification if you th- if you think about physics and Einstein towards a simplified language?

   27. BSBjarne Stroustrup1:35:21

       Uh, I-

   28. LFLex Fridman1:35:21

       Do you think that's possible?

   29. BSBjarne Stroustrup1:35:24

       Let's remember, sort of modern physics, I think started with Galileo in the 1300s. So, they've had, uh, 700 years to get going.

   30. LFLex Fridman1:35:35

       Right.
8. 1:45:00 – 1:46:29

   Section 8

   1. BSBjarne Stroustrup1:45:00

      area and partly because what I do, uh, has much more impact if I do it in the context of, of C++. I, I have four and a half million people that pick it up, uh, tomorrow if I get something right. If I did it in another field, I would have to start learning, then I have to build it, and then I'll see if anybody wants to use it. One of the things that has kept me going for all of these years is, one, the good things that people do with it and the interesting, uh, things they do with it. And also, I get to see a lot of interesting stuff and talk to a lot of interesting people. Um, I mean, if it has just been statements on paper or on a screen, I, I don't think I could have kept going. But I get to see the telescopes up on, uh, Mauna Kea, and I actually went and see how Ford built cars, and I got to JPL and see how they do the, the, um, the Mars rovers. Um, there's so much cool stuff going on, and most of the cool stuff is done by pretty nice people and sometimes in very nice places. Uh, Cambridge, Sophia and Troopolis, uh, uh, Silicon Valley. Yeah. It's, uh, it, th- there, there's more to it than just code, but code is central.

Episode duration: 1:47:12