Creator of C++: Bell Labs, Negative Overhead Abstraction, Mistakes | Bjarne Stroustrup

Bjarne Stroustrup is the creator of the C++ programming language and a former researcher at Bell Labs. We talked about what Bell Labs was like, programming language design, and interesting anecdotes from his experience. • My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/ 𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀: • YouTube: https://youtu.be/U46fJ2bJ-co • Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 • Transcript: https://www.developing.dev/p/creator-of-c-bell-labs-negative-overhead 𝗧𝗵𝗮𝗻𝗸 𝘆𝗼𝘂 𝘁𝗼 𝘁𝗵𝗶𝘀 𝗲𝗽𝗶𝘀𝗼𝗱𝗲'𝘀 𝘀𝗽𝗼𝗻𝘀𝗼𝗿𝘀 𝗳𝗼𝗿 𝘀𝘂𝗽𝗽𝗼𝗿𝘁𝗶𝗻𝗴 𝗺𝘆 𝘄𝗼𝗿𝗸: • Cursor 3: a unified workspace for building software with agents, check it out at https://cursor.com/ • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/ 𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀: 0:00 - Intro 0:50 - The origin of C++ 8:46 - What Bell Labs was like 17:24 - Dennis Ritchie 24:00 - When to build a programming language 31:59 - Bootstrapping a language 33:58 - C++ is not object-oriented 37:32 - Discussing type systems 46:20 - Memory safety 49:26 - Standards committee anecdotes 1:09:40 - Adding automatic garbage collection to C++ 1:18:25 - Template instantiation is Turing complete 1:21:57 - Abstraction and performance 1:28:51 - AI writing code 1:35:54 - His motivation 1:39:18 - Famous quotes 1:46:48 - Reflecting on building C++ 1:49:12 - Top C++ book recommendation 1:50:59 - Advice for his younger self 1:58:06 - Outro 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗕𝗷𝗮𝗿𝗻𝗲: • Wikipedia: https://en.wikipedia.org/wiki/Bjarne_Stroustrup • Personal Website: https://www.stroustrup.com/ 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman 𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝗱 𝗶𝗻 𝘁𝗵𝗶𝘀 𝗲𝗽𝗶𝘀𝗼𝗱𝗲: • "A History of C++": https://www.stroustrup.com/hopl2.pdf • "Evolving a language in and for the real world": https://www.stroustrup.com/hopl-almost-final.pdf • "Thriving in a Crowded and Changing World": https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2184r0.pdf • The lecture where he mentioned he lost half his hair: https://youtu.be/69edOm889V4?si=IAZxYNwlUALodEV7&t=474 • Quotes I pulled: https://www.stroustrup.com/quotes.html

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  There wasn't a language in the world that could do what I needed.

• 0:03Ryan Peterman?

  This is Bjorn Stroves, creator of C++ and we talked about his career starting with Bell Labs. What gave you the conviction to fly on your own tab?

• 0:14Speaker 00

  It was the best place in the world, right? I mean, do you need anymore?

• 0:18Ryan Peterman?

  And I also asked him all about programming language design. What was the most technically challenging part to implement?

• 0:26Speaker 00

  Everybody asked that question, and I think it's a wrong question.

• 0:30Ryan Peterman?

  But I tend to think that more abstraction costs you something.

• 0:33Speaker 00

  It's not the case. We can do negative overhead abstraction.

• 0:38Ryan Peterman?

  Is there any part where you think, oh, that was a mistake?

• 0:42Speaker 00

  I should have fought harder for that.

• 0:44Ryan Peterman?

  Here's the full episode.

• 0:50Ryan Peterman?

  What is the origin story behind C++?

• 0:54Speaker 00

  Well, let's start from the real beginning. I got a job at Bell Labs, which is a really great place over in New Jersey. It's not like that anymore, but at the time it was the best applied math, the applied engineering place in the world. I looked around, you know, the great people who were there. They built Unix, they built C, they did a lot of the theory behind it. And I realized I had to do something important, otherwise I didn't belong. So I decided I was going to build a distributed Unix,

• 1:35Speaker 00

  because it was clear that computers were getting better, networking was getting better. So we need some of those, one of those. And if I'd succeeded, it would, we would have had Unix clusters 10 years earlier, or something like that. But of course I couldn't do it. That's not a one-person job. But the first thing I realized was, there wasn't a language in the world that could do what I needed. It needed two things: low-level access to hardware, so to memory managers, process implementations, process scheduler,

• 2:16Speaker 00

  network drivers, device drivers, all that kind of stuff. And then it needed high-level things that says, "Well, there's a module here on this computer and there's a module there on that computer, and here's the communication protocol they're using," things like that. And there's lots of languages that could do either, none that could do both. The obvious language for the low-level stuff was C, because Walt Dennis Ritchie and Brian Kearney and was down the hall. And I said, "Distribute Unix," because I was in the home where Unix was invented and still being built.

• 3:02Speaker 00

  And for the high-level languages, there was a fair number, but they were all too slow and they couldn't manipulate hardware. But I had learned to use Simula. I knew Christ Nego and Uljan Dahl that invented object-oriented programming and Simula. And so I decided I had to merge these two. And the way that was practical was to take the class concept from Simula and stick it into C so that it could run much, much faster and be used for systems programming. And at the same time, I made the type system a bit more regular,

• 3:47Speaker 00

  user-defined types, classes, was handled the same way as built-in types. And that's basically the start of what neither C nor Simula could do, which gets us to generic programming eventually. Many years later, I had to add overloading. I mean, we have always had overloading. You can add to integers, you can add to...

• 4:16Speaker 00

  Floating point numbers, you can add a floating point number to an integer with a plus, that's a single name, right? And so I had to generalize that to be able to have unique set of rules for both building and user-defined types. So that's where it came from.

• 4:35Ryan Peterman?

  In one of the lectures that I saw that you gave, you talked about rewriting a simulator in B C P L. Is that the distributed Unix work or?

• 4:46Speaker 00

  No, no, that's before that. I went to Cambridge, England to get a PhD. And at some point, I decided I needed a simulator or software on a distributed system to do the PhD work on distributed systems. And of course, the idea of distributed Unix, three or four years later, came out of the same way of thinking. But what I did was I wrote a really nice simulator in Simula. Simula is very good at that.

• 5:29Speaker 00

  It's misnamed because it was a general-purpose programming language and it's having a bad name didn't help it at all. But anyway, I wrote this simulator and I wrote little examples, test cases, et cetera, et cetera. It all worked nicely. Then I tried the first real run, full scale, and I took the department's mainframe and used it for a very significant time. And, well, PhD students can't do that. That's the chemists and the astrophysicists and such would never accept it.

• 6:13Speaker 00

  So I was kicked off the machine. And it was clear that Simula could write, I could write the program in Simula very well, but I couldn't afford to run it. So I took the ideas and I moved it to a little-used experimental computer, which was the CAP computer, which had hardware protection and capabilities and great stuff for hardware. And it was somewhat unusual, so the astrophysicists couldn't use it. They weren't computer scientists as such, but I could. And so the only problem was I couldn't run Simula there,

• 6:57Speaker 00

  because Simula was never ported on that kind of machine, and it was being used on mainframes and it was proprietary, and everything was wrong in the context of the CAP computer. So I basically rewrote my simulator in BCPL. And BCPL is a language that'll make C look like a high-level language. And like it has only one data type, the word. And it was a very painful exercise.

• 7:36Speaker 00

  But once I'd done it, my program ran, I guesstimated, about 50 times faster. And I got my data and I got my PhD, so that was good. But I was convinced I would never again attempt a problem with tools that inadequate, as I had tried it on the mainframe in Cambridge. And so I had a list of things that my ideal language should have.

• 8:15Speaker 00

  Well, C++ Simul, I didn't have all of that, but it came closer than any other language that existed. C++ came out of there.

• 8:25Ryan Peterman?

  Yeah, in that lecture, you said something like that, writing that program in B C P L was so difficult, you lost half your hair debugging.

• 8:35Speaker 00

  That's almost exactly true, and I lost the other half getting C++ going over the years, but anyway, it worked.

• 8:46Ryan Peterman?

  You mentioned Bell Labs, and I think there's a lot of curiosity about that topic, just because it's such a legendary place. When you had graduated from your PhD and you were thinking about where to work, socially, what was Bell Labs known as at that time?

• 9:05Speaker 00

  Bell Labs was the place to go if you wanted to practice engineering at a large scale, sort of world-class, and I think it was easily the best. I mean, we probably had twice as many computer scientists as MIT at the time, things like that. And the Computer Science Research Center had great people, and some of them had come from Cambridge.

• 9:42Speaker 00

  And one day in my last year in Cambridge, one of the people from Bell Labs came along to give a talk, and give a talk, and the tradition in England and in the computer lab is after a day's work, you go to the pub and you chat with other people to see what has been going on. And he says, well, when you need a job, give us a buzz. And so I did, and I flew over to New Jersey on my own tab, actually. And my leader boss, Sandy

