The Peterman Pod - Creator of C++: Bell Labs, Negative Overhead Abstraction, Mistakes | Bjarne Stroustrup

Episode Date: May 18, 2026

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 - Intro0:50 - The origin of C++8:46 - What Bell Labs was like17:24 - Dennis Ritchie24:00 - When to build a programming language31:59 - Bootstrapping a language33:58 - C++ is not object-oriented37:32 - Discussing type systems46:20 - Memory safety49:26 - Standards committee anecdotes1:09:40 - Adding automatic garbage collection to C++1:18:25 - Template instantiation is Turing complete1:21:57 - Abstraction and performance1:28:51 - AI writing code1:35:54 - His motivation1:39:18 - Famous quotes1:46:48 - Reflecting on building C++1:49:12 - Top C++ book recommendation1:50:59 - Advice for his younger self1: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

There wasn't a language in the world that could do what I needed. This is Bjornis Stroostrom, creator of C++, and we talked about his career starting with Bell Labs. What gave you the conviction to fly on your own tab? It was the best place in the world, right? I mean, do you need any more? And I also asked him all about programming language design. What was the most technically challenging part to implement? Everybody asked that question, and I think it's a wrong question. But I tend to think that more abstraction costs you something.

It's not the case. We can do negative overhead abstraction. Is there any part where you think, oh, that was a mistake? I should have fought harder for that. Here's the full episode. What is the origin story behind C++? 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, applied engineering place in the world. I looked around 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 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 had succeeded, 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. 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, network drivers, device drivers, all that kind of stuff. And then it needed high level things that says, well, there's a module here and 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, well, Dennis Ritchie and Brian Kearneyhan was down the hall. And I said, distributed UNIX because I was in the home where Unix was invented and still being built. 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 Christenugur and Oll Johan Daal 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, user-defined types classes, was handled the same way as building types. And that's basically the start of what neither seen or a simulator 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 two integers. You can add to 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.

In one of the lectures that I saw that you gave, you talked about rewriting a simulator in BCPL. Is that the distributed Unix work? 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 of software on a distributed system to do the PhD work on distributed systems. And of course, the idea of a distributed unit, 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.

It's misnamed because it was a general purpose programming language, and it's having a bad name. It didn't help it at all. But anyway, I wrote this simulator, and I wrote little examples, test cases, etc., etc. 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. So I was kicked off the machine and it was clear that Simula could write, I could write the program I'm insimular 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 simulator there because simulator 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 computer. So I basically rewrote my simulator in BCPL. and BCPL is a language that will 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. But once I'd done it, my program ran, I estimated it 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. And, well, C++ simula didn't have all of that,

but it came closer than any other language that existed. C++ came out of there. Yeah, in that lecture, you said something like that, writing that program in BCPL was so difficult. You lost half your hair debugging that. That's almost exactly true. And I lost the other half getting C++ going over the years, but anyway, it worked.

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? Bell Labs was the place to go if you wanted to do practical 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. and one day in my last year in Cambridge one of the people from middle 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 all people to see what has been going on And he says, well, when you need a job, give us a boss. And so I did. And I flew over to New Jersey on my own tab, actually. And my later boss, Sandy Fraser, great guy working with networking, told me that I'd come out 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. What was the interview process like? You just talk to some people. I mean, I remember having a longish chat with Dennis Ritchie, for instance. And I, I, I talked to people doing networking mostly. There wasn't an 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.

So it's kind of like the belief and credibility that other people say that you have. Like Dennis Ritchie talked to you and that he knew that. that you knew at your time. 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 letter, 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. 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?

No, well, it was the best place in the world, right? I mean, do you need any more? 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. Today there's more industries, has a stronger pull. At that time, would it have been IBM or something that would have been the best industry? No, I talked to IBM. They weren't as good as the Bill 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. At a place like Bell Labs, how does project selection go? Like, how does all that work once you're employed?

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 hire 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. 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 point fund 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 they were actually worrying when they built Unix because it eventually involved five or seven people and it was getting too big for for that model of the world of individuals doing interesting things. 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 coupled devices that are all cameras came out of there. They tried to do video phones 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 cell phones 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, 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. It doesn't matter how good C++ is, the computers of today can't do it. Back then though, but now... 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 they gave me the numbers.

