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

31:59Bjarne Stroustrup: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 yes how do you use this language to build something that it is using itself how does that work this is bootstrapping and it's 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 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.

33:14So I can build a scope class that handles lookup and naming and things like that. And then you work from there.

33:27just writing the next version in the previous version you keep keep going and after a couple of years you have something that became known to the world of C++ and I wrote a book about it and a compiler came out in the world 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:58Bjarne Stroustrup: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? I never called it an object-oriented programming language. If you look at the C++ programming language, the first edition, the closest that comes 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 Simula's model of defining types, defining classes, and defining class hierarchies to handle groups of related classes.

34:59But 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 z 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 full-time compatibility.

36:19I 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, Fortran 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, 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.

37:18This 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 with that view of what you're doing.

37:32Bjarne Stroustrup: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 gives you 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 towards more design that helps the debugging and makes fewer mistakes at runtime.

38:33And 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++. Also, there's things you can't express unless you have a strong type system. I mentioned 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 Ts, providing all the Ts have the same interface for what you need. So you need the type system to resolve those things.

39:21And 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.

40:28But the C people compiled twice as often. This is just one experiment. I think the factor of two is just one experiment. But I wanted to move towards using more compile time resolution. Still doing that.

40:53Bjarne Stroustrup:I mean, for every language, there's this 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 a 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 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.

41:47This is true even today, because I think 99 % of all computers are embedded systems, and they tend to be memory-rest-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 120K, 250K, one 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.

42:52phones 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. the competition there is c and assembler and you mentioned the the research that was done

43:27Bjarne Stroustrup: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 um 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 are very popular and they are runtime checked and they run much slower.

44:18I 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.

45:10And 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 gets 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 mustn't crash, your car mustn't crash, your plane mustn't crash, you want guarantees.

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

46:20Bjarne Stroustrup:One thing that I think C++ is infamous for is kind of like memory safety issues or kind of foot guns 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 buffer overflows and people hacking in using that kind of stuff. And almost all of these cases were people writing C-style code or in C. and Herb Sutter has a talk with actual numbers and they are quite significant. 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.

47:35You 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 it's one of the things that makes me work on coding guidelines and on enforced profiles and on education.

48:39Bjarne Stroustrup: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 say you should only standardize what is common in industry. But when the bugs are common in industry, you should do something else.

49:26Bjarne Stroustrup: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? 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. language. That's what academic language development does. They break to improve all the time, and then they can't maintain a user population.

50:18I didn't actually choose to have a standards committee. I chose responsibility to the community. But one day, two guys came in representing representing IBM and HP, and I can't remember if it was Sun or Dec. 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, ah, it's 89. and they say, well, Pjarne, 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 say, no, Pjarne, you don't get it.

51:21Our 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, 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. And in the end, they said, okay, I will standardize C++ under ANSI rules, just like you suggest and you need. The computer community needs that. And by the way, what's ANSI rules for standardization?

52:16And 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 &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 written was based on it. Actually, I rewrote the documentation that became the ARM, the annotated C++ standards 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.

53:16And that became the foundation document for the standardization.

53:21Bjarne Stroustrup: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 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++ 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 wannabe C++ killers. I remember the ads for Java and people standing up saying, we'll kill, absolutely kill C++ in two years.

54:27I 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.

54:43Bjarne Stroustrup:How is it that C++, not exactly that it's a war, But just if we looked at adoption, clearly C++ gained a lot more adoption than Java. Yet I know Java 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, next to zero marketing done for it. Next to zero was$5 ,000 to be used over three years. And Sun 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.

56:06Today, 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, 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:44Bjarne Stroustrup: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%. Is that consensus?

57:56I can reassure you that no convener would call that consensus.

58:01Bjarne Stroustrup: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? It happens, but you can't just have numeric rules. Not everybody cares for the whole language. which 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.

58:57And 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 body heads, he asked 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.

1:00:01Not everybody weighs equally once there's a disagreement.

1:00:07Bjarne Stroustrup:For this podcast, I produce 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 CLU, not CLU. So to fix this, I used cursor three, 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.

1:00:44Bjarne Stroustrup: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 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.

1:01:23Bjarne Stroustrup: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 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:03It 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 value, seven. And maybe I didn't explain this well enough and there's a variety of backgrounds in the committee and 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. Because we needed something like that.

1:03:19But 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 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. And that's what concept formalizes. But it was always checked at the end. And I noticed a group of people that was overusing auto 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.

1:04:22And 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.

1:05:11Bjarne Stroustrup:I saw another anecdote in kind of the Standards Committee being heated at some times. 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 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? PowerPC. PowerPC. The X-CED6. And the Intel was doing, well, Intel.

1:06:01And 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 organizations 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, were mostly in the lowest level, even down in the microcode, that was relying on the way they have done it.

1:07:21And 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 Intel guys was right. 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 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, 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:19And 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.

1:08:45Bjarne Stroustrup:That's funny. Why did you have to do shuttle diplomacy? Why not just a group conversation? 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.

1:09:21So 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.

1:09:40Bjarne Stroustrup: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 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.

1:10:35But 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 representing the internal model

1:10:59Bjarne Stroustrup:of stuff he has a conservative garbage collector still used today and And we thought we needed an interface so 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.

1:12:01And 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 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.

1:12:42Bjarne Stroustrup:How does that work? Is it kind of like a wrapper around the memory allocation methods? Yeah. You have a different implementation of new or malloc or operator 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 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, you 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.

1:13:43the king 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 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 the highly predictable result is a lot of holes in the one gun deck battleship, and it's gone.

1:14:41So the king orders that this ship should now have two gun decks, and they've already started building it. 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'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 it was built, they tested it for stability. 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.

1:15:43Back, 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,