• 10:25Speaker 00

  Fraser, great guy, working with networking, told me that I'd come at a wrong time, they didn't have any jobs. This is not what you want to hear when you've just flown over the Atlantic. Anyway, the next day I gave a talk to a development group, not the research group. And then they changed their minds and took me up to the research group and I worked there for for the next couple of decades.

• 10:53Ryan Peterman?

  What was the interview process like?

• 10:56Speaker 00

  You just talked to some people. I mean, I remember having a longest chat with Dennis Ritchie, for instance. And I talked to people doing networking mostly. There wasn't a interview process as such. They hadn't actually hired anybody new for five years. So, no, they just did it by the seat of the pants.

• 11:27Ryan Peterman?

  So it's kind of like the the belief and credibility that other people say that you have, like Dennis Ritchie talked to you and he knew that you knew at your time?

• 11:39Speaker 00

  Sandy Fraser and such, they just talk to you and see what you know and don't know. And at the end, they go to the director and says, in this case, we've got a good guy. Can you give us a, let us have him? I, of course, didn't know anything about that. I wasn't there. I was out talking to somebody in California and I get a phone call from the director and says, would you like to come and work here? A week later.

• 12:10Ryan Peterman?

  What gave you the conviction to fly on your own tab to go and, you know, there wasn't even a promise of a job yet?

• 12:17Speaker 00

  No, well, it was the best place in the world, right? I mean, do you need any more?

• 12:25Speaker 00

  It, I mean, if it worked, it was the best. And if it didn't work, so what? I mean, you can't succeed at everything.

• 12:34Ryan Peterman?

  Today, there's more, industry has a stronger pull. At that time, would it have been IBM or something that would have been the best industry?

• 12:43Speaker 00

  I talked to IBM. They weren't as good as the Bell Labs Computer Science Research Center. I was up at Yorktown Heights and I talked to the researchers and I talked to the young researchers and I just didn't think they were doing the right stuff. And not in the right way. And they were much more controlled and directed than the researchers at Bell Labs.

• 13:12Ryan Peterman?

  At a place like Bell Labs, how does project selection go? Like, how does, how does all that work once you're employed?

• 13:20Speaker 00

  Oh, at the time, and I think still, there are two philosophies about how to get good research. The one is that you have a well-designed project, chosen carefully by management and higher management, seriously funded, and maybe you do put 20 or 30 people at the problem and you solve it and you have something great. The other philosophy is you hire the best people you can find and don't tell them what to do.

• 14:00Speaker 00

  I mean, my job was described as, do something interesting. In a year's time, tell us what you did. And if we like it, we'll extend, we'll give you the same deal next year. And by the way, the way you tell us, you write one sheet of paper using more than nine, nine-point font or more. Because if you can't say what you did in fairly briefly, you probably haven't done something interesting enough. Very unusual. So there.

• 14:45Speaker 00

  They were actually worrying when they built Unix, because it eventually involved five or seven people. And it was getting too big for that model of the world, of individuals doing interesting things.

• 15:03Speaker 00

  Very different. I would say that, on average, this fairly anarchic organization did better than the well-organized thing. Most of the things you've heard of from Bell Labs came out of there. And then, in other part of the building, they were doing hardware things. So fibers, as we use them today, came out of there. A lot of the wireless technology came out of there. The charge couple devices, that are our cameras, came out of there.

• 15:43Speaker 00

  They tried to do videophones and couldn't get it to work, because, well, hardware hadn't grown up to it, but they were trying to do it. The system of cells for cellphones came out of, not that building, but another building for Bell Labs. It was just a great place. And so, the computer science people tended to talk to people doing other things. So I remember, when I was doing simulations, I was helping somebody building a simulator for some networking stuff. A lot of early C++ had to do with doing things like, what happens when a network get overloaded?

• 16:26Speaker 00

  How do we handle the overload protocols? And in this particular case, they did a good job, and they called me back, and they had a slightly bigger problem. They wanted to simulate the computer traffic of Manhattan. Even then, my answer was no. We don't have the compute power to do that.

• 16:53Speaker 00

  It doesn't matter how good C++ is, the computers of today can't do it.

• 17:02Ryan Peterman?

  Back then though, but now.

• 17:04Speaker 00

  Now they probably could, but of course the computer traffic has become much more, so maybe they can't. I don't know. I don't have the numbers now. Then I, they gave me the numbers. That was why I declined to help them, because it was impossible.

• 17:24Ryan Peterman?

  I saw somewhere, when I was doing my research, that you said you had gotten lunch with Dennis Ritchie once a week for like 16 years or something like that. And, you know, he's also a very legendary name. And I was curious, you know, if there's anything that you learned from him, or anything that impressed you about him that maybe influenced you or C++?

• 17:49Speaker 00

  He was a great guy, and we talked about a lot of things. He never said anything rude or negative about C++ Actually, in his Hubble paper, he points to C++ as the obvious successor to C. So all of these C versus C++ language wars are ridiculous. They should never have happened, and they certainly didn't happen because, well, I knew Dennis. We were not fighting. I still know Brian Kearney, and I was talking to him this Friday.

• 18:33Speaker 00

  We're good friends. And yeah, language wars are silly. Dennis helped me design const, for instance, for C++ It used to be called read only and write only, but the C guys couldn't handle two words, and they were too long. So we got what we got. But that's one specific thing I remember Dennis being helpful with. He was a bit worried that about overloading, because you had to look at the

• 19:13Speaker 00

  declarations of functions before you knew what the meaning of a call was. But that's a very reasonable way of thinking. It's just happens that it it works. And anybody who writes C today are using my handiwork essentially all of the time. Because the the modern syntax for function definitions and function declarations and the call semantics came out of the early C++ early C O classes work of mine.

• 19:54Speaker 00

  So when when people start writing, they they should remember that they're actually doing my using my handiwork every day.

• 20:04Ryan Peterman?

  You had written these almost like historical accountings of the history of C++ like maybe three really long papers. I think for some conference, I forgot the exact. And so in there, there was one anecdote about Dennis Ritchie. It was it was about this this concept where he proposed to the C standard committee, this idea of a fat pointer where it, you know, also has it stores its size as well. And you mentioned the C committee didn't approve, and I was curious if you could like tell that.

• 20:42Speaker 00

  So Dennis did see, but he didn't take part in the standards committee. And I've even heard people from the C standards committee says, no, Dennis isn't a C expert. He's not ever come to meetings.

• 20:59Speaker 00

  Very strange attitude. But anyway, we knew the problem about.

• 21:07Speaker 00

  About buffer overflow and range errors. And the obvious solution is to use what Dennis called a fat pointer, which is a pointer with its number of elements it points to attached to it. But that's two words and that's probably, no. That is why it wasn't used on the early C. Because then they had forty eight K of memory. And when I had this discussion with Dennis, I think we had a whole megabyte. And when I started with C++ we had two hundred and fifty six kilobytes.

• 21:49Speaker 00

  And I knew that we were going to get a megabyte. And we were talking about it and he called them fat pointers. And today in C++ they're called span. And the span came out of my work with others on the C++ core guidelines. And we needed something like that. We couldn't provide the degree of control and safety that we needed. So we built span and it came into the standard a bit later. But some of these ideas are very old.

• 22:30Ryan Peterman?

  When you put together really impressive people, like, you know, the world's greatest people, that you look around and you see how great the other people are. And even though each individual is great, just the greatness of others can give people this feeling of imposter syndrome that's not necessarily founded. Is that something that you ever felt or saw at Bell Labs?

• 22:52Speaker 00

  Definitely. Maybe I still got a bit of it. But certainly when I came to Bell Labs and saw the names on the doors and I'd read the papers and they'd created the fields I liked to work in. Yeah, I thought I have to up my game. I have to do something bigger and better than what I had imagined.

• 23:17Speaker 00

  Also, you talk to them and you learn things. I mean, I learned a lot over lunch, where there's a bunch of them talking about what they're doing and why they're doing it. There's some places that has that effect on people and has this density of talent. Cambridge University was, computer science was, one of those places, I learned a lot there. And the doors were always open. It was sort of, almost a policy that we kept the doors open. Because how else would people be able to come and talk?

• 24:02Ryan Peterman?

  When we talk about a programming language and just generally like language design, if I was to want to build a programming language today, what are all the pieces that you'd need to build to make a programming language?

• 24:17Speaker 00

  Well, that's a relatively easy question to answer. And everybody asks that question. And I think it's a wrong question. What you need is a problem that needs a solution. A lot of people just want to build a language that is better at what they are doing now and what they particularly are doing. And most of the time, that can be done reasonably well with existing languages. And if you build a very specialized language, that's fine. But if we're talking about more general purpose languages, you're then building something