That was why I declined to help them because it was important. because it was impossible. I saw somewhere when I was doing the research that you said you had gotten lunch with Dennis Ritchie once a week for like 16 years or something like that. And 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++. It feels 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, I knew Dennis. We were not fighting. I still know Brian Kernighan. I was talking to him this Friday. 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 Z guys couldn't handle two. 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 about overloading because you had to look at the declarations of functions before you knew what the meaning of a call was. but that's a very reasonable way of thinking. It just happens that it works.

And anybody who writes C today are using my handiwork essentially all of the time because the modern syntax for function definitions and function declarations and the core semantics came out of the early C++. plus early serial classes work of mine. So when people start ranting, they should remember that they're actually doing my,

using my handiwork every day. 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 about this concept where he proposed to the C standard committee, this idea of a fat pointer where it also has, it stores its size as well. And you mentioned the C committee didn't approve, and I was curious if you could tell that.

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 sea expert. He's not ever come to meetings. Very strange attitude. But anyway, we knew the problem about 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 attach 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 48K 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 256 kilobytes. 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. When you put together really impressive people, like 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? 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 like 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. Also, you talk to them and you learned 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 are doing it. There are some places that has that effect on people

and has the density or 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? 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? Well, that's a relatively easy a question to answer. And everybody asked 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. 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 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 ages, 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, and then you see what works. and what doesn't work, 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 the 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 civil classes in 79, but people didn't get it. And so there's teaching to do it. But anyway, once you figure out that you have a problem that require a new language, then you start looking what there is. And you have lots of help lots of books about analysis and about 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 highly amusing. 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. Domain specific languages are great when you find the right solution to the right problem. But identify the problem first. 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 probably high-level languages at the time tended to use interfaces that took away performance. Quite often they required garbage collection, which is not very good for device drivers, for instance, or for building garbage collectors. So, yes. identify the problem and try and solve it. Back when you were creating C++ and you had identified the problem and so then you went off to build C++

and 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 lexer, and all those things. When you were building the original thing, what was the most technically challenging part to implement? I don't think any part was particularly genetic. It was more that there was 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. And nobody wants you to touch their linker because if you make a mistake, everything breaks. So I decided a rule, don't miss with a 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, I'm going to write a language here, right? And I can't, if I wanted to be an optimizer specialist for deck 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 civil 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. 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. It was part of the reason I chose it. So let's use it for the low level. And I could have hidden C and re-created probably a better interface. But I decided that I'll just use C-have-C compatibility at the time. What I said was that, well, we can have DEN-D compatibility. mistakes which we know and we can have my mistakes which we don't know yet so we'll take

denises 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 I that's see compatibility came in that way partly as an implementation technique partly to get into the culture and tool support and such. I saw somewhere in my research that, you know, 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? This is bootstriping. and it was not an unusual thing. So I started with C, and 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 I, in that, I wrote a simple compiler for again what was a subset of C++. And now I can use operator overloading and overloading in general classes. So I can build a scope class that handles look up 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. But I didn't invent this technique. This was known as bootstress. I think I was taught it as an undergrad that you could do things like that. 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? Yeah, I never called it an object-oriented programming language. If you look at the C++ programming language, the first edition, 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. For instance, I do not want object-oriented complex numbers. I don't want to say two dot as something to get to some parts of numbers.

I really want to say two plus z and I want that to end up being roughly the same as said plus two. And no dots, no arrows. Math has developed a notation over the last 300 years or so. 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 Fortrain 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. A lot of researchers wanted to build a language, a system that allowed reuse. I wanted to reuse things that existed. I mean, Fawtron was there with some great software. C was there with some great systems 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. 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 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. what you're doing. At the time that you wrote C++, C was already there and it had a weaker type system than what C++ eventually had. And it gives your thoughts on the trade-offs behind that and why did you choose to make the typing system stronger in C++? 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 arrow or towards more design that helps the debugging and makes fewer mistakes at runtime. And the type system is one of them.