1:16:11this was 1624, I think. The ship gets finished. It's sailing out on 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. 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:09Always 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 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 Gundet 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-gun deck battleship.

1:18:04You 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, it 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:24Bjarne Stroustrup: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 preprocess 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 does 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 Turing completeness. you need some form of iterate or recurse and you need a comparison and that's about it.

1:19:27Then you can get true incompleteness. At least some of the theoreticians says, we can't do that, it will run forever. And the guy who 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.

1:19:55Bjarne Stroustrup: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. it. So if you imagine building a real Turing machine the way Turing designed it, you have to have a bunch of navviers 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 just 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 your trustness is sieve, or calculating factorials and such.

1:21:02And 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 Gabby Dress Reis built ConstExpr, 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 Turing complete. It turns them into ordinary functions.

1:21:57Bjarne Stroustrup:Generally, with programming languages, there's this high-level intuition that the closer to the machine you are, the higher the performance is. And I tend to see C is closer to the machine than C++, for instance. No, that's not the case. It's not the case. It's not as good as compile time calculation at 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++ compilers can do more at compile time. and so C++ runs as fast or faster than C in most cases. There's more information.

1:22:55If you give an optimizer more information, it can do a better job.

1:23:00Bjarne Stroustrup:Ah, okay. Yeah, because that was what I was going to ask you. 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 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? How does that compare? if you are very smart and you have infinite time, you can do better.

1:23:50By 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? 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. And I got out alive. And my main point was that C++ is good enough for more than 98 % of your code.

1:24:56So 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 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.

1:25:58Usually you run faster. Because clever stuff tends, 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 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 that with a friend of mine in Spain doing fluid dynamics.

1:26:55And we threw away the clever stuff, or actually a performance test suite example. So it was not a 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, But he also pointed out that 2 % to 3 % is 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.

1:28:00You 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.

1:28:16Bjarne Stroustrup:So when you say cleverness here, it's like human level, a manual management to 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. Yes, 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.

1:29:10Bjarne Stroustrup: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 pessimizes 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.

1:30:20And 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 difference in prompt, a lot of the code will change and you have to now check it again. All of the code that was generated knows 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.

1:31:09You have to try to 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.

1:31:40not, 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, 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.

1:32:53I hear rumors of Bjarne 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 Dijkstra 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.

1:33:47Bjarne Stroustrup: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 because it's not validating. And the people that are really good at that kind of stuff tend to not want to spend all their 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.

1:34:46I'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 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.

1:35:54Bjarne Stroustrup: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 imagine you knew that you were embarking on a journey for decades. 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. But one was, well, I was the team that did it. Secondly, so lack of resources, lack of time.

1:36:43And 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, improve 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++ 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.

1:37:41It's really nice to see interesting uses and such. So I was at JPL and I talked to the people who was 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.

1:38:57You have to write. And the code for that was interesting. I learned something. 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:18Bjarne Stroustrup: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. Yeah. Somebody asked a question at a talk I was given in Boston back in the 80s, and I shot that one back. Well, not thinking, but it's a good quote, and it's correct. Arnold Penches, who's 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.

1:40:17So if you have a saw, a 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:02Bjarne Stroustrup:You also have this other great quote. 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 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 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 were.

1:41:56I 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 mustn't get stuck with just what's in your language. It's like it's not good for you to be monoglot. 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. Okay. 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.

1:43:08Bjarne Stroustrup: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, I mean, 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++, it would be much simpler and nicer. Usually they want to throw away things like C.

1:44:00But 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 way of expressing my frustration with people who oversimplify. People think they can program without 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.

1:44:50Bjarne Stroustrup:Yeah, I think I saw somewhere kind of in response to C++ being difficult for some people, people who have the perspective of programming should be approachable and anyone can learn programming. And I think you expressed the opinion that C++ is not necessarily for everyone. It's for serious programmers. I mean, the first line of the C++ programming language version 1, 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.

1:45:48If 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 Russen 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, look at the problem, and then learn from what worked and what doesn't.

1:46:48Bjarne Stroustrup: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.

1:47:07I 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 everything to 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 yeah you must simplify it and I need these two features I need them yesterday.

1:48:29You must, when you are 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.

1:49:11Bjarne Stroustrup:For anyone who wants to learn C++, I think a common question is, what is the top technical book recommendation that you would have? Learn modern C++. There's a book I wrote when I was teaching undergraduates. 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 as the starter.

1:50:10And a lot of courses still says you learn C first so you learn some issues, malloc and pointers and then later you can learn how to use a vector and a string and not have the problems. but profiles are there to be able to have a compiler and static analyzer support for that kind of thinking. And educators are asking for something like that too. A lot of people think profiles 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:58Bjarne Stroustrup: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 a time machine question. I sometimes set 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. since.

1:51:39I think a lot of...

1:51:47I tried to avoid the two-way conversions of the built-in types in 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 Stefanoff with the STL but that was real luck because I made a mistake in not delaying until I could have built a good vector and class hierarchy stuff.

1:52:58And then finally, if I'd known 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 standard 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 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.

1:53:59Notice 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 said, 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.

1:55:06Bjarne Stroustrup:on that first one I imagine that would have been really tough to do because the the Bell Labs people were so senior I failed I tried but it's 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 the Unix team, 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:59They didn't actually get casts until 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. Problematic, but since you are writing fundamental software, where 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 deal with that failed.

1:56:46Bjarne Stroustrup:It sounds like it wasn't for no reason. It saves resources maybe or 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 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 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.

1:57:47It's easier to get a PhD than 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 well thank you so much for your time professor i really appreciate it okay thank you hey thank you for watching this podcast if you

1:58:08Bjarne Stroustrup: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 Lisskov, 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.

1:58:43Bjarne Stroustrup: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