• 25:02Speaker 00

  that when you want to work with somebody else, it's not ideal for them. So I'm sometimes asked why C++ is so big and complicated. And there's two reasons. One is history. I could not build the C++ I wanted back in the 80s for a variety of reasons. Partly technology, partly computers, and partly because I didn't know enough. And I had to learn. So you do the standard engineering thing, you do the best you can. Then you see what works and what doesn't work.

• 25:45Speaker 00

  And try and fix the problems. And then you repeat. And that's how C++ grew. And so there's some leftover things that just gets into people's way. Now you have spans. You very rarely use pointers. And you should certainly not use pointers as resource handles. That was already built in with C语言 classes in seventy nine, but people didn't get it. Um, and so there's teaching to do it. But anyway, uh, once you figure out that you have a problem that require a new language. Then you start looking what there is.

• 26:30Speaker 00

  And you have lots of help, lots of uh, books about analysis and about um, code generation. You have frameworks like LLVM that most of the modern languages uses to generate decent code. So most of the languages that compete with C++ does it by using a C++ infrastructure. It's it's highly amusing. Um, but but anyway, focus on the problem and don't think you're the only user. If you think you're the only user, you build a special purpose programming language and that's fine.

• 27:15Speaker 00

  Uh, domain-specific languages are great when you find the right uh, solution to the right problem. But identify the problem first. Uh, in my case, the problem was I needed high and low level facilities in the same language, otherwise I had to use two languages. And I had to have them communicate uh, properly. High-level languages at the time tended to use interfaces that took away performance. Uh, quite often they required garbage collection, which is not very good for uh, device drivers, for instance. Uh, or for building garbage collectors. Um, so.

• 28:01Speaker 00

  Yes, identify the problem and try and solve it.

• 28:06Ryan Peterman?

  Back when you were creating C++ and you had identified the problem, and so then you went off to build C++ and, you know, there's all these pieces, right? There's the compiler, there's a linker, there's, you know, in the implementations of those, there's like a parser, a lexic and, you know, all those things. When you were building the original thing, what was the most technically challenging part to implement?

• 28:33Speaker 00

  I don't think any part was particularly challenging. It was more of those many parts, as you point out. One of the things I decided that caused trouble later was that I wasn't going to touch the linker. And it came simply because I asked around and I realized people were using about 25 different linkers in Bell Labs, just in Bell Labs. And so if I wanted to serve my obvious initial uses, I would have to write interfaces or modifications to 25 linkers.

• 29:14Speaker 00

  And nobody wants you to touch their linker because if you make a mistake, everything breaks. So I decided a rule, don't mess with the linker. Later, people have messed with the linkers and made them better for C++, but that was after C++ became a major issue. The other thing was that there was many different optimizers. Every computer from different sources had a different optimizer. And again, I couldn't write a dozen optimizers. I mean...

• 29:58Speaker 00

  I'm going to write a language here, right? And I can't, if I wanted to be an optimizer specialist for tech computers, say, I can become that. I have the background, I have the training. But that wasn't what I wanted to do. I wanted to build first a distributed system. And then, when my friends and colleagues started using Cibul classes, I wanted to help them. And they were doing things like network simulations, hardware layout, positioning of satellites, all kinds of interesting stuff. So that was worth doing.

• 30:41Speaker 00

  And so I decided that actually there was a common interface to all these optimizers and code generators. It's called C. So let's use C as the assembler. And that worked nicely. C was very good at the low level, was part of the reason I chose it. So let's use it for the low level. And I could have hidden C and recreated a, probably a better interface. But I decided that I'll just use C, have C compatibility.

• 31:21Speaker 00

  At the time, what I said was that, well, we can have Dennis's mistakes, which we know, and we can have my mistakes, which we don't know yet. So we'll take Dennis's. That's much more manageable and understandable. And I don't have to teach people how to write a for loop and things like that. So that's, C compatibility came in that way, partly as an implementation technique, partly to get into the culture and tool support and such.

• 32:00Ryan Peterman?

  I saw somewhere in my research that C++ was used to write some part of the language tool chain. And to me, immediately, I have this thought of there's this chicken and egg problem, because how do you use this language to build something that it is using itself? How does that work?

• 32:23Speaker 00

  This is bootstrapping, and it was not an unusual thing. So I started with C, and in C, I wrote a preprocessor that did some of the fundamental things in what became C++ classes, and fairly simple inheritance, and overloading and such. And then, in that, I wrote a simple compiler for, again, what was a subset of C++.

• 33:06Speaker 00

  And now, I can use operator overloading and overloading in general classes, so I can build a scope class that handles lookup and naming and things like that. And then you work from there, just writing the next version in the previous version. You keep going. And after a couple of years, you have something that became known to the world as C++, and I wrote a book about it, and the compiler came out in the world.

• 33:47Speaker 00

  But I didn't invent this technique. This was known as bootstrapping. I think I was taught it as an undergrad, that you could do things like that.

• 33:58Ryan Peterman?

  Most people, they look at C++ and they think that's an object-oriented language. And I've heard you say multiple times that that's not the case, or that's not your immediate thought. And why is that?

• 34:10Speaker 00

  Yeah. I never called it an object-oriented programming language. If you look at the C++ programming language, the first edition...

• 34:22Speaker 00

  The closest I come is to say, some people call these techniques object-based. Actually, it's more focused on classes, it's type-oriented, class-oriented. It actually supports the techniques of object orientation very well. And it, in particular, follows similar model of defining types, defining classes, and defining class hierarchies to handle groups of related classes. But that was never all it was.

• 35:03Speaker 00

  For instance, I do not want object-oriented complex numbers. I don't want to say two dot, something to get to some parts of the numbers. I really want to say two plus z, and I want that to be, end up being roughly the same as z plus two. And no dots, no arrows. Math has developed a notation over the last 300 years or so.

• 35:46Speaker 00

  Descartes was, I think, the first one to use this notation, and it is very good. So I didn't want everything to be object-oriented. Furthermore, I wanted things that did not require inheritance, that did not require runtime resolution, not to use it. So for arithmetic and for complex numbers and such, I wanted Forte and compatibility. I mean, I was rather keen on what's called reuse in those days, but I saw it slightly different from a lot of researchers.

• 36:29Speaker 00

  A lot of researchers wanted to build a language, a system. That allowed reuse. I wanted to reuse things that existed. I mean, Fortran was there with some great software. C was there with some great system software. Actually helped with compilers and such. And there was a simpler that was used a fair bit too. So I wanted to reuse that and I wanted to make sure that worked. And that meant I couldn't go too far away from the hardware. I couldn't build all of the things that was considered ideal

• 37:14Speaker 00

  or even the things I would consider ideal. This is the real world. This is the real set of problems you are attacking. And so you have to respect the constraints that comes with that view of what you're doing.

• 37:32Ryan Peterman?

  At the time that you wrote C++, C was already there and it had a weaker type system than what C++ eventually had. And just give your thoughts on the trade offs behind that? And why did you choose to make the typing system stronger in C++?

• 37:47Speaker 00

  Because we needed it. The weakness in the type system is one of the most obvious sources of errors. And it's certainly one of the sources of endless testing and debugging. I hate debugging. I would much rather do design. And so you can't really have either design or debugging. Some people claim they can, but they can't. So I want to move the error more towards more design

• 38:27Speaker 00

  that helps the debugging and makes fewer mistakes at runtime. And the type system is one of them. And actually, what you get in C today, to a large extent, is stronger. Well, no, it is much stronger type than it was in those days, partly because of C++.

• 38:50Speaker 00

  Um, also, there's things you can't express unless you have a strong type system. Um, I mentioned overloading before. Uh, overloading is essential for generic programming. And if you want to write, say, a vector of T where T is a parameter type, you have to have overloading because you can only operate on Ts providing all the Ts have the same interface uh for what you need. So you you need the type system to resolve those things. And that can be resolved at compile time. So the compiler gets a bit more complicated, probably a bit slower. But you don't need to do so much debugging.

• 39:34Speaker 00

  Um, there was a large scale experiment done in Bell Labs in Chicago where they had

• 39:44Speaker 00

  some groups using C++ switching to C++. And they wanted to know whether they were more or less uh productive. And some people claimed that the slower compilation slowed them down.

• 40:03Speaker 00

  And uh somebody simply measured how much compile time was used uh before after switching to C++. And they found that the amount of

• 40:17Speaker 00

  compilation time on compute power was roughly identical. That is, C++ was slower, but you were by about a factor of two at that time. But the C people uh compiled twice as often.

• 40:34Speaker 00

  Um, this is just one experiment. I said the factor of two is is is just one experiment. But um.

• 40:44Speaker 00

  I wanted to move towards using more compile,

• 40:50Speaker 00

  compile time resolution, still doing that.

• 40:53Ryan Peterman?

  I mean, for every language, there's this, you know, dichotomy of having it being statically typed versus dynamically typed. And C++ is one of the most famous statically typed languages. Why did you choose statically typed language?