And actually what you get and see today, to a large extent, is stronger. Well, no, it is much stronger type than it was in those days, and partly because of C++. Also, there's things you can't express unless you have a strong type system. I mentioned the overloading before. 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 T's, providing all the T's have the same interface for what you need.

So 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 do so much debugging. There was a large-scale experiment done in Bell Labs in Chicago, where they had some groups using C++, switching to C++, and they wanted to know whether they were more or less productive. and some people claimed that the slower compilation slowed them down.

And somebody simply measured how much compile time was used before or after switching to C++. And they found that the amount of 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 to see people compile twice as often this is just one experiment I said the factor of two is it's just one experiment but I wanted to move towards using more compile time resolution still doing that I mean for every language there's this you know the Cata 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? Because of the problems I wanted to attack. What do you do when you get a runtime error? And in something like small talk, 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 I think 99% of all computers are embedded, systems and they tend to be memories restraint. 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 120k, 250k, 1 megabyte, things like that. And I think it's still relevant for many systems. You can build a camera like that. 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 constraint. And statically type 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.

the competition there is C and assembler. And you mentioned the research that was done on the compile time on, you know, if you catch things earlier, you compile less often, but maybe it takes longer. In this case, I could see a similar analogy where 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 type language, the errors may come later, comparing for a developer, like which one is more time efficient? I don't know any solid research on that, but you can look at it. JavaScript and Python's very popular, and they are runtime checked, and they run time 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. 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 language is found at runtime later. 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 guarantee to work, like the telephone switch must and crash, your car must not crash, your plane must and crash, you want guarantees. and their hearters provide in a very flexible dynamic type system. One thing that I think C++ is infamous for is kind of like memory safety issues

or kind of footguns that exist there. I'm so tired of that. I haven't had those problems for years. And somebody did a study of the obvious problems with body. for overflows and people hacking in using that kind of stuff and almost all of these cases when people writing C-style code or in C and Herb Sutter has a talk with actual numbers and they are quite significant it's it's sort of of that kind of problems, more than 90% are for people that don't write more than C++.

They use raw pointers to pass things around without 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. 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. 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 one of the things that makes me work on coding guidelines and on enforced profiles and on education. 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? 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.

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. 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 wanted to ask you

is if it was addictive. So you just had full say, what language features would be in that, you know, maybe a harder to get by? 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 their help 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. But one day, two guys came in representing IBM and HP,

And I can't remember if it was son or deck. 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 H-G-9. And they say, well, Pianne, 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.

So they said, no, Biana, you don't get it. Our 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 trust you, of course. course, but not your employer. We compete with them sometimes. And you can get run over by a boss.

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, ow. And in the end, they said, okay, I will standardize C++ under anti-rules, just like you suggest and you need the computer community needs. that. And by the way, what NC rules for standardization? And so they told me and we started a year later. But this was the way it came about. Some very important organizations wanted that standardization. C was on the track to get standardized. And AT&C 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 written was basis on it. Actually, I rewrote the documentation that became the arm, the annotated C++ standards, the manual that gave the definition, the manual of the language. and for every feature some rationale and some way it could be implemented or was implemented

and that became the foundation document for the standardization. When they were strong-arming you, what if you had just said no? Like what would have happened? I think, well, I think C++ would have faded into becoming an academic

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

I remember the ads for Java and people standing up saying, we'll absolutely kill C++ in two years. I thought that was rude. And anyway, we have 10, 12 times more C++ developers today than we had when they said it. So it didn't work. 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, I know Jop. had the backing of 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 next to zero was five thousand dollars to be used over three years and son used much more money on advertising and marketing Java than was ever used in C++ development. 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.

And 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, 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, 6.000. 60 to 40 or even worse 52 to 48, no percent.

We don't do that. And that's painful and tedious and good. When you say consensus, that 100% need to approve? 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. What's the lower bound that's coded into the rules? 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%? But the implementers of C++ compiler and standard libraries from Google, Apple, Microsoft and others were all in the 5%.

