CppCast - Past, Present and Future of C++

Episode Date: May 4, 2017

Rob and Jason are joined by Bjarne Stroustrup, designer and original implementer of C++ to discuss the current state of C++, his vision for the future as well as some discussion of the past. Bjarne Stroustrup is the designer and original implementer of C++ as well as the author of The C++ Programming Language (Fourth Edition) and A Tour of C++, Programming: Principles and Practice using C++ (Second Edition), and many popular and academic publications. Dr. Stroustrup is a Managing Director in the technology division of Morgan Stanley in New York City as well as a visiting professor at Columbia University. He is a member of the US National Academy of Engineering, and an IEEE, ACM, and CHM fellow. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages.  To make C++ a stable and up-to-date base for real-world software development, he has been a leading figure with the ISO C++ standards effort for more than 25 years. He holds a master’s in Mathematics from Aarhus University and a PhD in Computer Science from Cambridge University, where he is an honorary fellow of Churchill College. News C++ Montreal HPX V1.0 Released A serious bug in GCC What's New in ReSharper C++ 2016.3 and 2017.1 Bjarne Stroustrup Bjarne Stroustrup's homepage Links A Tour of C++ The C++ Programming Language (4th Edition) CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, Present and Future" Sponsors Backtrace JetBrains Hosts @robwirving @lefticus

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io.cppcast. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice, CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com. CppCast is also sponsored by Pacific++, the first major C++ conference in the Pacific region

providing great talks and opportunities for networking. Get your ticket now during early bird registration until June 1st. Episode 100 of CPP Cast with guest Bjarne Stroustrup recorded May 3rd, 2017. In this episode, we discuss HPX and a bug in GCC. Then we talked to Bjarne Stroustrup, designer and original implementer of C++. We talked to Bjarne about his vision of the future of C++ and what he the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Doing good, Rob. Episode 100.

Yeah, we made it. We made it. So, obviously, we have a great guest today, which we'll get to in a minute. First, I wanted to have one programming note. Jason, you and I are going to be pretty busy for the next two weeks. Conference season

is upon us. I'll be at Microsoft Build next week, and then the following week you'll be giving how many talks at C++ now again? Just two this year. Just two this year. Okay. But because of the two of us being at these different conferences

for the next two weeks, we don't currently have an episode planned, an interview planned during those two weeks. But for me, going to the Microsoft conference at least, Microsoft is actually reaching out to podcasters who are attending the conference, and I might have opportunities to interview speakers there. So it's possible that we might put out a build recap episode type thing. Yeah, that'd be fun. Yeah. But we're probably going to miss

at least one of the next two weeks, so just be but uh we're probably gonna miss at least one of the next two weeks so just be aware that uh we're probably gonna be missing an episode or two right and we'll be returned after c++ now and we'll i'm sure have plenty of exciting things to talk about then okay well at the top of our episode i'd like to read a piece of feedback uh we got a great uh little note on uh on facebook here from a listener, Jean-Michel Carter in Montreal. He writes in, hey guys, great show. I'm always learning something from each episode, whether it be from the pieces of news or the great guests you have on. I wanted to let you know that your podcast inspired a couple of us here in Montreal to start our own C++ user group.

Anyone in the Montreal area that is interested should join C++ Montreal on Meetup. So it's always great to hear. We're really happy that we're inspiring a couple new user groups. Yeah, and if you're in the area, check it out. User groups are always fun. Yeah, and this one's at meetup.com slash cppmtl

and I checked and they're already on the meeting C++ user group list. So it should be very easy to find. Yeah. Very cool. So we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com.

And don't forget to leave us a review on iTunes. Joining us today is Bjarne Struestrup. Bjarne is the designer and original implementer of C++, as well as the author of the C++ Programming Language and a tour of C++ programming principles and practice using C++, and many popular and academic publications. Dr. Stroustrup is a Managing Director in the Technology Division of Morgan Stanley in New York City, as well as a visiting professor at Columbia University.