• 41:09Speaker 00

  Because of the problems I wanted to, to attack. What do you do when you get a runtime error? And in something like Smalltalk, you go into the debugger. And that makes a lot of sense if there's a programmer sitting at a screen getting the error. It doesn't make any sense if a telephone switch finds a runtime error, and then you have to resolve it. Furthermore, you want performance and you want small programs to fit into memories. This is true even today because, as I think,

• 41:52Speaker 00

  99% of all computers are embedded systems and they tend to be memory risk constrained. And again, if you do runtime resolution, you need to have enough information, enough data to do the runtime resolution. And I wanted to fit into small memories. Small meaning hundreds, 120K, 250K, 1MB, things like that. And I think it's still relevant for many systems. You can build a camera like that.

• 42:36Speaker 00

  It can still have several megabytes of memory. But if you put in a lot of memory, it gets bigger and it costs more and the battery runs out quicker. So we don't do that. Phones and cameras and things like that are still memory constrained. And statically typed languages, languages optimized for memory consumption, are just better at that, which is why we use it. We're using it right now. I suspect that the microphones have chips in them too. And there's a lot of C++ in that world.

• 43:20Speaker 00

  The competition there is C and assembly.

• 43:24Ryan Peterman?

  And you mentioned the, the research that was done on the, the compile time on, you know, if you catch things earlier, you compile less often, but maybe it takes longer. In this case, I, I could see a similar analogy where you, you catch errors way earlier if you have a statically typed language because the compiler is yelling at you before you put together that final thing. Whereas in dynamically typed language, the errors may come later. Comparing for a developer, like which one is more time efficient?

• 43:58Speaker 00

  I, I don't know any solid research on that. But you can look at it. JavaScript and Python are very, are very popular and they are runtime checked and they run much slower. I mean, raw Python runs something like 70 times slower than raw C++. And the reason it's viable is that a lot of key Python libraries are written in C or C++ to get the performance. And so you get the performance by actually getting to the point that I was starting out with.

• 44:43Speaker 00

  You need a high level stuff and you need the thing that can manipulate hardware. Here they are using two languages, but still the same needs, fundamental needs. And it's easier to try out things in a dynamically checked language because you don't have to know enough about the language. You don't have to know about type systems. And your average web developer or astrophysicist is not a computer scientist and don't want to become one. So there's advantages there. But the problem is that errors that are found by the type system in a statically typed

• 45:27Speaker 00

  language is found at runtime later.

• 45:32Speaker 00

  And so as systems grow, the performance problems start. Furthermore, you find it's get harder to write reliable software. You need much more unit testing, for instance, in a dynamic language. Because it's, well, the compiler doesn't do it for you. And if you want things to guaranteed to work, like the telephone switch mustn't crash, your car mustn't crash, your plane mustn't crash, you want guarantees.

• 46:15Speaker 00

  And they're harder to provide in a very flexible, dynamic type system.

• 46:20Ryan Peterman?

  One thing that I think C++ is infamous for is kind of like memory safety issues or kind of footguns that exist there.

• 46:31Speaker 00

  I'm so tired of that. I haven't had those problems for years. And somebody did a study of the obvious problems with buffer overflows and people hacking in using that kind of stuff. And almost all of these cases were when people writing C-style code or in C. And Herb Soder has a talk with actual numbers. And they're quite significant.

• 47:12Speaker 00

  It's sort of of that kind of problems. More than 90% are for people that don't write modern C++. They they use raw pointers to pass things around without.

• 47:30Speaker 00

  The number of elements, no fat pointers, no spans. You have them in C++. You can use them. You can use vectors. We have hardened libraries. Everybody has hardened libraries that does the runtime checking.

• 47:49Speaker 00

  Apple has it, Google has it, Microsoft has it. It's just not standard till now. C++ 26 has a hardened option that are standard. And the work I'm doing on profiles will give you a way of guaranteeing that you don't do the stupid things.

• 48:12Speaker 00

  So anyway, fundamentally, theoretically, the problem was solved many years ago. And people just do what they've always done and get the problems they've always had. And that makes me sad. And it's one of the things that makes me work on coding guidelines and on enforced profiles and on education.

• 48:40Ryan Peterman?

  I mean, education is one way to solve the problem. Is there a way to get the compiler to just prevent people from doing all those risky things? And is that enabled by default in modern C++ today?

• 48:53Speaker 00

  No, but it should be. I'm proposing that for C++ 29. The simpler versions of that should have been in C++ 26. But there are still a lot of people, even in the C++ Standards Committee, that are very devoted to their old code and their old ways of doing things.

• 49:16Speaker 00

  There's people who says you should only standardize what is common in industry. But when the bugs are common in industry, you should do something else.

• 49:26Ryan Peterman?

  The standards committee is a topic I want to talk about, actually. It's interesting, I mean, the language is now run by a democracy. And one question I want to ask you is if it was a dictatorship, so you just had full say, what language features would be in that, you know, maybe harder to get by?

• 49:47Speaker 00

  First of all, it never was a dictatorship. I never had full control. Once you have some users, in my opinion, you gain some responsibility for making sure that they're helped and their stuff works. You can't keep breaking the language. That's what academic language development does. They break to improve all the time. And then they can't maintain a user population. I didn't actually choose to have a standards committee. I chose responsibility to the community.

• 50:30Speaker 00

  But one day, two guys came in representing IBM and HP. And I can't remember if it was Sun or Dick. That was the third thing they represented. But anyway, the biggest computer and software suppliers in the world at the time. They come into my office in, it was S H E nine. And they say, "Well, Björn, you want to help us standardize C++ under ISO rules." And I said, "No, I can't do that. I'm still doing experiments. It's still not complete."

• 51:15Speaker 00

  So they said, "No, Björn, you don't get it."

• 51:22Speaker 00

  Organizations cannot use a language that's not standardized. They cannot use a language that's owned by a corporation that we might compete with. And we do sometimes. Okay, we, we, we trust you, of course, but not your employer. We compete with them sometimes. And you can get run over by a boss. This, uh, the, no, no, no, we need a standards and we need a standards committee. So this goes on for about an hour and they twist my arm, ow, ow, ow. And in the end I said, okay, I, I, I, I will, uh, standardize C++ under ANSI rules, uh, just like you suggest and you need.

• 52:05Speaker 00

  The, the computer, uh, community needs that. And, uh, by the way, what's ANSI rules for standardization?

• 52:17Speaker 00

  And, um, so they told me and, uh, we started a year later. But, uh, this, this was the way it came about. Some very important organizations wanted that standardization. C was on the track to get standard, standardized. And AT&T being primarily a user of software was also in favor of standardization, I found out. And so they supported it and the documentation I had, uh, written was based on it. Actually, I rewrote the documentation. It became the, the arm, the annotated C++ standards, uh, the ma- the manual that, uh,

• 53:03Speaker 00

  gave the definition, the manual of the language. And for every feature, some rationale and s- some way it could be implemented or was implemented. And that became the, the foundation document for the standardization.

• 53:21Ryan Peterman?

  When they were strong-arming you, what if you had just said no, like what would have happened?

• 53:26Speaker 00

  I think, well, I think C++ would have faded into becoming an academic, um...

• 53:38Speaker 00

  Language that was loved by some small community. And it would have disappeared out of the mainstream of of computing. And there are people who say this stronger than I do. They say that C++ is spread and uses is that it has a standard. It's not owned by a corporation. It is one of the things that sometimes blocks the the wannabe C++ killers.

• 54:17Speaker 00

  I remember the ads for Java and people standing up saying, we'll kill, absolutely kill C++ in two years. I thought that was rude. And anyway, we have ten, twelve times more C++ developers today than we had when they said it. So didn't work.

• 54:43Ryan Peterman?

  How is it that C++ not exactly that it's a war, but just if we looked at adoption, you know, clearly C++ gained a lot more adoption than Java. Yet I know C or Java had the backing of, you know, a big company that was putting a lot of marketing dollars in and C++ was kind of, I think you've said that it had almost zero, you know, next to zero marketing done for it.

• 55:13Speaker 00

  Next to zero was five thousand dollars to be used over three years. And Sun used much more money on advertising and marketing Java than was ever used in C++ development.

• 55:34Speaker 00

  And to this day, the Standards Committee has a problem. It has no funding. And that means that it's hard to do experiments, it's hard to deploy things. Other language communities keep sort of stealing C++ compiler and tool developers because they're good, but it makes it hard to predict how fast we can implement things. Today, last I checked, the C++ Standards Committee had 527 members.

• 56:14Speaker 00

  And we work on consensus, because if you don't have consensus, then you get dialects. We don't want to have a feature in that's voted in, say, 60 to 40, or even worse, 52 to 48. No percent. We don't do that. And that's painful and tedious and good.

• 56:45Ryan Peterman?

  When you say consensus, that 100% need to approve?

• 56:48Speaker 00

  100% is not necessary. We don't need unanimity. We need a massive majority. And basically, I would like to see 90%, and we often do. 80%, I start to worry.

• 57:08Ryan Peterman?

  What's the lower bound that's coded into the rules?