I can reassure you that no convener would call that consensus. And that makes sense intuitively. I kind of wonder with democratic decisions, there needs to be objective rules. So what if the convener made the wrong decision? 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 the standardization and don't understand standardization and knows only what they're known from their development organization that they have been part of, which might be a small one. You need some judgment. 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, Look, if everybody is four, 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. For this podcast, I produced transcripts for every episode for convenience skimming,

and I built a custom tool to automate that. Recently, I noticed in the Barbara Liskoff transcript, my simple speech-to-text tool was getting a lot of things wrong. For instance, the clue programming language is spelled all caps, CLEU, not clue. So to fix this, I use 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 out 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.

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 Versal 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 Rback, 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, 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 Otto. And I know Otto eventually made its way in there, but what's the story behind why it was so, you know, negatively received at that time? 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 also is just the simplest constraint it must be a type as opposed to a value seven and maybe I didn't explain this well enough and there's a variety of backgrounds and in the comedians maybe they they didn't know languages of the generic types ML Haskell things like that so it it was those horrible egg so anyway we still got it 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 the type is correct that auto has resolved to something that supports the operations that you're going to do on it. to do on it. And that's what concept formalizes, but it was always checked at the end. And I noticed the group of people that were overusing auto in a, 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 auto was meant. So you have auto and the comment says, must be an input channel. Now you simply define input channel. 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. I saw another anecdote in kind of the Standards Committee being heated at some time, 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? I was actually talking to Brian McNight, who was the IBM rep at the time.

And it was the 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? PowerPC? Power PC. And the X-E-6. 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 he anyway

also a good guy I used some of his slides in my presentations so I knew these guys but they were totally deadlocked I mean these are massive again massive organization with massive amounts of code out there. And basically 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 was done a long time ago and they just couldn't rewrite all of that code

and get it right even if the Enzel Guys was right. Okay. And the Inselguise 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, the guy representing Intel here.

And what's the problem here? Tell me about it. Explain it. I go down and explain. He's saying this. They say, well, there's this, this. And I go back again. And I spent a couple of hours literally doing shuttle diploma.

walking from one corner of the rooms to the other. 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 actually the result was improvement. cross-pollination. That's funny. Why did you have to do shuttle diplomacy?

Why not just a group conversation with... 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. He has a C version of it so he can get it into the, but it's the bottom of the Linux kernel. 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 think about C++, one of my immediate thoughts is no garbage collector, we're going to manually or manage the memory ourselves. How would that even work?

There's two things there. One, I wanted to automate resource management in general, not just memory. And for that, you have constructors, destructors, and the techniques that was later known as our AIA resource acquisition is initialization, which is probably my worst naming ever. But I was busy at the time. So 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 Berm.

He was the one that represented the internal model of stuff. He has a conservative garbage collector, still used today. And we thought we needed an interface. that it could be standard how you used such a garbage collector. 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. And what we found was over the next 10 years, the amount of usage of garbage collection decreased as RAAII, the resource management that had been there all the time got more and better understood and was used more. Furthermore, the people who still used 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. How does that work? Is it kind of like a wrapper around the memory allocation methods? Yeah. Okay. You have a different implementation of new or malloc or operate a new, or whatever it is you're using at your lowest level.

And then delete becomes something slightly different too. There's this cautionary tale in the C++ community about this ship Vasa. And I was kind of curious, like, why that's popular. 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 and it was going to be a good fighting battleship

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 gun decks. And this was an then old-fashioned battleship with only one gun deck. And if you put a one-gun deck battleship next to a two-gun-deck battleship next to a two-gun-dick battleship, the highly predictable result is a lot of holes in the one gun deck battleship and it's gone. So the king orders that this ship should now have two gundegs. And they've already started building it.

So they add another gun deck. They add cannons up there. And the king also watched now the ship is, bigger, they want more statues and beautiful things. So it becomes a bit top-heavy. And rumor has it, I've 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 to stability. And the way you test a ship like that for stability is you take the whole crew and you run from one side to the other. Back, forth, get harmonic there. And if you can do that 14 times, then it will stand up to the Baltic and the North Sea. Rumor has it, actually, as I said,