He is a member of the U.S. National Academy of Engineering and IEEE ACM and CHM fellow. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages. To make C++ a stable and up-to-date base for real-world software development, he has been a leading figure with the ISO C++ standards effort for more than 25 years. He holds a master's in mathematics from Aarhus University and a PhD in computer science from Cambridge University, where he is an honorary fellow of Churchill College. Bjarne, welcome to the show. Thanks. Thanks for inviting me. It's fun to be here. You know, I always like to ask people questions like how they got started with C++, but that

seems kind of irrelevant to ask you. So I'm curious, though, what was the first... Sort of backwards, right? Yeah. Yes, right. What was the first programming language that you did use, I guess, is I'm curious about? Sure. That was Alcol 60 on a little old Danish computer called Gia

that filled a very large room and had about 1K 48-bit words or something like that. And after that, I learned a lot of other languages, of course, and tried a lot of other computers. That's interesting. Including Simula and C. I don't think anyone else has mentioned Algal in any other interview we've done. Maybe I'm a bit older than some of the other people being interviewed,

or maybe they wouldn't admit it. Right. I know when we talked to Kate Gregory, she mentioned doing some punch card programming, right? Ah, they were lucky. We didn't have punch cards. We had to use paper tape. Oh, wow. Sorry about my Yorkshire accent. It's not quite up there. Okay, Bjarne. Well, we have a couple news articles to talk about.

Please feel free to comment on any of these, and then we'll start talking to you about your thoughts about C++17 and the future of the language. Mm-hmm. Okay. So this first one is HPX version 1.0 has been released. And apparently this is their 15th release, but this is the first time they've given it the 1.0 label,

which means it's really production-ready. Although I think when we talked to Harmut Kaiser on the show a while back, he mentioned that it had already been used in production systems for quite a while. It's a project they've been working on a long time. It's a pretty big milestone for them. They say it's feature-complete is why they called it 1.0. Yeah, and they mentioned that it's implementing a is why they called it 1.0. No. Yeah, and they mentioned that it's implementing a bunch of the new C++17 parallel STL features,

and they're the first ones to implement all of them, I believe. Cool. Yeah, Bjorn, do you have any thoughts about HPX? I haven't been doing much in that area recently but you know 600,000 calls is quite a lot and you take a lot of interesting techniques to get there and people have been trying

it for a while. It's nice to see C++ is playing in that space. It has for a long time though I mean oh what sir and they do interesting things. One question I have that I'll have to explore about it is, does it actually scale down from those large numbers? That is, can I use it if I've only got a dozen cores? Because in some systems, there's been a break in what they can do.

They can do thousands of processors really well, but they're not actually really that good if all you've got is sort of a garden variety 32-core processor. So that's what I will be studying about it. But I haven't done enough homework to have an opinion. Thinking back to when we interviewed Hartmut, I believe he said that it can help any C++ application get more performance, even if you're just talking about something that's running on a single machine. That's good. That's good.

And it's good that it takes the standard interfaces so that you can play with it more easily. Yeah, that part's particularly interesting to me because I've been attempting to use the C++17 parallel algorithms on Clang and GCC, and as far as I can tell, neither standard library has them implemented yet. Well, it's still 17, and the ink isn't dry on the standard yet. That's true. We're getting so much better that we're getting spoiled. That's very true. Okay. The next article we have is about a bug that this person found in GCC. Yeah. If you use aggregate initialization syntax, it's possible to

initialize objects that will never have their destructors called. That's truly horrid. That's the kind of bug that should be fixed, preferably yesterday. And if it's a standards text that hasn't gotten it right, you have to fix

the standards test. This is messing with the basic model of the language. That's a good point. I'm not sure if anyone tested it with any of the other compilers to see if it's present in just GCC or if Clang or MSVC is having the same bug, which would maybe indicate a lack of definition standards for it. I believe in the Reddit discussion,

MSVC calls the destructor as expected. That's good. Good. But this bug's been open for more than two years already. Oh, wow. At GCC. It's hard. Yeah, they should really get that fixed.

