Skip to content
Bjarne Stroustrup: C++ | Lex Fridman Podcast #48
This video isn’t embeddableWatch on YouTube →
Lex Fridman PodcastLex Fridman Podcast

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

Lex Fridman and Bjarne Stroustrup on bjarne Stroustrup on C++: Abstraction, Efficiency, and Reliable Systems.

Lex FridmanhostBjarne Stroustrupguest
Nov 7, 20191h 47mWatch on YouTube ↗

EVERY SPOKEN WORD

  1. 0:00 – 3:20

    Bjarne’s first programs: Algol 60, assembler, and discovering Simula

    1. LF

      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. BS

      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. LF

      And that was in college, in university?

    4. BS

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

    5. LF

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

    6. BS

      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. LF

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

    8. BS

      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. LF

      Simula?

  2. 3:20 – 6:18

    Simula’s big idea: user-defined types, modularity, and strong-but-flexible typing

    1. BS

      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.

    2. LF

      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?

    3. BS

      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.

    4. LF

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

    5. BS

      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.

  3. 6:18 – 16:46

    A personal history of languages: Fortran → ALGOL → Simula (and the Lisp divide)

    1. LF

      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-

    2. BS

      I- I- I can-

    3. LF

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

    4. BS

      ... 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.

    5. LF

      Mm-hmm.

    6. BS

      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.

    7. LF

      Mm-hmm.

    8. BS

      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-

    9. LF

      And that was the first step towards the human?

    10. BS

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

    11. LF

      Mathematicians.

    12. BS

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

    13. LF

      (laughs)

    14. BS

      ... 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-

    15. LF

      That was late '60s.

    16. BS

      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.

    17. LF

      You're just listening.

    18. BS

      So, um, it, it was great. I learned it from there.

    19. LF

      Not to romanticize the notion, but it seems like a big leap to think about o- object-oriented programming. W- uh, it's, it's really a leap of abstraction. It's-

    20. BS

      Yes.

    21. LF

      And was that as, uh, big and beautiful of a leap as it seems from now in retrospect, or was it an obvious one at the time?

    22. BS

      It was not obvious, and many people have tried to do something like that, and most people didn't come up with something as, as wonderful as Simula. Uh, lots of people got their PhDs and made their careers out of, um, forgetting about Simula or never knowing it. For, for me, the key idea was basically I could get my own types, and that's the idea that goes further into C++, where I can get, uh, better types and more flexible types and more efficient types. But it's still the fundamental idea when I want to write a program, I want to write it with my types that is appropriate to my problem-

    23. LF

      Mm-hmm.

    24. BS

      ... uh, and under the constraints that I'm under with hardware, software, environment, et cetera. And tha- that's, that's the key idea. People picked up on the class hierarchies and the virtual functions and the inheritance, and that was only part of it. It was an interesting and major part and still a major part in a lot of graphics stuff, but it was not the most fundamental. It, it was when you wanted to relate one type to another, you don't want them all to be independent. The, the classical example is that you don't actually want to write a city simulation with vehicles where you say, "Well, if it's a bicycle, uh, write the code for turning a bicycle to the left. If it's a normal car, turn right the normal car way. If it's a fire engine, turn right the fire engine way," da-da-da-da-da-da. You get these big case statements and-... bunches of if statements and such. Instead, you, you tell the, uh, the, the, the base class, the, that, uh, uh, that's the vehicle and saying, "Turn, turn left the way you want to."

    25. LF

      (laughs) Yeah.

    26. BS

      And this is actually a real example. Uh, they, they used it to simulate, um, and optimize the emergency-

    27. LF

      Traffic flow or something like that.

    28. BS

      ... the, the emergency services for, uh, somewhere in Norway, uh, back in the '60s.

    29. LF

      Wow.

    30. BS

      So this was one of the early examples for why you needed inheritance and, and you needed, um, a runtime polymorphism, uh, s- because you wanted to handle this set of, um, of vehicles in a manageable way. You, y- y- you can't just rewrite your code each time a new kind of vehicle comes along.

  4. 16:46 – 23:20

    Why learn multiple languages: perspectives, machine code, and functional thinking

    1. LF

      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++?

    2. BS

      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-

    3. LF

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

    4. BS

      Yeah.

    5. LF

      That there's commonalities and so on.

    6. BS

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

    7. LF

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

    8. BS

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

    9. LF

      (laughs) That's right.

    10. BS

      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-

    11. LF

      Even still? Sorry to interrupt but-

    12. BS

      Even today, even today.

    13. LF

      Even today?

    14. BS

      Um, the C++ optimizers write better machine code than I do.

    15. LF

      Yes.

    16. BS

      But I don't think I could appreciate them if I actually didn't understand, uh, machine code and machine architecture. At least in, in, in my position, I have to understand a bit of it because (sighs) you mess up the cache and you're off in performance by a factor of 100. Right? It shouldn't be that if you are interested in either performance or the size of the computer you have to deploy. Uh, so, so I would go S assembler. Uh, I used to mention C, but these days going low level is not actually what gives you the performance.

    17. LF

      (laughs)

    18. BS

      It is to express your ideas so cleanly that you can think about it and the optimizer can understand what you're up to. My favorite way of optimizing these days is to throw away... out the clever bits and see if it still runs fast. And sometimes it runs faster.

    19. LF

      (laughs)

    20. BS

      Um, so I need the abstraction mechanisms or something like C++ to write compact high-performance code. Uh, there was a beautiful keynote by Jason Turner at the CppCon a couple of years ago where he decided he was going to program, uh, Pong on, um, um, Motorola 60, uh, 800 I think it was. And he says, "Well, this is relevant because it looks like a microcontroller. It has specialized hardware, it has not very much memory and it's relatively slow." And so he shows in real time how he writes Pong starting with fairly straightforward low-level stuff, improving his abstractions and what he's doing, he's writing C++ and it translate into, into 86 assembler, which, uh, you can do with, with Clang and you can see it in real time. It's, um, the compiler explorer, which you can use on the web. And then he wrote a little program that translated 86 assembler into Motorola assembler.

    21. LF

      Mm-hmm.

    22. BS

      And so he types and you can see this thing on-

    23. LF

      In, in real time? Wow.

    24. BS

      You can see it in real time and even if you can't read the assembly code, you can just see it... his code gets better, the code g- uh, the assembler gets smaller. He increases the abstraction level, uses C++11, as it were, better. This code gets cleaner, it gets easier, maintainable and the code shrinks.

    25. LF

      Wow.

    26. BS

      And it keeps shrinking.

    27. LF

      Wow.

    28. BS

      And I could not in any reasonable amount of time write that assembler as good as the compiler generated from really quite nice modern C++. And, and I'll go as far as to say the, the thing that looked like C was significantly, uh, uglier and, and smaller when it became s- me- uh, and, and larger when it became machine code. So up the, the abstractions that can be optimized are important.

    29. LF

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

    30. BS

      Yeah.

  5. 23:20 – 25:07

    Tools get used in unexpected ways: JavaScript, unintended use, and ethics

    1. LF

      What do you make of JavaScript in general? So you kind of... you're talking in the platonic sense about languages, about what they're good at, what their philosophy of design is. But there's also a large user base behind each of these languages and they use it in a way sometimes maybe it wasn't really designed for.

    2. BS

      That's right.

    3. LF

      JavaScript is used way beyond, uh, probably what it (laughs) was designed for.

    4. BS

      L- l- let me say it this way. When you build a tool, you do not know how it's going to be used. You try to improve the tool by looking at how it's being used and when people cut their fingers off and try and stop that from happening.

    5. LF

      (laughs) Yeah.

    6. BS

      Um, but really you have no control over how something is used. So I'm very happy and proud of some of the things C++ being used at and some of the things I wish people wouldn't do. Bitcoin mining being my favorite example. Uses as much energy as Switzerland and, uh, mostly serves, uh, criminals.

    7. LF

      Yeah.

    8. BS

      But back to, back to the languages. I actually think that having JavaScript run in the browser wa- wa- was, w- was an enabling thing for a lot of things. Yes, you could have done it better, but people were trying to do it better and they were using pre- uh mm- sort of more principled language designs, but they just couldn't do it right. And the-... non-professional programmers that write lo- lots of that code just couldn't understand them. So let, it, it did a, an amazing job for, for what it was. It's not the prettiest language and I don't think it ever will be, uh, the prettiest language, but let's not be bigots here.

  6. 25:07 – 27:31

    Origin motivation for C++: performance + reliability as real-world requirements

    1. LF

      So what was the origin story of C++?

    2. BS

      Yeah.

    3. LF

      You, you basically gave a few perspectives of your inspiration of object-oriented programming. That's ... You had a connection with C and performance. Efficiency was an important, uh, thing you were drawn to.

    4. BS

      Efficiency and reliability.

    5. LF

      Reliability, yeah.

    6. BS

      You have to get both.

    7. LF

      What, what, what's reliability?

    8. BS

      I, I, I really want my telephone calls to get through and I want the quality of what I am talking coming out at the other end. The other end might be in London or wherever. Um, so ... And y- and you don't want the system to be crashing. If you're doing a bank, uh, it's, uh, you mustn't crash. It might be your, uh, uh, your bank account that is in trouble. There's different constraints. Like, in games, it doesn't matter too much if there's a crash. Nobody dies and nobody gets ruined. But I- I'm interested in the combination of performance, uh, partly because of sort of s- speed of things being done, part of being able to do things that is necessary to, to, to have reliability, uh, of larger systems. If you spend all your time, um, interpreting a, a simple function call, you are not going to have enough time to do proper signal processing to get the telephone calls to sound right. Um, either that or you have to have 10 times as many computers and you can't afford your phone anymore. It's a ridiculous idea, uh, in the modern world because we have solved all of those problems.

    9. LF

      I mean, they keep popping up in different ways.

    10. BS

      Yeah.

    11. LF

      We ... 'Cause we ta- tackle bigger and bigger problems, so efficiency remains (laughs) always an important-

    12. BS

      Yeah.

    13. LF

      ... uh, aspect.

    14. BS

      But you have to think about efficiency not just as speed, but as an enabler to, uh, important things. And one of the things it enables is, uh, is reliability, is dependability. You ... When, when I press the pedal, uh, the brake pedal of a car, it is not actually connected directly to, uh, to anything but a computer.

    15. LF

      Yeah.

    16. BS

      That computer better work.

  7. 27:31 – 36:44

    Safety is a systems property: simplify first, then guidelines and analysis

    1. LF

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

    2. BS

      Mm-hmm.

    3. LF

      ... today. So this is certainly especially true of autonomous vehicles where some of the aspect of the control or driver assistance systems that steer the car to keep it in the lane and so on.

    4. BS

      Mm-hmm.

    5. LF

      So how do you think ... You know, I talk to regulators, people in government, who are very nervous about testing the safety of these systems-

    6. BS

      Mm-hmm.

    7. LF

      ... of so- of software, ultimately software that makes decisions that could lead to fatalities. So h- how do you ... How do we test software systems like these?

    8. BS

      First of all, safety, like performance and like, uh, security, is a systems property. People tend to look at one part of a system at a time and saying something like, "This is secure. That's all right. I don't need to do that. Yeah, that piece of code is secure. I'll buy your operator."

    9. LF

      Right.

    10. BS

      If you want to have reliability, if you want to have performance, if you want to have security, you have to look at the whole system.

    11. LF

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

    12. BS

      I'm dealing with one part of the system and I want my part to be really good, but I know it's not the whole system. Furthermore, e- making an individual part perfect may actually not be the best way of getting the highest degree of reliability and performance and such. There's people who say, "C++ is type safe, uh, not type safe. You can break it." Sure. I can break anything that runs on a computer. I may not go through your type system. If I wanted to break into your computer, I'll probably try SQL injection.

    13. LF

      And it's very true. If you think about safety or even reliability at a systems level, especially when a human being is involved, it's ... starts becoming hopeless pretty quickly in terms of, uh, proving that something is safe to a certain level-

    14. BS

      Yeah.

    15. LF

      ... 'cause there's so many variables. It's so complex.

    16. BS

      Well, let's get back to something we can talk about-

    17. LF

      (laughs)

    18. BS

      ... and, and actually make some progress on.

    19. LF

      Yes.

    20. BS

      Uh, we, we could look at C++ programs and we can try and make sure they, um, crash less often.

    21. LF

      Yeah.

    22. BS

      The way you do that-

    23. LF

      Mm-hmm.

    24. BS

      ... 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-

    25. LF

      Mm-hmm.

    26. BS

      ... 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."

    27. LF

      No simpler. But how do you-

    28. BS

      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.

    29. LF

      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?

    30. BS

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

  8. 36:44 – 41:15

    Static analysis explained: finding bugs before runtime (and avoiding impossible proofs)

    1. BS

      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-

    2. LF

      Can you describe what static analysis is?

    3. BS

      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-

    4. LF

      (laughs)

    5. BS

      ... it becomes impossible.

    6. LF

      Yeah.

    7. BS

      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-

    8. LF

      Mm-hmm.

    9. BS

      ... for static analysis, you can run through a program, and you can try and figure out if there's any leaks. And what you'll probably find is that you will find some leaks, and you'll find quite a few places where your analysis can't be complete. It might depend on runtime. It might depend on, um, the, the cleverness of your analyzer, and it might take a long time. Some of these programs run for a long time. But if you combine such analysis with a set of rules that says how people could use it, you can actually see why the rules are violated, and that stops you from getting into the impossible com- uh, complexities. You don't want to solve the halting problem.

    10. LF

      So static analysis is looking at the code without running the code.

    11. BS

      Yes.

    12. LF

      And thereby, it's almost not a production code, but it's almost like an educational tool of how the language should be used. It guides you. Like, at, at its best, right, it would guide you in how you write future code as well, and you learn together.

    13. BS

      Yes. So basically, you need a set of rules for how you use the language. Then you need a static analysis that catches, um, your mistakes when you violate the rules or when your code ends up doing things that it shouldn't despite the rules because those are the language rules. We can go further. And again, it's back to my idea that I would much rather find errors before I start running the code. If nothing else, once the code runs, if it catches an error at runtimes, I have to have an error handler.

    14. LF

      Hm.

    15. BS

      And one of the hardest things to write in code is error-handling code because you know something went wrong. Do you know really exactly what went wrong? Usually not. How can you recover when you don't know what the problem was?

    16. LF

      (laughs) Yeah.

    17. BS

      You can't be 100% sure what the problem was in many, many cases. And s- this is, this is part of it. So yes, we, we, we, we need good languages with good type systems. We need rules for how to use them. We need static analysis, uh, and the ultimate for static analysis is, of course, program proof, but that still doesn't scale to the kind of systems we deploy. Then we start needing, uh, testing and uh, the rest of the stuff.

  9. 41:15 – 47:09

    C++ design philosophy: not ‘OO language,’ but multi-paradigm with guiding principles

    1. LF

      So C++ is an object-oriented programming language that creates, especially with its newer versions as we'll talk about, higher and higher levels of abstraction. So how do you design... Let's even go back to the origin of C++. How do you design something with so much abstraction that's still efficient and is still something that you can manage, do static analysis on, you can have constraints on, that can be reliable, all those things we've talked about? So create... The, the, to me, slightly... There's a slight tension between high-level abstraction and efficiency.

    2. BS

      That's a good question. I could probably have a years course-

    3. LF

      Yeah.

    4. BS

      ... uh, just trying to answer it. Yes, there's a tension between efficiency and abstraction, but you also get the interesting situation that you get the best efficiency out of the best abstraction. And my main tool for efficiency, for performance, actually, is abstraction. So let's go back to how C++ got there.

    5. LF

      Yeah.

    6. BS

      You said it was an object-oriented programming language. I actually never said that.

    7. LF

      (laughs)

    8. BS

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

    9. LF

      But it's not.

    10. BS

      "... and other techniques."

    11. LF

      Hm.

    12. BS

      And that, that's important because I think that the best solution to most complex, interesting problems require-... ideas and take techniques from things that have been called object-oriented, um, data abstraction, functional, uh, traditional C-style code. All of the above.

    13. LF

      Mm-hmm.

    14. BS

      And so when I was designing C++, I soon realized I couldn't just add features. If you just add what looks pretty, or what people ask for, or what you think is good, one by one, you're not going to get a coherent whole. What you need is a set of guidelines that... that, that, that guide your decisions. Should this feature be in or should this feature be out? How should a feature be modified before it can go in and such? And there's a... In, in the book, I wrote about that, the design evolution of C++. There's a wh- a whole bunch of, of rules like that. Most of them are not language technical. They, they, they're things like don't violate static type system, because I like static type system for the obvious reason that I like things to be reliable on reasonable amounts of hardware. But one of these rules is, uh, is the zero overhead principle.

    15. LF

      The what kind of pr-

    16. BS

      The zero overhead principle.

    17. LF

      Mm-hmm.

    18. BS

      It basically says that if you have an abstraction, it should not cost anything compared to write the equivalent code at a lower level. So, if I have, say, a, a matrix multiply, it should be written in such a way that you could not, uh, drop to the C level of abstraction and use arrays and pointers and such and run faster. Um, and so people have written such, um, matrix multiplications and they've actually gotten code that ran faster than Fortran because-

    19. LF

      Mm-hmm.

    20. BS

      ... 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.

    21. LF

      Mm-hmm.

    22. BS

      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.

  10. 47:09 – 54:45

    How zero-overhead works in practice: compilers, techniques, and multi-compiler ecosystems

    1. LF

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

    2. BS

      And we meet it quite often.

    3. LF

      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-

    4. BS

      Mm-hmm.

    5. LF

      ... 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?

    6. BS

      And.

    7. LF

      And?

    8. BS

      Not or.

    9. LF

      (laughs)

    10. BS

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

    11. LF

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

    12. BS

      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.

    13. LF

      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.

    14. BS

      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.

    15. LF

      Mm-hmm.

    16. BS

      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.

    17. LF

      Monocultures?

    18. BS

      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.

    19. LF

      Mm-hmm.

    20. BS

      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.

    21. LF

      (laughs) Competition is good.

    22. BS

      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.

    23. LF

      (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?

    24. BS

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

    25. LF

      But there's been C++11, 14, 17, 20, you know? There's been a lot of feature-

    26. BS

      I think sooner or later somebody's going to try again. There has been attempts, uh, to write new C++ compilers, and some of them has been used and some of them has been absorbed into others and such. Yeah, it'll happen.

  11. 54:45 – 1:08:02

    Core C++ building blocks: classes, inheritance, templates, and efficient implementation tricks

    1. LF

      So, what are the key features of C++? And let's use that as a way to sort of talk about the evolution of C++, the new features. So, at the highest level, what are the features that were there in the beginning? What features got added?

    2. BS

      Let's first get a, a principle, uh, or an aim in place. Um, C++...... is for people who want to use hardware really well and then manage the complexity of doing that through abstraction.

    3. LF

      Mm-hmm.

    4. BS

      And so, the first facility you, you have is a way of manipulating the machines at a fairly low level. That looks very much like C. It has loops, it has variables, it has pointers with, like, machine addresses. It can access memory directly. It can allocate stuff in the absolute minimum of space needed on the machine. There's a machine-facing part of C++, which is roughly equivalent to C. I said C++ could beat C, and it can. It doesn't mean I dislike C. If I disliked C, I wouldn't have built on it. Furthermore, after Dennis Ritchie, I'm probably the major contributor to modern C. And, well, I had lunch with Dennis, uh, most days for 16 years, and we, we n- we never had a, a, a harsh word between us. So, uh, these C versus C++ fights are, are for people who don't quite understand what's going on. Uh, then the other part is the abstraction, and there, the key is the class, which is a user-defined type. And my idea for the class is that you should be able to build a type that's just like the built-in types in, in the way you use them, in the way you declare them, in the way you get the, the memory, and you can do just as well. So, in C++ there's an int, as in C. You should be able to build an abstraction, a class, which we can call capital int, that you could use exactly like an integer and run just as fast as an integer. There's the idea right there. And of course, you probably don't want to use the int itself, but it has happened. People have wanted integers that were range-checked so that you couldn't overflow and such.

    5. LF

      Yeah.

    6. BS

      Basically for very safety-critical, uh, applications, like the fuel injection for a marine diesel engine for the largest ships. This is a real example, by the way.

    7. LF

      Mm-hmm.

    8. BS

      Th- this has been done. They, they built themselves an integer that was just like integer except that it couldn't overflow. If there was an overflow, you went into the error-handling. Um, and then you built more interesting types. You, you, you can build a, a matrix, which you need to do graphics, or you could build a gnome for a, um, for a video game.

    9. LF

      Mm-hmm. And all of these are classes and they appear just like the built-in types?

    10. BS

      Exactly.

    11. LF

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

    12. BS

      And flexibility.

    13. LF

      So, uh, I don't know, for people who are not familiar with object-oriented programming, there's inheritance. There's a hierarchy of classes. You, you can, just like you said, create a generic vehicle-

    14. BS

      Yep.

    15. LF

      ... that can turn left.

    16. BS

      So, what people found was that you don't actually know... How do I say this? A lot of types are related. That is, uh, the vehicles, all vehicles are related. Bicycles, cars, fire engines, tanks. They have some things in common and some things that differ and you would like to have the common things common and having the differences, uh, specific. And when you didn't want to know about the differences, like, just turn left.

    17. LF

      Mm-hmm.

    18. BS

      Um, you, you, you, you, you don't have to worry about it. That's how you get the traditional object-oriented programming coming out of SIMULA, adopted by Smalltalk and C++ and all, all the other languages. The other kind of obvious similarity between types comes when you have something like a vector.

    19. LF

      Mm-hmm.

    20. BS

      Fortran gave us the vector as called array of, um, doubles.

    21. LF

      Mm-hmm.

    22. BS

      But the minute you have a vector of doubles, you want a vector of double-precision doubles and for short doubles for graphics, and why should you have, not have a vector of integers while you're at it, or vet- vector of vectors and a vector of vectors of chess pieces? Now you have a board, right? So, this 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.

    23. LF

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

    24. BS

      Yep.

    25. LF

      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.

    26. BS

      Mm-hmm. Mm-hmm.

    27. LF

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

    28. BS

      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.

    29. LF

      Implementation.

    30. BS

      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.

  12. 1:08:02 – 1:18:21

    Concepts (C++20): compile-time requirements for templates, and why it took decades

    1. LF

      And then there's this idea of concepts-

    2. BS

      Yes.

    3. LF

      ... that puts some ... Now, I've never even ... J- I don't know if it was ever available in any form, but, uh, it puts some constraints on the stuff you can parametrize, essentially?

    4. BS

      Uh, let me try and explain.

    5. LF

      Yes .

    6. BS

      Um, so yes, it wasn't there 10 years ago. We have had versions of it that actually work for the last four, five years. Um, it was a design by Gaby Dos Reis, uh, Andrew Soddon, and me. We were professors and post-docs in Texas at the time. And, um, the implementation by Andrew Soddon has been available for, uh, that time, and it is part of C++20. Uh, and there's a standard library that uses it. So, this is becoming really very real. It's available in, uh, Clang and, and GCC. Uh, GCC for a couple of years, and I believe Microsoft is soon, soon going to do it. We expect all of C++20 to be available, so in all the major compilers in '20. But this kind of stuff-

    7. LF

      Can y-

    8. BS

      ... is, is available now.

    9. LF

      Yeah.

    10. BS

      I'm just saying that because otherwise people might think I was talking about science fiction. And so what I'm going to say-

    11. LF

      This is real.

    12. BS

      ... is concrete. You can run it today, and there's production users of it. So, the basic idea is that when you have a, a, a generic component, uh, like a sort function, the sort function will, will require at least two parameters. One, uh, a data structure with a given type, and a comparison criteria. And these things are related, but, um, obviously you can't compare things if you don't know what the type of the things you compare. And so, you want to be able to say, "I'm going to sort something, and it is to be sortable." What does it mean to be sortable? You look it up in the standard. It has to have ... It has to be a sequence with a begin and an end.

    13. LF

      Mm-hmm.

    14. BS

      There has to be random access to that sequence, and there has to be ... Um, the, the element types has to be comparable. By default, by less than.

    15. LF

      Which means less than operator can operate on them.

    16. BS

      By ... By ... Yes.

    17. LF

      Lots of logical operators can operate on them.

    18. BS

      So, basically, what concepts are, they're compile time predicates. They're predicates you can ask, "Are you a sequence?"

    19. LF

      Mm-hmm.

    20. BS

      "Yes, I have a begin and end." "Uh, are you a random exit sequence?" "Yes, I have, uh, subscripting and plus." "Uh, is your element type something that has a less than?" "Yes, I have a less than. It's &." So basically, that's the system. And so instead of saying, "I will take a parameter of any type," it'll say, "I'll take something that's sortable and it's well-defined." And so we say, "Okay, um, you can sort with less than. I don't want less than. I want greater than, or s- or something I invent." So, you have two parameters, the sortable thing and the, uh, comparison criteria. And the comparison criteria will say, "Well, I can, um ... You, you can write it saying it, it should operate on the element type, and it has the comparison operations." So, that's th- simply the fundamental thing. It's compile time predicates. Do you have the properties I need?

    21. LF

      Mm-hmm.

    22. BS

      So, it specifies the requirements of the code on the parameters that it gets.

    23. LF

      At compile time.

    24. BS

      It's very similar to types, actually.

    25. LF

      But operating in the space of concepts. (laughs) So-

    26. BS

      Yeah, concepts. Uh, the, the word concept was, uh, used by Alex Stefanov, who is sort of the father of generic programming in the context of C++. You know, there's other pla- uh, places that use that word, but the way we call generic programming is Alex's. And he called them concepts because he said they're, they're the sort of the fundamental concepts of an area, so they should be called concepts.

    27. LF

      (laughs)

    28. BS

      And we've had concepts all the time. If you look at the K&R book about C, C has arithmetic types and it has, um, um, integral types. It says so in the book. And then it lists what they are, and they have certain properties. The difference today is that we can actually write a concept that will ask a type, "Are you an integral type?"

    29. LF

      Mm-hmm.

    30. BS

      "Y- Do you have the properties necessary to be an integral type? Do you have plus, minus, divide, and such?"

  13. 1:18:21 – 1:28:06

    How C++ gets standardized: committee mechanics, consensus, and the shift to 3-year releases

    1. LF

      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?

    2. BS

      Sure.

    3. LF

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

    4. BS

      Okay.

    5. LF

      What's the discussion like?

    6. BS

      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.

    7. LF

      Right, the old, the old bus, right?

    8. BS

      "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-

    9. LF

      A carrot and stick.

    10. BS

      ... it got started.

    11. LF

      Yep.

    12. BS

      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.

    13. LF

      (laughs)

    14. BS

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

    15. LF

      Right.

    16. BS

      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.

    17. LF

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

    18. BS

      Yes.

    19. LF

      'Cause, 'cause it's basically-

    20. BS

      Or, or individuals.

    21. LF

      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.

    22. BS

      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.

    23. LF

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

    24. BS

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

    25. LF

      Yeah.

    26. BS

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

    27. LF

      It's like democracy, right?

    28. BS

      But we... exactly. Uh, 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, uh, we, 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, uh, another 15 to 20 are, are sort of looking and then voting based on the rest of the work on it. A- and we meet three times a year. Uh, next week, I'll be in Cologne, Germany, uh, spending a week, uh, doing standardization, and we'll vote out the committee draft, or C++20, which goes to the national, uh, standards committees for comments and requests for changes and improvements. Then we do that, and there's a second, uh, 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, um, and it was an international standard. All the countries voted in favor. Um, it took longer with 11. I'm not gonna mention why, but all the nations voted in favor. Uh, and we work on the basis of, uh, consensus. That is, we do not want something that passes 60/40, uh, because then we're going to get dialects and opponents and people complain too much. Eh, they all complain too much, but, eh, basically-

    29. LF

      Eventually, you won.

    30. BS

      ... it has no real effect. The, the standards has been obeyed. They have been working to make it, uh, easier to use many compilers, many computers, and all of that kind of stuff. And so the first... The, the, the... it was traditional with ISO standards to take 10 years. We did the first one in eight brilliant.

  14. 1:28:06 – 1:31:53

    The most beautiful C++ feature: RAII, constructors/destructors, and the ‘life cycle’ of objects

    1. LF

      There's a lot of features that came in in C++11. There's a lot of features at the birth of C++ that were amazing and ideas with concepts in 2020. What to you is the most, just, just to you personally, beautiful or just you sit back and think, "Wow, that's just nice and clean feature of C++"?

    2. BS

      I have written two papers for the History of Programming Languages Conference, which basically asked me such questions. And I'm writing a third one, which I will deliver, uh, at the History of Programming Languages Conference in London next year. So I've been thinking about that, and there is one clear answer, constructors and destructors. The way a constructor can establish the environment for the use of the, of a type, for an object, and the destructor that cleans up any messes at the end of it. That is the key to C++. That's why we don't have to use garbage collection. That's how we can get predictable perf- performance. That's how you can get, um, the minimal overhead in many, many cases and have really clean types. It's the idea of constructor/destructor pairs. Sometimes it comes out under the name RII, um, RAII, resource acquisition is initialization, which is the idea that you grab resources in the constructor and release them in destructor. Um, it's also the best example of why I shouldn't be in advertising.

    3. LF

      (laughs)

    4. BS

      I get the best idea and I call it resource acquisition is initialization. Um, not the greatest naming I've ever heard.

    5. LF

      (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++-

    6. BS

      Yes.

    7. LF

      ... 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-

    8. BS

      Um, a, a little bit-

    9. LF

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

    10. BS

      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-

    11. LF

      Hmm.

    12. BS

      ... 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-

    13. LF

      Mm-hmm.

    14. BS

      ... 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.

    15. LF

      Mm-hmm.

    16. BS

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

    17. LF

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

    18. BS

      Yes.

  15. 1:31:53 – 1:44:21

    Future of languages and ‘fuzzy programming’: convergence of principles, and limits of ML reliability

    1. LF

      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.

    2. BS

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

    3. LF

      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?

    4. BS

      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.

    5. LF

      Mm-hmm.

    6. BS

      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.

    7. LF

      There's too many parentheses.

    8. BS

      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.

    9. LF

      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-

    10. BS

      Yeah.

    11. LF

      ... 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?

    12. BS

      Uh, I-

    13. LF

      Do you think that's possible?

    14. BS

      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.

    15. LF

      Right.

    16. BS

      Modern computing started in about '49. Hmm, we've got, what is that? Uh, 70 years. They have 10, 10 times.

    17. LF

      Yeah.

    18. BS

      And furthermore, they, they, they're not as bothered with people using physics, uh, the way we are worried about programming is done by humans.

    19. LF

      Sure.

    20. BS

      So, uh, each have, um, problems and constraints the others have, but we are very immature compared to physics. Um, so I would look at sort of the philosophical level a- and, and look for fundamental principles. Like you don't leak resources you shouldn't. Uh, you don't take errors at runtime that you don't need to. Um, you don't violate some kind of type system. There's many kinds of type systems, but when you have one, you don't break it, um, et cetera, et cetera. Uh, there, there will be quite a few and it'll not be, uh, be the same for all languages. But I think we ... If we step back at some kind of philosophical level, we can ... We would be able to agree on sets of principles that applied to, to, to sets of problem areas. And within an area of use, like in c++'s case, uh, what used to be called systems programming, the area between the hardware and the, the, the, the fluffier parts of the system, you, you might very well see a convergence. So these days you see Rust having a, uh, adopted RAII and sometime accuses me for having borrowed it 20 years before they discovered it.

    21. LF

      (laughs)

    22. BS

      But, um, it's, uh, uh, we're, we're seeing some kind of conversion, uh, con- convergence here instead of, um, relying on garbage collection all the time. The garbage collection languages are, are doing things like the, uh ...... uh, dispose patterns and such that imitates, uh, some of the, uh, construction/destruction stuff, and they're trying not to use the garbage collection all the time and things like that. So, there's- there- there's conversion, but I think we have to step back to the philosophical level, agree on principles, and then we'll see some conversions co- con- convergences, and it will be application domain specific.

    23. LF

      So, a crazy question, but I work a lot with machine learning, with deep learning. I'm not sure if you touch that world m- much, but y- you could think of programming as a thing that takes some input... Uh, uh, programming is the task of creating a program, and the program takes some input and produces some output. So, machine learning systems train on data in order to be able to take an input and produce output, but they're messy, fuzzy things. Much like, uh, we as children grow up, you know, we take some input, we take, make some output, but we're noisy, we mess up a lot, we're definitely not reliable. Biological system are a giant mess. So, there's a sense in which machine learning is a kind of way of programming, but just fuzzy.

    24. BS

      Mm-hmm.

    25. LF

      It's very, very, very different (laughs) than C++. 'Cause C++ is a, like, it's just like you said, it's extremely reliable, it's efficient, it's, uh, you know, you can- you can measure, you can test it in a bunch of different ways. With biological systems, or machine learning systems, you can't say much except sort of empirically saying that 99.8% of the time, it seems to work. Uh, what do you think about this fuzzy kind of programming? I- and- and do you- do you even see it as programming? Is it solely and totally another kind of world?

    26. BS

      Mm-hmm. I- I think it's a different kind of world, uh, and it is fuzzy, and in my domain, I don't like fuzziness.

    27. LF

      (laughs)

    28. BS

      That is, people say things like they want everybody to be able to program, but I don't want everybody to program my, um, my- my- my- my aeroplane controls or the car controls. Uh, I want that to be done by engineers. I want that to- to be done with people that are specifically educated and trained for doing, uh, building things, and it is not for everybody. Similarly, a language like C++ is not for everybody. It is generated to be a sharp and effective tool for, uh, professionals basically, uh, and definitely for people who- who- who aim at some kind of precision. You don't have people doing calculations without understanding math.

    29. LF

      Mm-hmm.

    30. BS

      Right? Uh, counting on your fingers is not going to cut it if you want to fly to the moon. And, um, so there are areas where an 84% accuracy rate, uh, 16%, um, false positive rate is perfectly acceptable and where people will probably get no more than 70. You said 98%, I- m- th- what I have seen is more like 84-

  16. 1:44:21 – 1:46:29

    Looking back: impact, community, and seeing C++ power real-world engineering

    1. LF

      When you look back at your life work, what is a, what is a moment, what is a event, creation, that you're really proud of, that you say, "Damn, I, I did pretty good there?" Is it as obvious as the creation of C++?

    2. BS

      It's obvious. I've spent a lot of time with C++, and it's a combination of a few good ideas, a lot of hard work, and a bit of luck. And I've tried to get away from it a few times, but I get dragged in again, partly because I'm most effective in this 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

Install uListen for AI-powered chat & search across the full episode — Get Full Transcript

Transcript of episode uTxRF5ag27A

Get more out of YouTube videos.

High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.

iOSAndroidClaudeChrome