I think it's a fact. that they did it seven times and then they stopped because it looked dangerous. So this was 1624, 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 a war and it's gone and it ends down in some place where

there's not much much oxygen 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. Always improve the foundation to make sure that it's just not a random set of features that you have added because that's complexity. Furthermore, do not compromise your testing. That's really dangerous. And furthermore, you've all noticed when your high buses say something should be done, and the high buses 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 gun-dead battleship. We'll just not call it the Vasa. 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 nope 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 At some point, someone demonstrated that the C++ template instantiation mechanism was turning 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. a compile time, how's that work? 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 during completeness.

You need some form of iterate or recurs, and you need a, a comparison, and that's about it. Then you can get true incompleteness. And at least some of the theoreticians says, we can't do that, it'll run forever. And the guy who, Ernanru, 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 touring machine, you have the tape. And the tape has to be infinite. So if you imagine building a real touring machine, the way Turing designed it, you have to have a bunch of navvies building track all the time when it gets out there.

Of course we don't do that. 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 something. simple calculations, like prime momenters or your trust and this is, yeah, your sustences

or calculating factorials and such. And it's so awful and it's so expensive and it uses up so much memory that it becomes a problem. So that was why I and Gabbyter's Reyes 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 Constable, if you want to guarantee that this is done.

And so that takes care of. the obvious misuses of the idea of templates being during complete. It turns them into ordinary functions. Generally, with programming languages, there's this, you know, high-level intuition that the closer to the machine you are, the higher the performances. And, you know, I tend to see C is closer to the machine than C++, for instance. It's not the case. It's not the case.

It's not as good as compile time calculation that C++ is. And anyway, we have exactly the same machine model because C borrowed the C++11 machine model. So if you write the same code in both languages, you get the same result, except the C++ compiler can do more. at compile time, and so C++ runs as faster, faster than C in most cases. There's more information. If you give a optimizer more information, it can do a better job. Ah, okay. Yeah, because that was what I was going to ask you.

It was you had said somewhere that C++ can be more performant than C, but I tend to think that more abstraction costs you something. 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.

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? if you are very smart and you have infinite time, you can do better. 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 smart?

smarts. This is even starting to affect clever code. I gave a talk to Slack last year, which is a group of very perform and 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 and I got out alive 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, 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 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 ages. And there's people who does nothing but using different optimizations on the next. 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 there is a lot of it still today because the techniques carry on in people's heads and some of the code remains tend to use a ratch 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 cash 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 and we threw away the clever stuff or 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. Knooth says, don't do premature optimization. But he also pointed out the 2 to 3% is where you should optimize,

which is exactly the number I'm using. And so first built 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 figure out where the time is spent and then you optimize that. But a lot of the time you don't need to go to that stage. It's fast enough. I see. So when you say cleverness here, it's like human level, a manual management that eke out performance. Yes.

And you're saying that actually if you don't do that, you're giving the compiler more to optimize and it can do a good job. and it's much, much better than it used to be. Code that was cleverly and correctly optimized in the 1990s are often pessimized today because machine architectures have changed and the compilers have improved. When I look at the industry today,

more and more of code is being written by machines than humans. And I feel like a lot of programming language design is thinking about how do you make it amenable to humans solving problems and 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 models and machines. I 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 has not been successful. 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. 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, 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, even if you make a slight different than prompt, a lot of the code will change, and you have to now check it again. All of the code that was generated, and there was 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, you don't actually know where it's changed.

You have to try and figure that out. 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 safety critical, performance critical.

code. Now, let's say that 70 or 80% of the world's code doesn't fit that pattern, but it's that 10, 20% of the code that I'm interested in. And it's not there, it's not there, and I don't see it coming with the LLM model. Furthermore, LLM, 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 bianna apps being written that's fed my

writings 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. It's not English.

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. 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 10 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 10 years. I'm always told by AI proponents

that either the problem has already been solved or it will be solved in the next release. But I hear Anthropic 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 $100 million center and run the electricity for 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. 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. And like when you started C++, I can't imagine you knew that you were embarking on a journey for decades.