Okay, and then the last article I wanted to talk about was this What's New in ReSharper C++ 2016.3 and 2017.1. And there's a lot of new features here for ReSharper C++. Obviously, the most prominent one being that they support Visual Studio 2017, the latest version of Visual Studio. And even some of the kind of newer out there features of Visual Studio 2017, like the open folder and CMake support, RootSharper C++ is already supporting that in their product, which is

nice to see. And you can see a normalization of their features with CLion also, supporting some of the C++17 nested namespaces kind of thing. Now, Bjarne, since we have you on the show and we have this news article in front of us,

I'm kind of wondering what type of IDE preference do you have? Are you using something like CLion or Visual Studio or do you use something like Emacs and Vim? I'm not really an IDE aficionado. I tend to be going fairly light on sort of tools. I use whatever editor is available on a system. So if I'm on a Linux, I'll probably use VI or Vim or something like that. Roughly, people say Vim or VI or Emacs, and I hate both. So you can get along with whatever there is there.

I sort of like Visual Studio when I'm on a Windows machine. Trying Sea Lion is on my infinite list of things to do because I've heard good things about it, but I haven't gotten around to it. And even if I did have, I'm probably not the person to ask about such things because I'm not a heavy enough user and I'm using too many different systems to be really expert in one system, not on every system. the sort of simple programming stuff, looking to see if they're going to use the core guidelines. I hope they will soon.

And that would make it very attractive to me. Yeah, I know Visual Studio has done a lot of integration with the core guidelines. I'm not sure if any other IDEs have made that step. I don't know either. But I'm hoping to see that kind of stuff spread. I mean, the core guidelines is being done collaboratively across the world, so it can go into any IDE or any tool chain that you like.

We've been very careful not to make it married to a particular organization. I have noticed that the Clang static analysis tools has some core guidelines implementations also. Yep, they have a little bit. I hope they'll soon get more. Okay, well, Bjarne, you talked before about how the ink on C++17 isn't yet dry, but it is basically done in the committee, and they're starting to move on to C++20.

What are your thoughts on what some of the most important things to get approved for C++20 are? Yeah, I mean, I don't expect any significant changes to C++17 between now and getting the official version out of Geneva. They're doing the last little proofreading of everything. The committee that are looking at those details are almost done. And so Geneva will take its time and we'll get the standard. For C++20, my wishes are roughly for the major features I'd hoped for for 17, concept, modules, maybe contracts, networking, and not too much else. Because I think the committee is into doing too many little things and too few major things.

And we need to deliver what we have sort of promised and what we have talked about for years. People are really quite interested in seeing modules and concepts and they're waiting for them and if we don't deliver soon they'll be disappointed. So that's my main thing. I wonder about reflection but it doesn't seem to be gelling quite as fast as I would have hoped.

So, I'm not even putting that on the 20 list. Concepts, modules, contracts would make specification of larger pieces of software much better, to deal with and networking has been production used for more than a decade it's time to to put it in and i would like some more some more concurrency support stuff but i don't want to be specific about that because that moves with its sort of own logic and you can't just pick individual features the point is that things has to fit together and that's very important in concurrency so looking for something there but i won't say what it is People who are doing it will have a much better idea of sequencing or features, what comes first and what comes later. Well, the features you're listing would be great if they

made it in for C++20. Like you said, I think everyone would be very happy if we got modules and concepts and networking too. Yeah. And one thing that's really important, and I think we have not been doing quite as well as we should, it's to have a direction for the language and the library and having the community know that direction so that we can get a coherent set of features that will work together. I do fear the individual little features that come in because, well, they look nice, but they don't interact with the rest of the language.

They're just sort of isolated. And we have now a little group that's charged with looking into direction issues. But having a group of people, 200, 300, 400 people taking part in the Standards Committee and 110, 120 turning up at the meetings, it is really hard to get a consistent and coherent design and a definite direction with that many people. We're sort of overwhelmed with our own success, I would say. If there had been half as many people, we would get more work done. You could argue that the work we got done would not be quite as good, but you know, then we could fix it.

