Home > Articles > Programming > C/C++

High-Performance Applications with C++: Video Podcast Transcript

  • Print
  • + Share This
In this transcription of an OnSoftware session, Bjarne Stroustrup and Herb Sutter talk with Ted Neward about the measure of a quality programming language, the importance of planning for interactions, and how to create something when you can't even imagine it.
Like this article? We recommend

Welcome to OnSoftware—conversations with thought leaders in software development. In this session, Bjarne Stroustrup (the creator of C++) and author Herb Sutter discuss C++ and other important applications.

Ted Neward: [Bjarne, you mentioned in a previous session that] your original work was in the space of concurrency. I know you've said that when you first sat down to create C with Classes, which was the original name for this thing we now call C++, a lot of it was based off of work you'd seen in Simula and so forth.

Bjarne Stroustrup: Oh, yes.

Ted: When you look back across the—what is it now, 20 years?—since you started that work, I think you said, mid '80s?

Bjarne: Twenty-five, I think. It was late '79 when I started. It's scary. It's scary.

Herb Sutter: Coming up on 30.

Ted: When you look back, it would seem to me to be somewhat surreal to think that you've created this thing that people have been using now for a quarter of a century—I mean, as you look across it, what's your first reaction?

Bjarne: It is surreal. It's somewhat scary, and also gratifying. I've been writing a paper for the ACM History of Programming Languages conference, where I have to look back over the last 15 years. Scary bit is I also wrote the previous one that looked back to the previous 15 years. But of course, then the question comes in, how do you measure success of a language? What is it you consider successful? Most people [think], "Oh, look at this beautiful language feature," or something like that. I think that's fundamentally wrong. You measure the quality of a programming language in the applications developed in it. I look back and say, "What has been done with this?" The basic code for the Human Genome Project was C++. The scene analysis in the autonomous driving system in the Mars Rover is C++. The search engines of Google and Amazon.com. So, my work has indirectly (most often indirectly) affected the world, in mostly positive ways—and that I'm proud of. It's not so scary in retrospect as it was when I knew some of these things were being attempted, and people were scaling my work several orders of magnitude bigger than any individual could handle in his or her own mind. So, yeah. A lot of good stuff was done with it, a lot of good stuff is being done with it. For all I know, the camera that takes the pictures throughout [this] program is C++. It's a very good chance that's true.

Herb: C++ is fairly viral, it's everywhere. Now, I have a question for you, though [pointing to Stroustrup], taking over the interview [looking at Neward].

Ted: By all means, please!

Herb: I once heard a good friend, a programming language designer, say that he never wanted to design a programming language that could only do the things that he could imagine. I think he was you?

Bjarne: Yes, that was me, and it's pretty fundamental. If I build a tool, I want something that's not just good for me now. It's good for me next year and the year after. And it should be good for my friends also and for lots of people. So you can't just build things that close and can do just what you can imagine. You have to have it much more general and much more open. So I've always concentrated on allowing it to express more things, and more general things, rather than trying to pinpoint exactly what's good for people—that kind of paternalistic thinking is outside—

Ted: I remember in The Design and Evolution of C++ you talked about—I forget which feature it was, or which discussion, but it was something to do with type aliases or whatnot—you said that during one of the standards meetings somebody said, "Oh, we can do that with the language facility today and walked up to the whiteboard and demonstrated how you could use a typedef to do exactly what the request was for. I remember specifically you said something to the effect of, "I had never even thought that this was possible, and here somebody was teaching me how to use my own language," which has always just sort of resonated with me—that same sense of, wow! Other people are using this in ways I had never really contemplated before.

Bjarne: It happens regularly, and it's really nice.

Herb: There's a potential pitfall in how to understand what that means, however. On the one hand, you could say that means, well, Bjarne may be a nice guy and fairly smart, but he didn't understand his own language. And so the design had accidental things that you could do that were unintended—that would be completely the wrong takeaway from that. Rather, the key to the approach that Bjarne is taking is to design a programming language with features that are solid in themselves, that work well, but that mesh together well. Anybody can design a programming language with n features. But do they deal with the n2 interactions between those features well? Or do they punt by saying, "Well, you just can't use feature x and y together at all"? Once you design the features so that they work in isolation, they mesh well, then you come up with new meshings and new combinations of those features in threes and in fours, and use them for new tools that nobody could imagine, because that n2, n4 is just too big a number to contemplate of all the interactions that could be. And that's how you generate lots of territory for people to discover and settle and build new cities.

Ted: Right.

Bjarne: So you build things aimed at combination; that is, I try not to design a particular solution to a particular problem. I try to solve and provide a set of general facilities to solve large classes of problems. And then I work on the affordability; that is, if what you are really going to do is use a combination of things, use a library or something like that, the combination has to be efficient enough that you couldn't hand-code or hack it in some lower-level style and lose generality again. So you need not just composability, but you need affordable composability. So, for instance, I'm often asked, "Did you imagine the STL? Or did you imagine the template metaprogramming?" And my answer is of course not, but I worked very, very hard on having a set of facilities that were general, efficient, and composable. And that had a lot of attention to where the type information was flowing around, so that it could be used later, so that optimizers could get their hands on it. And the net effect is that libraries, embedded systems programming, and high-performance numerics that I couldn't have written (because I don't know the application domains) had been written, and had become the backbone of high-performance applications in those areas. Did I imagine it? Well, I imagined people would do something like that, but I don't have sufficient knowledge to imagine the details.

Ted: One other thing, since obviously both of you are very much involved with the C++ standards effort: I think, Herb, you're the "convener"? Is that the right terminology?

Herb: Uh huh, we're both lifers, yeah.

Bjarne: "Convener" means he's the guy in charge of all the paperwork and rules and regulations and interactions with other groups.

Ted: And so, if we don't like the language, it's his fault?

[Stroustrup and Sutter point to each other. All laugh.]

For more information, visit onpodcastweekly.com and subscribe to all our podcasts. Brought to you by the publishing imprints and information portal of Pearson Education.

  • + Share This
  • 🔖 Save To Your Account