• 57:10Speaker 00

  There's no lower bound coded into the rules. The rule says that the convener of the ISO Committee determines what is consensus. So pure numbers doesn't say it. Could you imagine you had a vote, 95% versus 5%?

• 57:37Speaker 00

  But the implementers of C++ compiler and standard libraries from Google, Apple, Microsoft, and others were all in the 5%. Is that consensus? I can reassure you that no convener would call that consensus.

• 58:02Ryan Peterman?

  And that makes sense intuitively. I kind of wonder with democratic decisions, there needs to be objective rules. So like, what if the convener made the wrong decision?

• 58:13Speaker 00

  It happens. But you can't just have numeric rules. Not everybody cares for the whole language. Not everybody understands what's going on. You can vote at your third meeting. So you might have somebody with a vote that has, well, eight months of experience with standardization and don't understand standardization and knows only what they're known from their development organization that they've been part of, which might be a small one. You need some judgment.

• 58:57Speaker 00

  And you hope that the convener has that judgment. The convener always asks the national representatives. I mean, the other way of getting a consensus is that you have a massive consensus, but you have 10 countries where the representatives didn't agree. That's not consensus. And even when there looks if there is a...

• 59:29Speaker 00

  Look, if everybody's for, if it's massive and all of that, there's not a problem. But if there's a problem, the convener asks the national bodyheads, he asks the implementers, sort of key people that are necessary for getting the voted change into real use. Sometimes educators also, before they make that decision. Not everybody weighs equally once there's a disagreement.

• 1:00:07Ryan Peterman?

  For this podcast, I produced transcripts for every episode for convenient skimming, and I built a custom tool to automate that. Recently, I noticed in the Barbara Liskov transcript, my simple speech-to-text tool was getting a lot of things wrong. For instance, the CLU programming language is spelled, all caps, C-L-U, not clue. So to fix this, I used Cursor 3, picked the strongest version of Opus 4.7 Extra High, and had an agent make a plan to fix that. And while I was waiting, I figured I'd trigger a few more agents for code cleanups and front-end improvements. It generated a reasonable plan with rich system diagrams. It applied all the changes within minutes and worked on the first try.

• 1:00:49Ryan Peterman?

  So if you want to build something with the flexibility of sending off a bunch of agents with frontier models of your choice, you can go to cursor.com to try out Cursor 3. OpenAI, Anthropic, Cursor, and Vercel all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product, and you want to sell to other companies, there's all these requirements you need to meet. There's SSO, there's SCIM, there's RBAC, there's audit logs. These are all things that take time to integrate but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies.

• 1:01:32Ryan Peterman?

  WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started. And I appreciate them for supporting my work and sponsoring this podcast. About the Standards Committee, I saw in some of your writing, you said one of the most negatively received ideas you'd ever presented was auto. And I know auto eventually made its way in there. But what's the story behind why it was so negatively received at that time?

• 1:02:03Speaker 00

  It was just unusual. People thought it was weakening the type system. And also, it opens the door to fairly general generic programming that is not heavily syntax based. And auto is the beginning of concepts, which is the ability to put constraints on generic code. And auto is just the simplest constraint. It must be a type as opposed to a, let's say, a value seven.

• 1:02:42Speaker 00

  And maybe I didn't explain this well enough. And there's a variety of backgrounds in the comedians. Maybe they didn't know languages of the generic types, ML, Haskell, things like that. So it was horrible. Eek! So anyway, we still got it.

• 1:03:16Speaker 00

  Because we needed something like that. But it wasn't enough. I have looked at industrial software and problems with overuse of auto. You should only use auto when you have an idea about what is needed there. It's good in generic code where there's, you go and eventually you check that the type is correct, that auto has resolved to something that supports the operations that you're going to do on it. And that's what concepts formalizes. But it was always checked at the end. And I noticed a group of people that was overusing auto in a

• 1:04:01Speaker 00

  Actually in a framework for networking. And they were saying that they were being slowed down. Not so much with bugs, but they had to look up the functions being called to see what that auto could possibly bind to. And then they had to put in comments that says what the what the auto was meant. So you have auto on the comment says must be an input channel. Now you simply define input channel.

• 1:04:42Speaker 00

  And then instead of saying auto, you say input channel auto. Fine, that's what the system is. My design of that simply said that auto is the simplest concept. And you should simply only set input channel C equals blah, blah, blah. But anyway, the committee wanted an indicator that this was going on. Oh, well.

• 1:05:11Ryan Peterman?

  I saw another anecdote in kind of the standards committee being heated at sometimes. You mentioned there's this thing about shuttle diplomacy between two corners of the room because I think it was IBM and Intel, they both needed different support. What's the story behind that?

• 1:05:30Speaker 00

  Oh, so actually talking to Brian McKnight, who was the IBM rep at the time. And it was last week. And we were discussing some of the things that was happening then. So it's still remembered. So basically IBM was doing the, what's that architecture called?

• 1:05:55Speaker 00

  Power PC? Power PC and The x86? And the Intel was doing well, Intel. And they have different models of the underlying hardware, especially coordination with the caches and things like that. And basically, yeah, and the guy representing Intel wasn't actually an Intel guy. That was, uh, he, he, anyway, also a good guy. I used some of his slides in my presentations. It's, uh, so I knew these guys, but they were totally deadlocked.

• 1:06:36Speaker 00

  I mean, this, these are massive, again, massive organizations with massive amounts of code out there. And, uh, basically,

• 1:06:56Speaker 00

  some things could be done, but the IBM guy, Brian, said that they had a lot of software, mostly in the lowest level, even down in the microcode, that was relying on the way they have done it. And the people who had done it had left the company. They, they, it was done a long time ago. And they just couldn't rewrite all of that code and get it right, even if the Intel guys was right.

• 1:07:38Speaker 00

  Okay. And the Intel guys had similar arguments and similar points. This is better, we are using it. And so I was shuffling. They were definitely, they were in different corners of a large room. And so I go up to the Intel guy, um, the guy representing Intel here. And what's the problem here? Tell him, tell me about it, explain it. I go down, explain, he's saying this. They say, well, there's this, this, this. And I go back again. And I spent a couple of hours literally doing shuttle diplomacy, walking from one corner of the room to the other.

• 1:08:18Speaker 00

  And we reached an agreement, and that's in C++ 11. And a couple of years later, they both agreed that they were now using a combination of what they had before and what the other guys brought in. So they actually, the result was improvement, cross pollination.

• 1:08:45Ryan Peterman?

  That's funny. Why did you have to do shuttle diplomacy? Why not just a group conversation with?

• 1:08:50Speaker 00

  Because they've been trying that for days and probably for meetings before that, and it didn't work. So I guess I was just translating and asking questions. I mean, those were experts. I don't consider myself expert at that level. I mean, I've done hardware, I've done microcode, so I'm not an amateur, but these guys are really good. So the IBM guy is now the guy doing most of the synchronization under Linux. We're still using his stuff today.

• 1:09:33Speaker 00

  He has a C version of it, so he can get it into the, but it's the bottom of the Linux kernel.

• 1:09:40Ryan Peterman?

  When I was reading your writing in these papers, there's this part where it seems like in 1995, you had this idea to introduce some form of automatic garbage collection into C++ and that kind of surprised me because when I, when I think about C++, my, one of my immediate thoughts is no garbage collector, we're gonna man, manually or, you know, manage the memory ourselves. How would that even work?

• 1:10:08Speaker 00

  There's two things there. One, I wanted to automate resource management in general, not just garbage, not just memory. And for that, you have constructors, destructors, and the techniques that was later known as RAII, resource acquisition is initialization, which is probably my worst naming ever. But I was busy at the time. So.

• 1:10:42Speaker 00

  In the standards committee, those people that insisted that we needed to be able to do garbage collection. And there was garbage collectors out there. Oh, that was Hans Birm. He was the one that representing internal model of stuff. He has a conservative garbage collector, still used today. And we thought we needed an interface so that it could be standard how you used such a garbage collector.

• 1:11:16Speaker 00

  And so, basically, I was listening to the users, expert users, and they thought it was necessary. I thought that support for memory management, resource management, was important. I've thought that from the beginning. I didn't think garbage collection was appropriate for a lot of what I was doing. But certainly, automating the management was ideal. And so, after a long set of discussions, we found an interface that people agreed on. And we put it into C++ 11.

• 1:12:02Speaker 00

  And what we found was, over the next 10 years, the amount of usage of garbage collection decreased as RAII, the resource management that had been there all the time, got more and better understood and was used more. Furthermore, the people who still use the garbage collectors didn't use the standard interface because they had figured out ways of doing it better. And so, today, there are still a few people doing garbage collection, but it's not part of the standard.

• 1:12:43Ryan Peterman?

  How does that work? Is it kind of like a wrapper around the memory allocation methods?

• 1:12:48Speaker 00

  Yeah.

• 1:12:49Ryan Peterman?

  Okay.