So of all the wish lists that you had for C++20, we've talked about networking on this show and concepts and modules, but contracts I don't think have been brought up yet, Rob. Would you mind going over that a little bit, Bjarne? Yes. Basically, with concepts, you get sort of control over the type system, and you can say what types you will accept into a generic function. Contracts is sort of similar but for runtime properties. So you can say that a number has to be within a certain

range or that a pointer has to be not zero and there's all kinds of things you can say. There's a proposal written by a whole bunch of people, including people from Bloomberg who Facebook coming from a different tradition with a lot of background in what they've been doing at Microsoft. And our main editor for writing it is a professor from Madrid, José Daniel García, and he just gave a presentation at ACCU about it,

where it was very well received. Basically, I guess people who haven't seen it before can start thinking about it as asserts on steroids. Okay. You can have something that is not a macro that you can put in your say function definition and you can assert that something should be true and then you have a system that says

whether this is always checked or whether it's never checked and whether it's checked in debug mode or in production mode there's some names for those things they're not important and so you can you can instrument your code like that find bugs early and then important difference from plain certain macros is you can also put them on the interfaces. So if you read a header file and read a specification,

you can actually see the preconditions, postconditions that you would like to put on it. So the stuff that are in the standard now can be put in the code. And that's, again, where I see the similarity to concepts. Things that used to be comments, things that used to be standards text become code so that you can have tools that check it. Concepts is all compile-time type-based. Contracts is all runtime. And, yeah, it's runtime-based. And you can also use that information that's in contracts for optimizers and static analysis.

But to my mind, that's not the primary way to think about it. It's about values and can be done, can be checked at runtime. I mean, if you have to say that a value is larger than 200, unless you can do the whole thing constexpr, you have to wait some more time to figure it out. So does this in any way work with the type system or with, what am I trying to say, overload resolution? Like, could you have different requirements?

No, no, no. It does not interfere with the overload resolution. And the idea is that in a conforming program, you can't tell. A conforming program should never trigger a contract, should never trigger an assertion. And so you can't tell. If you don't have bugs in your program, they look exactly like they are today, as if you had ripped the whole thing out. If you have bugs,

however, you find them sooner. Furthermore, your comments about what your functions assume now become obvious. They become stated. Right.

So your code should get better. So of these features that you're hoping to see in C++20, do you have any feature that you feel is the most important of that list? You know, modules, contracts, concepts, anything? I tend to list them, concepts, modules, and maybe contracts. I think I and the community would be very badly served if concepts and modules weren't there. And they would be very badly served if we got something that was called concepts or called modules but wasn't quite up to what we expected of them. I mean, we need some high-quality stuff in these areas

because we're addressing major issues. There are too much obscure metaprogramming now that can be made much clearer and much simpler with concepts. The code will become much more useful and readable. And compile times are too long. And we need to do something about compile times and code cleanliness. There are just so much messiness because of the old model for compile time. That is, we have to rely on the ODR to make sure things are consistent across files. And that's really a mess.

I discussed that with Dennis Ritchie, and we both agreed that this was a hack that we would rather not have had to deal with, but we didn't know how to do any better. Today, we know how to do any better. Today we know how to do it better. In particular, the stuff that Gabby DesRais is doing over at Microsoft is very promising. Well, truth in advertising here, it's based on something that Gabby and I did when we were both professors in Texas called the IPR, which is probably the smallest and fastest representation of C++ anybody has ever seen. We're trying to make it provably minimal.

The minimal number of interactions, the minimal number of data stored, all that kind of stuff. And that's what's used to describe a module inside its implementation. So I have high hopes. We will see where it gets us in the standards committee and in the data we get for hopefully vastly improved compiled speeds. I'm an optimist. I'm hoping for many factors, not fiddling around with percents or tens of percents.