And so 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. 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, that's one reason C++ plus wasn't just an 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 knew we would evolve. The other half of that answer to that question, what keeps me going, is applications. It's really nice to see interesting uses and such. So I was at JPL and I talked to the people who are doing the Mars rovers.

That's cool stuff. 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 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, 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 interesting. I learned something. And I still travel around. 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. 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. Somebody asked a question at a talk I was given in Boston back in the ages, and I shot that one back. Well, not thinking.

But it's a good quote, and it's correct. Arnold Panshez, has got a Nobel Prize in physics, so he's not a nobody, was one 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. 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 old-fashioned slow accelerating car can't. It's fundamental to having power tools. You also have this other great quo. It's 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 being a better engineer or programmer, what would you recommend? Yeah, and if you've heard, if you've seen that interview, you'll know I waffle on that. deliberately. It is not so much which other languages you know, but that you get a set of ideas that I 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. Have a look at a functional language. ML or Haskell would be obvious solutions. Or just pick something different. The point is that you must not get stuck with just what's in your language. It's like it's not good for you to be monoglod. I mean, you know what you call somebody who knows three languages,

trilingual, who knows two languages, bilingual, one language, American. It's 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. because you're building things and you should broaden your mind with ideas and techniques.

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. Well, that's very simple. 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. 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++ plus, it would be much. simpler and nicer. Usually they want to throw away things like C. But then you annoy a few million people. And you don't actually succeed because they'll stick to the old stuff. So it's a, it's a way of expressing my frustration with people who oversimplify. People think they can program without being learning to program.

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. It's always simplification annoys me. And I probably shouldn't express annoyance. I very rarely do. But in this particular case, my frustration showed.

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 expressed the opinion that C++ is not necessarily for everyone. It's for serious programmers. Yeah. I mean, the first line of the C++ programming language, version one, first edition, was 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 you and that's your problem 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 I mean Gildolf and Rassen built Python with the expertise it aim of allowing many people or even or 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. Look at the problem. And then learn from what worked and what doesn't.

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

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. I explain it. People come up and say to me, C++ is too complicated. it. Yep. You must simplify it. 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. 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. For anyone who wants to learn C+++, I think a common question is like, what is the top technical book recommendation that you would have? 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 practice 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. But use the latest C++, learn the modern way first. Don't start learning all the bad ways of writing C starter.

And a lot of courses still says you learn C first, so you learn some issues, Maluck and pointers and then later you can learn how to use a vector on 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. A lot of people think the 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. 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? Oh dear. Yeah, that's the 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. I think a lot of, I tried to avoid the two-way conversions of the building types and C. I should have fought harder for that. I tried but was stopped by the people in Bell Labs. 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. 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 Steffanov with the STL,

but that was real luck because I made a mistake in not delay until I could have built a good, vector and class hierarchy stuff. And then finally, if I'd know what I know now about standards committees and bloated 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 they cared for the whole language who made the decisions based on what was proposed something like that, but I did not have the experience or 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 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 say, I want this, then a lot of the things couldn't be done until 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 has changed. On that first one, I imagine that would have been really tough to do because the Bell Labs people were so senior. 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++ plus.

And it came because they needed, they being people like Dennis Ritchie and the Unix team. And so 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. They didn't actually get casts till about five years after they got floating point and 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.

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, came and my attempts to deal with that failed. It sounds like it wasn't for no reason. It saves resources maybe are very limited.

They didn't have the resources to deal with it. They built Lint, the static checker, to deal with some of it. And small machines. Another thing was that that group of programmers was significantly smarter and significantly more experience than the average developer today. We have the law of large numbers. I think the latest estimate I've seen on the number of software developers in the world is 47 million. And at that time, with UNIX, the number of programmers probably was a few dozen.

and the ones that didn't have a PhD from a good university were geniuses. It's easier to get a PhD and it's 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. Awesome. Thank you so much for your time, Professor. I really appreciate it.

Okay, thank you. Hey, thank you for watching this podcast. 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 Liskov, Mike Stonebreaker, Mark Brooker, 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, 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.