• 1:12:50Speaker 00

  You have a different implementation of new or malloc or operator new, whatever it is you're using at your lowest level. And then delete becomes something slightly different, too.

• 1:13:11Ryan Peterman?

  There's this cautionary tale in the C++ community about this ship, Vasa, and I was kind of curious, like, why that's popular and...

• 1:13:21Speaker 00

  Oh, we had a meeting in Stockholm at some point, and they have a wonderful ship that, if you ever get to Stockholm, should see the Vasa. It's a battleship from the 1600s. There's a story to that, and that's the one I tell people. The king was building, was ordering built, a battleship that should be the best and most beautiful battleship around. It was going to be a good fighting battleship,

• 1:14:01Speaker 00

  and it was going to be used for diplomatic visits, so it should be beautiful. And they laid down the keel and they started building it. And then they heard that a likely opponent was building battleships with two gondags. And this was an old-fashioned battleship with only one gondak. And if you put a one-gondak battleship next to a two-gondak battleship, the highly predictable result is a lot of holes in the one-gondak battleship, and it's gone.

• 1:14:41Speaker 00

  So the king orders that this ship should now have two gondags. And they've already started building it.

• 1:14:53Speaker 00

  So they add another gun deck, they add cannons up there. And the king also wants now the ship is bigger, they want more statues and beautiful things. So it becomes a bit top-heavy. And rumor has it, I have never checked this rumor, so it might be wrong, is that the ship designer committed suicide out of horror. Also, a thing that I don't believe is just a rumor, was when they was built, they tested it for stability.

• 1:15:31Speaker 00

  And the way you test a ship like that for stability is you take the whole crew and you run them from one side to the other. Back, forth, get harmonic there. And if you can do that fourteen times, then it'll stand up to the Baltic and the North Sea. Rumor has it, actually, as I said, I think it's fact, that they did it seven times and then they stopped because it looked dangerous.

• 1:16:07Speaker 00

  So, this was sixteen twenty-four, I think. The ship gets finished. It's sailing out, the most wonderful ship you've ever seen. It's sailing out in Stockholm harbor. Trumpets blaring, flags flying, families of crews on board, the whole thing. It gets halfway across the harbor. A gust of wind comes, it keels to oar, and it's gone. And it ends down in some place where there's not much oxygen.

• 1:16:51Speaker 00

  So it was well preserved and they fished it up again, and you can see it. And so, I tell this story to the standards committee, and I point out there's something they did wrong. They built more features on top without improving the foundation.

• 1:17:09Speaker 00

  Always improve the foundation to make sure that it's just not a random set of features that you have adding, because that's complexity. Furthermore, do not compromise your testing. That's really dangerous. And furthermore, you've all noticed when your high bosses say something should be done, and the high bosses don't always know what's right. Sometimes the professional thing is to say, "No, we are not doing this. We have to take it easy." If they had said, "Okay, we'll build a one-gunned battleship. We'll just not call it the Vasa.

• 1:17:54Speaker 00

  Call it something neutral." And the next year, you can have a battleship that's been designed from the bottom up to be a two-gunned battleship. You wouldn't have any problems with that. But the high management, meaning the king, who was in Poland at the time, so he couldn't even see it, says, "No, must be delivered on time." And so they delivered something on time that just couldn't do the job. But go see the ship, it's great.

• 1:18:24Ryan Peterman?

  At some point, someone demonstrated that the C++ template instantiation mechanism was Turing complete. So, you know, what the compiler is going to do to kind of pre-process that C++ program can actually be used for computation. And I was just trying to understand, how is that possible? Like, how, it was mentioned something about he calculated prime numbers at compile time. How's that work?

• 1:18:56Speaker 00

  Well, that's, I mean, the prime number thing was just a curiosity. It used the error messages to report the result. But when you build something, you can get Turing completeness. You need some form of iterate or recurs, and you need a comparison, and that's about it. Then you can get Turing completeness. And the... At least some of the theoreticians say, "Hey, we can't do that. It'll run forever."

• 1:19:39Speaker 00

  And the guy who, Erwin Anru, who came up with the first example of this, actually thought I should prohibit it somehow. I should ban it. And my reaction was, "This looks useful. Great." And I think I was right. Furthermore, nothing runs forever. If you have a Turing machine, you have the tape. And the tape has to be infinite. So if you imagine building a real Turing machine the way Turing designed it, you have to have a bunch of Navis building track all the time when it gets out there. Of course, we don't do that.

• 1:20:24Speaker 00

  The point is that the compiler will run out of resources long before we get into real problems. Machines are finite. And so the problem doesn't become real unless there's bugs. And the bugs get caught, guaranteed. So, not a problem. What happened, though, was that people were misusing templates to do simple calculations, like prime numbers, or arithmetic, yeah, arithmetic, or calculating factorials and such. And it's so awful, and it's so expensive,

• 1:21:07Speaker 00

  and it uses up so much memory that it becomes a problem. So that was why I and Gabby Drus raised built ConstExper, which basically says you can calculate perfectly ordinary code at compile time, and it is much simpler, much more what we're used to, and much faster to compile, and giving usually much faster code. And you have that today, and you have Constabel if you want to guarantee that this is done.

• 1:21:45Speaker 00

  And so that takes care of the obvious misuses of the idea of templates being sure and complete. It turns them into ordinary functions.

• 1:21:57Ryan Peterman?

  Generally, with programming languages, there's this you know, high level intuition that the closer to the machine you are, the higher the performance is. And you know, I I tend to see C as closer to the machine than C++ for instance.

• 1:22:16Ryan Peterman?

  That's not the case.

• 1:22:17Speaker 00

  It's not the case. It's not as good as compile time calculation as C++ is. And anyway, we have exactly the same machine model because

• 1:22:29Speaker 00

  C borrowed the C++ 11 machine model. So if you write the same code in both languages, it's you get the same result, except the C++ compilers can do more at compile time. And so C++ runs as fast or faster than C in most cases. There's more information. If if you give the optimizer more information, it can do a better job.

• 1:23:00Ryan Peterman?

  Ah, OK. Yeah, because that was what I was going to ask you was you had said somewhere that C++ can be more performant than C, but I tend to think that more abstraction costs you something.

• 1:23:12Speaker 00

  It's compiled away. This is why I talk about zero overhead abstraction. And people are beginning to take me to task for that because that's underestimating the and understating the ability of the C++ compiler. We can do negative overhead abstraction.

• 1:23:34Ryan Peterman?

  What if I was really good at writing assembly and I had all the time in the world to write it? Could that? How about? How does that compare?

• 1:23:42Speaker 00

  If you are very smart and you have infinite time, you can do better.

• 1:23:50Speaker 00

  By and large, we are not as smart as the optimizers anymore, and we don't have infinite time. So if we are smart enough, we can only do a small piece of code. And now, the question is, did we get enough time to use our smarts?

• 1:24:14Speaker 00

  This is even starting to affect clever code. I gave a talk to Slack last year, which is a group of very performant, interested people from the finance industry. And my title was "Don't be clever." Actually, the written title was "Don't be too clever", but I can't pronounce parentheses.

• 1:24:44Speaker 00

  And I got out alive.

• 1:24:47Speaker 00

  And my main point was that C++ is good enough for more than 98% of your code. So if you want time to be clever,

• 1:25:00Speaker 00

  you use these techniques. And I showed modern C++. And that way, you get time so you can do all the clever optimizations. The problem is clever optimizations these days tend to be machine-dependent. That is, if you get a new

• 1:25:18Speaker 00

  computer or if you get a new version of the compiler, you might actually have pessimized your code. I've seen this repeatedly ever since the 80s.

• 1:25:33Speaker 00

  There's people who does nothing but using different optimizations on the next-generation hardware. And my standard techniques for improving things actually is to first throw away the clever stuff and then see if you run faster or slower. Usually, you run faster because clever stuff tend, at least 1990s style clever stuff, which is, there's a lot of it still today because the techniques carry on in people's heads.

• 1:26:15Speaker 00

  Some of the code remains, tend to use a right nest of pointers. And that gives the compilers and optimizers problems. They also sometimes use more allocations, which is not good. You want to minimize memory access, you want to maximize your cache performance and things like that. And compilers are getting very good at that. And I have seen this kind of thinking. I wrote a paper about it together with a friend of mine in Spain, doing fluid dynamics.

• 1:26:55Speaker 00

  And we threw away the clever stuff for a actually a performance test suite example, so it was not toy. And we got only 20% improvement by reducing the code to about 80% of what it was before. And so some people didn't think that was significant. I thought it was a significant proof that the technique was appropriate. You apply optimizations only when you need them. Knuth says, don't do premature optimization.

• 1:27:39Speaker 00

  But he also pointed out that 2% to 3% is where you where you should optimize, which is exactly the number I'm using. And so first build the stuff using high-level facilities. See if it's good enough, and if it isn't, and you have to time it, you don't guess, you time. Then you then you figure out where the time is spent, and then you optimize that.