Vastly improved compiled speeds would definitely be welcomed. Yeah, and also we will hopefully get rid of all of these strange bugs that comes out of macros that we didn't know existed. Right. So thinking back on the history of C++ now, since you mentioned these ODR kind of problems that we have and stuff, is there any, like if you could go back in time and change anything in the history of C++, any decision that was made earlier, do you have anything that you would change? This is the time machine question. I don't have a time machine, and it's really hard to outguess the people who were there, because they knew what was feasible at the time better than we know now. I don't think I could have done anything with modules. Not that we didn't know how to do modules and such.

Anders Heilsberg did a nice job in Delphi and such with that. But in the C, C++, Unix world, the C compilation model was just too ingrained. And we'll see if we can handle it now. I think we can. I think we can provide such great improvements that people will change. And they will have to change because you don't get the benefits of modules if you insist all your old code has to compile unchanged. If you have to handle all the mess, you're going to be roughly as slow as the stuff that currently handles messes. Our compilers are really great. They're very fast. They just have to deal with an awful model and an awful lot of data.

So what could have been done at the time? I think the major features are probably all right. And every major feature you could find half a dozen things you would like to do a little bit better in retrospect. But you don't get the second chance. So they're there. The one thing I have been wondering about has been concepts. I mean, I know that back then, 88 plus minus a few years, I was trying to solve that problem. I knew it was a problem that needed to be solved, and I just couldn't do it. I wanted full generality.

I wanted performance with a zero overhead principle, and I wanted good interfaces. I mean, remember, I was the one who put function prototypes into C. I know the value of interfaces. And I just couldn't get it. I couldn't get all three. And nobody else at the time could. If they could, I'd never heard of it, even now, so many years later. And I think if somebody has had the time machine and gone back and explained the very simple model that's currently

cost currently module sorry that's that's currently concepts I think I could have understood it and I would have implemented it it's easier to implement than the current fully general, fully generic stuff. And a lot of the sort of workarounds we had to invent and complications on templates could have been avoided. I mean, they're simply compile time predicates. That's all they are. It's not that complicated.

So I think I could have understood the solution. I know I understood the problem. And I think the implementation would have been feasible at the time. Remember, at the time, we're still wondering about whether we could get two megahertz of a processor and certainly two megabytes were a lot of memory. But I still think I could have done it. But you need that time machine because people didn't figure this out until a decade later or more.

I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state. Bactrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption,

malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io.cppcast. You have some proposals like the uniform call syntax. Are you still working on those and hoping they will make it into C++20?

The uniform call syntax I still think is a really excellent idea and would simplify a lot of things. I mean, as late as yesterday, I saw on the reflector a request for getting another function that's a member function out as a freestanding function. Basically, once you get concepts, and even if you don't get concepts, once you formalize the requirements of a template, you have to make a decision. Do you require member functions or do you require freestanding functions of your users? And when you are a user of a library, you have to look at the library. Did he decide that I should write my types with freestanding functions or with member functions? And so for libraries to use all types, they have to do both, which they rarely do.

And for users to use both kind of libraries, they have to write both freestanding and member function versions of the same thing. And by and large, they don't. And so you don't get the pluggability that you want. This is an example of how features actually should work in combination. Concepts works better if you have unified function cores, and it saves you a lot of writing functions. But people were very, very nervous because then how do you limit the set of functions to be considered in overloads and such? And my answer is namespaces, but I couldn't sell it to the committee.

In the committee, a significant minority can stop anything. There was discussions that modules might help, and if I can find something that can demonstrate that that conjecture was correct, then I will try again. But it depends on whether the problem has been simplified in the future modules in particular. The other thing is that some of the fear of overloading and hijacking and that kind of stuff decreases when your templates get constrained because the main problems with ATL and such comes out of unconstrained templates.

So this thing about having coherency and a matched set of functions is very important. And so I'm still thinking about unified function core. But it's not at the top of my list just now. I want to see how modules work out. The cleaner the modules come in, the greater chance we have for getting unified function calls. And that means that we can write concepts that are much simpler. This unified function call syntax reminds me that I was just working with the standard regex library and was iterating over sub-expression matches

and realized that the, I think it's the sub-match class, it has begin and end, but does not have the global begin and end free function overloads available. So I'm writing in a style that I'm used to programming in, and then all of a sudden I'm getting a compile error that I don't expect to see there because I can't call standard begin on it. Yep. Consistency is good.

And we try to simplify the job for the user. At least I do. And so I have the slogan of keeping simple things simple and having to remember whether something is a member function or a freestanding function can be a bit of a nuisance especially when people make their decisions from the strangest of reasons I have some rules of thumb that I use but they're different from other people's rules of thumb. So a naive user gets caught.

We can do better. Jason, do you want to ask about multi-methods? Yeah, sure. There's been a few talks that I've been in where I've seen your proposal for multi-methods come up, but I have not personally seen it come up in any of the discussion about any of the standards meetings in the last few years. I was just wondering if that's also still something that you're pursuing. It was an experiment. I particularly wanted to get rid of the visitor pattern, which I think is a horrible hack.

It is unfortunately necessary because you cannot have freestanding virtual functions. So let's have freestanding virtual functions and I don't have to go in and doctor a class or define a visitor to be able to traverse a hierarchy. And so we designed this, we implemented it, we figured out how it would work in so that it was uniform with the overload resolution things, wrote the paper, implemented it, did a few experiments, shows that it was faster than multiple dispatch and such. And that was as far as we got. Now, I have sort of this view that we should work on the top 10 features for the next standard. We should look at the top 20 maybe. And we should try and restrict ourselves to a set so that we can deliver what we are promising and we don't look as if we are

promising more than we can deliver. And the multi-methods basically never made it to the top 20. There are some implementation implications that are not that easy to deal with. They require linker support. And not enough people seem to be sufficiently interesting to make progress. So it didn't make it on my sort of top 10, top 20 list. It would probably be at the bottom of the top 20 list if I had it,

but I usually talk about top 10 and top 12. And other things always came in above it, so it never moved. If somebody wants open multi-methods, they can have them. There's a very good design. There was a very good prototype that worked. Whether it still works, I don't know. But all the basic sort of researchy kind of stuff has been done. But somebody has to push it, and I have a list here in front of me,

and it's not on it. I can't do that one also. One of the problems with the committee is that it can't focus because we're so many people and I'm trying at least personally to focus. So not everything that I would like to see is on my list of suggestions of what we should do now. Okay. As far as, you know, the focus of the committee, I was wondering what your thoughts were on the TSs that, you know, modules and concepts have been a part of. Do you agree with that way of handling some of those bigger new features in the committee?

I think that TSS seems to have worked reasonably in some library cases. But for language features, I feel they've become a barrier. They've become yet another way of delaying things. You can argue about getting it into a TS. Then you can argue about, sorry, the working paper for what should become a TS. Then you can argue whether that should become a TS. Then you can argue that you should change the TS. Then you can argue that the TS hasn't been around for long enough and you shouldn't put it in the working paper. Then you can argue about when it's in the working paper, and then you finally can argue whether it should be in the standard.

It just gives too many opportunities for people to come up with objections and alternative designs and creating uncertainty in the community about which way is going and what's happening and when. I'm not all that happy with TSS just now, especially not for language features. I think we should sort of put things in, integrate early, see what happens, and sometimes we'll have to back out again. But once things are in the working paper, for instance, the library guys can start using the feature and see if it really works. There's far too many people that won't touch something until they're in the working paper. They even ignore TSs.

And then there's people that don't want to touch anything that isn't a TS. And then they think that a TS, once it's a TS, it can't change. You ask two people what it means for something to be in a TS and you get three different explanations. I worry. Maybe I worry too much because on average we do deliver good stuff. But maybe it's my job to worry yeah that's probably true is uh which brings up another question i had is there's you see a lot of students particularly that think i want to make my own programming language and I was curious if you have any advice for these young language designers,

aspiring language designers. I guess my first advice would be don't. Because if you fail, you feel miserable. And if you succeed, you're in for 20 years of hard manual labor, meaning you have to labor on the manual. The next