• 1:28:10Speaker 00

  But a lot of the time, you don't need to go to that stage. It's it's fast enough.

• 1:28:16Ryan Peterman?

  I see. So when you say cleverness here, it's like human level, a manual management to eke out performance.

• 1:28:23Speaker 00

  Yes.

• 1:28:24Ryan Peterman?

  And you're saying that actually, if you don't do that, the compiler, you're giving the compiler more to optimize and it can do a good job.

• 1:28:31Speaker 00

  And it's much, much better than it used to be. Code that was cleverly and correctly optimized in nineteen nineties are often pessimized today. Because machine architectures have changed and the compilers have improved.

• 1:28:51Ryan Peterman?

  When I look at the industry today, more and more of code is being written by machines than humans. And I I feel like a lot of programming language design is thinking about how do you make it amenable to humans solving problems or writing the code. And I'm curious if you have any thoughts on if you think programming language design will change if more and more of the code is written by, you know, models and machines.

• 1:29:19Speaker 00

  I

• 1:29:23Speaker 00

  think that in the field I'm mostly interested in, code will still be written by humans and they will use abstraction. The examples I've seen of attempts for AI to generate code in this domain

• 1:29:43Speaker 00

  has not been successful. It they generate more bugs, more security holes. They have bloated code which pessimize again because you use more memory. And it's hard to validate.

• 1:30:02Speaker 00

  And the senior developers that would be needed to validate it, I've seen some of them starting to retire because they don't want to deal with the validation of something that changes every time you make a change in your code, in your prompts. And furthermore, a lot of the things I think about,

• 1:30:26Speaker 00

  there's regulatory bodies, there's validation. You have to be able to validate what you changed when you make a change. And the AIs, the tools change. The, even if you make a slight difference in prompt, the, a lot of the code will change and you have to now check it again. All of the code that was generated, there's more code generated than if it was written by humans. And when a human make a change, it will make a change that's localized and you can look for the effects of that localized change. If an AI writes it, it, it, you don't actually know where it's changed. You have to try and figure that out.

• 1:31:11Speaker 00

  So, if you're doing something that has been done many times before, you write a standard web app, what you say is correct. Also, AI is not useless, that's not what I'm saying. It can be used to write documentation. Again, it has to be humanly validated, but it helps write things. It's good at text. It's not, at least now, good at

• 1:31:48Speaker 00

  safety critical, performance critical code. Now, let's say that seventy or eighty percent of the code, of the world's code doesn't fit that pattern, but it's the, that ten, twenty percent of the code that I'm interested in. And there, it's not there and I don't see it coming with the LLM model. Furthermore, LLM...

• 1:32:16Speaker 00

  When fed with training data, has to be trained with old code. And my job, as I see it, is to make sure people write new things and use new techniques that are improvement over the old code. So I find that LLM-based code is imitating old code and getting old performance and old bugs. Again, maybe you can improve that. I hear rumors of Biana apps being written. That's fed my writings.

• 1:33:00Speaker 00

  But even that is problematic because I'm not saying exactly the same as I did 20 years ago. But anyway, we'll see. Also, even Dykstra was looking into the possibility and he claimed that the idea of having natural languages being the programming language was idiotic. He is less polite than I am. And I think that a language like English is very flexible and what we say is often very ambiguous. We need a programming language that's precise. That's engineering, that's math.

• 1:33:45Speaker 00

  It's not English.

• 1:33:48Ryan Peterman?

  And for that code that is performance or safety critical, I imagine there will be some group of people that is using LLMs for that. And I guess, based off what you're saying, is the intuition that you would foresee more breakages and bugs and, you know, because it's not validated.

• 1:34:09Speaker 00

  And the people that are really good at that kind of stuff tend to not want to spend all that time validating. Another problem is that they want to eliminate junior programmers because there's lots of them. But if you do that, where do you get the senior programmers from? We'll see. I mean, you can ask me the same question again in ten years and there will be more knowledge and undoubtedly some of what I said will not be correct. And my guess is some of what I say will be correct in ten years.

• 1:34:47Speaker 00

  I'm always told by AI proponents that either the problem has already been solved or it'll be solved in the next release. But I hear and think 4.7 is having more problems than 4.6 for reasons I don't understand. But the idea that the next version will solve the problem is always a dangerous assumption. Furthermore, it's getting more and more expensive. If you have to build a hundred million dollar center and use and run the electricity for

• 1:35:32Speaker 00

  it, how many junior developers does it take to be cheaper? They're starting to need money. It's not unproblematic and I'm in a subfield where it is probably more problematic than most.

• 1:35:53Ryan Peterman?

  One thing I saw in a profile that you did is they asked you what keeps you going on C++ or what motivates you. And you said, one is the fun of kind of building the future. And the second thing was the obligation to make sure C++ moves forward. Like when you started C++, I can imagine you knew that you were embarking on a journey for decades and so.

• 1:36:22Speaker 00

  Not decades, but I knew it was a longer journey because I knew I couldn't build the language I wanted. I could build a subset of it. And there was two reasons for that. One was, well, I was the team that did it. Secondly, so lack of resources, lack of time. And secondly, I didn't have the input needed to make sure that what I designed was right.

• 1:36:52Speaker 00

  And so we have the engineering issue. Build what you can, see what works and prove it. And so I knew I was getting into something like that. I knew I was building a language meant to evolve. And meant to evolve means that you make certain decisions in knowing that that is different. For instance, I, that's one reason C++ wasn't just a object-oriented programming language. Because I could see in the world that there was things that didn't seem to fit that paradigm. And so I, I knew we would evolve.

• 1:37:35Speaker 00

  The other half of that answer to that question, what keeps me going, is applications. It's really nice to see interesting users and such. So I was at JPL and I talked to the people who was doing the maslowers. That's cool stuff. I've been to J, I've been to CERN. I'm going to CERN this summer to see how you do high-energy physics. I don't know anything about high-energy physics. Well, probably more than the average, but, but nowhere near being a physicist. And so you can go there and see they do interesting things. And there's things that surprise you. So I was talking to a guy in CERN some years ago.

• 1:38:20Speaker 00

  And his job was to open and close doors. These doors weigh a couple of tons and are made of lead. And they move across to close off an area to protect against radiation or something like that. I don't know the details, but the point is, he has to start up this door, which is not too hard. You have engines. But then you have to make sure you stop it. Because when you have a couple of tons, this wide going into a wall, it will not stop normally. You have to write. And the code for that was, was interesting. I learned something.

• 1:39:03Speaker 00

  And I still travel around and talk to people and see what C++ is being used for and what it can be used for and what it can't be used for. Just learning. And learning is fun.

• 1:39:18Ryan Peterman?

  There's a few quotes that you have, which I thought would be interesting, kind of, if you could just give some context behind them. One of the quotes is, "C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do it, it blows your whole leg off."

• 1:39:35Speaker 00

  Yeah, somebody asked a question at a talk I was giving in Boston back in the ages, and I shot that one back, not thinking. But it's a good quote, and it's correct. Arno Penchess, who's a co-founder of Bell Labs in physics, so he's not a nobody, was once trying to explain to a large group of Bell Labs managers about C++. And he says, "You can't have a power tool without knowing how to use it.

• 1:40:18Speaker 00

  So if you have a saw, you saw like this. If you have a power saw, and you try and do that, it'll bounce, and you will have to be very lucky not to get hurt." Notice, it's roughly the same story. And so what is behind that is, if you get a power tool and you misuse it, you will get more problems. Get a car that can accelerate faster, and it can wrap you around a tree, in a way an old-fashioned, slow-accelerating car can't. It's fundamental to having power tools.

• 1:41:02Ryan Peterman?

  You also have this other great quote. "Nobody should call themselves a professional if they only know one language." Obviously, you'd recommend people learn C++. But if they had to know a second or a third language for the sake of, you know, being a better engineer or programmer, what would you recommend?

• 1:41:22Speaker 00

  Yeah, and if you've heard, if you've seen that interview, you'll know I waffle on that deliberately.

• 1:41:31Speaker 00

  It is not so much which other languages you know, but that you get a set of ideas that are embedded in those languages. So what you should do is to learn languages that are different from yours. And I'm not too fuzzy about which languages they are. I think I said, learn a scripting language. Today, that would be Python or JavaScript. Then, I guess it was Unix shell or something like that.

• 1:42:12Speaker 00

  Have a look at a functional language. ML or Haskell would be obvious solutions. Or just pick something different. The point is that you mustn't get stuck with just what's in your language. It's like, it's not good for you to be monogamous. I mean, you know what you call somebody who knows three languages? Trilingual. Who knows two languages? Bilingual. One language? American. Is a very popular joke, at least outside America. And it's the same idea with programming languages, but it's more important with programming languages, I think.

• 1:42:58Speaker 00

  Because you're building things and you shouldn't, you should broaden your mind with ideas and techniques.

• 1:43:08Ryan Peterman?

  Another quote is, "People who think they know everything really annoy those of us who know we don't." And I was curious the context behind that or your thoughts on?