and more realistic advice, because nobody listens to the first one, is, what's the problem you're trying to solve? All the languages that succeeded were designed to solve some kind of problem for somebody.

And most people want to build a programming language, want to build it because they're cool or because they think they can do slightly better than some other language. Those languages never succeed. Maybe if you're a big corporation like, say, Sun and spends a few hundred million dollars promoting it, you can get something out there. But the average person wants to write a language that makes it easier to write a video game. They don't know what the problem is they're trying to solve. And so the second question after don't, the second suggestion after don't is, what's the problem?

And why can you solve it better than existing languages? And why won't an existing language just turn around and write a library that does it as good as you're doing it so that what you did never gets used? So then what? Sorry to be negative, but I'm trying to help, actually. I'm trying to make sure that people don't waste a lot of time and energy and get disappointments. The success rate for programming languages is very low. The success rate for programming languages that are general purpose

without any particular problem to solve is even lower. So find a good problem, solve it somehow. A language might be a solution, but it usually isn't. That makes me then wonder, what is the unique problem that C++ solved that led to its success? Machines were getting bigger, and there was two kinds of languages at the time. There was languages that could manipulate hardware really well. C is a prime example that survived until today. And there was languages that could do abstraction, higher level organizational programs quite well.

Simula was a good example of that and the object-oriented languages that came after it. And there wasn't a language that could do both. And I needed, for a specific problem, I needed a language that could do both. And since there wasn't one, I had an excuse for building one. And I didn't actually look to build a language I was looking for a tool to help me solve another problem which had to do with how to write a multiprocessor or a cluster and then it became useful and my friends and colleagues started using it and I got distracted from the original problem. Never got to write that one. But

the position of C++ and the one it still has today is that if you need to manipulate hardware, if you need performance in a way that relates to hardware, it's a good language. And if you need a high level

abstraction, it's a good language. And if you need a high-level abstraction, it's a good language for that. And the cost factors are such that you can afford to do the abstraction over the hardware at a reasonable cost. The serial overhead principle has been one of the most useful guides to C++'s evolution. But the two-line or two-slide version of C++ is hardware plus abstraction. So how many years did you work on C++ before it became a success and you would say a significant number of people were using it?

This was rather crazy. Since I wasn't really aiming to build a language, I had my first user after six months. Okay. It came up to between 200 and 500 users, at which time I realized I did have a general-purpose programming language on my hands, and I had to do something. And I thought I had two choices. I could drop it because I knew the success rate for languages, so that's a sensible thing. But then I'm leaving my friends in the soup. Can't do that. Or I must make it a bigger success so that we can afford a support organization.

And I estimated that if I could get 5,000 users instead of 400 or thereabouts, then I wouldn't have to do all the maintenance myself. So I improved the language a bit so that we could increase the user population by a factor of 10. And I overshot the target. But that's what happened. And so there was a commercial release about five years after I started. And at that point, we had a few hundred university users that just had a license. And that was with AT&T at the time? It was Bell Labs, yes.

Bell Labs was a truly amazing place with a truly amazing bunch of people and all of that. And to succeed at Bell Labs, well, if you could succeed there, you could succeed in other places as C++ and C and Unix proved. If you're good enough for the old Bell Labs, you're good enough for lots of people. So I think we have one more back-in-time question. One of our guests recently suggested that if C++ had references at the very beginning of the language that maybe this would have been

a reference instead of a pointer. I was wondering what your thoughts were on that. I think he's right. References came a little bit later because I couldn't do overloading correctly without them. There's one thing I should say that for this to be a reference, I would also have had to go from the early primitive version of how constructors were implemented, where that relied on this was a point as you get tested for zero and such, to the modern one we have today. And then this could have been a reference.

Okay, very cool. Jason, do you have any other questions? I don't think so. Okay. Well, Bjarne, it's been great having you on the show. Thank you so much for making time for us today. Sure. Thanks. It was fun. Bye. Thank you. Thank you. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com.

I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.