• 1:43:19Speaker 00

  Well, that's, I mean, that's very simple. It's, there's so many people who think there's simple solutions to just about everything in the world. In this context, they'll come and tell me how much simpler C++ could be. And this is true.

• 1:43:41Speaker 00

  If you only want to do one thing, usually the one they have in mind, you can make a much simpler language. But... This is like, if we threw away this part of C++, it would be much simpler and nicer. Usually, they want to throw away things like C. So, but then you annoy a few million people. And you don't actually succeed because they'll stick to the old stuff. So, um, it's a, it's a way of expressing my frustration with people who oversimplify. Uh, people think they can program without being, learning to program.

• 1:44:24Speaker 00

  Uh, they think they can be engineers without learning engineering. They think they can be politicians without knowing how to run a company or a country. Um, it's, it's, uh, oversimplification annoys me. And I probably shouldn't express annoyance. I very rarely do. But, uh, in this particular case, uh, my frustration showed.

• 1:44:50Ryan Peterman?

  Yeah, I think I saw somewhere, kind of in response to C++ being difficult for some people, people who have the perspective of, you know, programming should be approachable and, you know, anyone can learn programming. And I think you, you expressed the opinion that C++ is not necessarily for everyone. It's for serious programmers.

• 1:45:11Speaker 00

  Yeah. I mean, uh, the, the first line of the C++ programming language, uh, version one, first edition, was, uh, "C++ is designed to make life more pleasant for the serious programmer." And I took away the first version, which was professional, because I saw amateurs that was really, really good. So a serious programmer is probably programming for somebody else. If you program for yourself, it doesn't matter. It's your, it's, it's you, uh, and that's your problem.

• 1:45:56Speaker 00

  If you do it for your friends, you can lose friends. If you build something for a million people, you can do harm in the world. And so that's what it's for. Um.

• 1:46:10Speaker 00

  I mean, Gildof and Rosen built Python with the explicit aim of allowing many people or even everybody to program. And he succeeded. I designed C++ to be a really good tool for serious programmers, for engineers and mathematicians and such, and I succeeded too. It's just not the same problem. Remember where we started? I said, "The problem. Build the problem and then learn from what worked and what doesn't."

• 1:46:48Ryan Peterman?

  Looking back on C++ and the whole journey, is there any part where you think, "Oh, that was a mistake," or something that you learned from in the design?

• 1:46:58Speaker 00

  Many, many times I learned something. I think most of the things never made it into C++. That is, that's what you have experiments for. And that's what you have initial uses for. I think I got the major part of the language right. And I think I could improve every single detail. But stability, compatibility is essential.

• 1:47:42Speaker 00

  If you make an insignificant change, it will annoy a few people and it wouldn't matter. If you make a significant change, you will annoy a lot of people and it will not work because, say, a million people will stick to the old way. So I try to grow the language without breaking it. I have this thing that happens again and again, and I explain it. People come up and say to me, "C++ is too complicated." Yep. You must simplify it.

• 1:48:25Speaker 00

  And I need these two features. I need them yesterday. You must, when you're doing this, give me these two features. Yes. And whatever you do, don't break my code. I have a million lines of it.

• 1:48:41Speaker 00

  That doesn't work. That's impossible. And so that is why I'm working on coding guidelines and on profiles, which is enforced guidelines. That way, you can design a profile that ensures that you can use the libraries that you need and ensure that you don't misuse the features that are unnecessary and dangerous in your field.

• 1:49:12Ryan Peterman?

  For anyone who wants to, you know, learn C++, I think a common question is like, what is the, you know, top technical book recommendation that you would have?

• 1:49:24Speaker 00

  Learn modern C++. There's a book I wrote when I was teaching undergrads. This is accidental. I didn't mean it to be there. But anyway, this is the second edition of Programming Principles and Practices Using C++. This is a big fat book written for undergrads. The third edition is not as thick because the language has improved and I can actually get the ideas across better with less text.

• 1:49:59Speaker 00

  But use the latest C++. Learn the modern way first. Don't start learning all the bad ways of writing C as the starter. And a lot of courses still says you learn C first. So you learn some misuse malloc and pointers. And then later, you can learn how to use a vector and a string and not have the problems. But... Yeah. Profiles are there to be able to have compiler and static analyzer support for that kind of thinking. And educators are asking for something like that, too.

• 1:50:43Speaker 00

  A lot of people think profile simply is to deal with memory safety and performance. No, it has to give people a better tool, both for learning and for doing specific kinds of work.

• 1:50:59Ryan Peterman?

  And then last question for you is if you could go back to the beginning of your career and give yourself some advice, what would you say?

• 1:51:06Speaker 00

  Oh dear, yeah, that's a time machine question. I sometimes said that for my students. You have a time machine, go back and give Dennis some advice. And once you've done that, step 10 years forward and give me some advice. It's a good exercise. I usually get some really good stories out of it and some suggestions.

• 1:51:39Speaker 00

  I think

• 1:51:42Speaker 00

  a lot of

• 1:51:47Speaker 00

  I tried to avoid the two-way conversions of the built-in types in C.

• 1:51:57Speaker 00

  I should have fought harder for that. I tried, but was stopped by the people in Bell Labs.

• 1:52:06Speaker 00

  And these were more experienced people than me and such. I should have gone further there. Furthermore, I should have delayed the release of C++ till I could have something template-like so I could do a better standard library.

• 1:52:27Speaker 00

  It wouldn't have been good enough, but it would have gotten people into the habit of using a standard. Everybody was building standard libraries and we got saved by Alex Stefanov with the STL, but that was real luck, because I made a mistake in not delaying till I could have built a good vector and class hierarchy stuff. And then finally, if I'd known what I know now about standard committees and bloated

• 1:53:06Speaker 00

  bureaucracies, and we have more subgroups now than we had members to start out with, I would have tried very hard to set up some kind of steering group, so that people could make suggestions, but we wouldn't have a vote with, say, 500 people. We would have suggestions from a community of 500 people, and we would have maybe a group of five or six people with vast experience and cared for the whole language, who made

• 1:53:49Speaker 00

  the decisions based on what was proposed. Something like that, but I did not have the experience or the knowledge to make such a suggestion. Notice that I did not mention tools. C++ has a weakness in tools, and that was because it grew up early in a time with limited tools, limited...

• 1:54:19Speaker 00

  Compute power, limited memory, so I couldn't have done it. One constraint on the exercise I give to the students for time machines is try and make sure that it would be possible to follow your advice. And if I just said, "I want this," then a lot of the things couldn't be done till 20 years later, and therefore would never have happened. There's a lot of languages designed to be perfect for the future computers and the future programmers. Most of them die, because by the time, 10 years later, they get the language, the world

• 1:55:04Speaker 00

  has changed.

• 1:55:05Ryan Peterman?

  On that first one, I imagine that would have been really tough to do, because the Bell Labs people were so senior.

• 1:55:15Speaker 00

  I failed. I tried. But it's obvious that you don't want narrowing conversions. I even wrote a paper about how to get rid of them today in a library last year. But it is a fundamental flaw in the type system of C and C++. And it came because they needed, they being people like Dennis Ritchie and Unix teams, they needed to be able to handle both integers and floating point. And they didn't think of explicit type conversion, and they thought explicit type conversion was too clunky.

• 1:55:59Speaker 00

  They didn't actually get cast till about five years after they got floating point integers. And of course, you have to be able to turn a floating point into an integer, right? And so that you get implicit conversions whenever you can, also things like integers into characters.

• 1:56:22Speaker 00

  Problematic, but since you are writing fundamental software, you didn't want to write something complicated and you didn't want to have runtime checking. You couldn't afford that. And, well, so it was established long before I came and my attempts to to deal with that failed.

• 1:56:47Ryan Peterman?

  It sounds like it wasn't for no reason. It, you know, saves resources maybe or very limited.

• 1:56:53Speaker 00

  They didn't have the resources to to deal with it. They built lint, the static checker, to deal with some of it. And small machines. And the other thing was that that group of programmers was significantly smarter and significantly more experienced than the average developer today. We have the law of large numbers. I think the last, the latest estimate I've seen on the number of software developers in the world is forty seven million. And at that time with Unix,

• 1:57:31Speaker 00

  the number of programmers probably was a few dozen. And the ones that didn't have a PhD in, from a good university were geniuses. It's easier to get a PhD into being a genius. And so they were for a different set of problems with a different set of machines and a different set of people. Boy, it was a pain and still is.

• 1:58:02Ryan Peterman?

  Asol, thank you so much for your time, professor. I really appreciate it.

• 1:58:05Speaker 00

  Okay, thank you.

• 1:58:07Ryan Peterman?

  Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Liskoff, Mike Stonebreaker, Mark Booker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard, so there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now. And so if you still want to pick one up,

• 1:58:52Ryan Peterman?

  I've left the late pledges open on Kickstarter, so you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the next episode.