Home > Articles > Programming > C/C++

Bjarne Stroustrup and Herb Sutter on the Future of C++: Part 2: Video Podcast Transcript

  • Print
  • + Share This
In this transcription of an OnSoftware session, Bjarne Stroustrup, Herb Sutter, and Ted Neward discuss templates in C++0x, how they relate to functional programming, and Stroustrup's chagrin over 20 years of 'very old news.'
Like this article? We recommend

Welcome to OnSoftware—conversations with thought leaders in software development. In this session, Bjarne Stroustrup, Herb Sutter, and Ted Neward continue discussing forthcoming features and core language changes in C++0x.

Ted Neward: So you mentioned concepts, you mentioned Lambdas—these are full closures, capturing variables off the stack as well, and so forth.

Bjarne Stroustrup: Yes. Yes.

Herb Sutter: Functions or function objects on the fly in the line, without having to go off somewhere else and define a class.

Ted: Okay.

Herb: Every popular language is doing it these days. It’s an indoor sport.

Ted: That tells you—you know, if Java is talking about closures, it must be past due for all the languages that are really hip. And that raises another question....

Bjarne: Actually, before we get into the really hip—one of the major things about the next standard is that it doesn’t break the old code.

Herb: Mm-hm.

Ted: Which is good.

Bjarne: I mean, we need to be stable. So we get all the new stuff, it is cool, but we’ve maintained the performance, we maintain the hardware access, and we don’t break your code if we can at all help it.

Ted: In C++—I’m trying to remember the forward from Design and Implementation—C++ sort of hit the streets, so to speak, in, what, the mid-’80s?

Bjarne: First commercial release was in the fall of ’85.

Ted: Yeah. And so we’re looking at, what is that—23 years now?

Bjarne: Something like that.

Ted: Wow, your jubilee is coming up.

Bjarne: It’s a long time—and, you know, some of the early code still runs.

Ted: Yeah. Yeah. Let’s see where other not-to-be-named languages are in 25 years. [Laughs.] So, one of the things that certainly emerged, particularly in the last year, it seems, has been a rise of interest in the functional language space. And somebody—I wish I could remember who said this so I could attribute it properly—somebody suggested that C++ templates were functional in nature. That really threw me for a loop, and I wasn’t quite sure what to make of that, so I figured [gestures to Stroustrup and Sutter].

Herb: You said that before we started, and that surprised me, too. Bjarne said he’d heard that and agrees, so I’m curious, too.

Bjarne: I do agree. The inspiration for a lot of the STL is functional programming, and if you look about—sort of, you go through data structures, you apply operations to it, you combine algorithms, you work generically or different data types. All of that is functional in inspiration. Most of the type work is done at compile time in C++, but what runs at runtime is a lot like that. Function objects can emulate certain forms of higher-order functions, and some of the early work with the STL was done in Scheme and Ada. Now, one thing that is different, and that’s the one thing you latched onto [gesturing to Sutter], is that functional programming usually goes with lack of state, or—

Herb: Mutable state.

Bjarne: —mutable state and such, and that’s not what we’re dealing with. We’re not trying to turn C++ into a functional language; we’re trying to see what parts of functional programming techniques can fit in with object-oriented programming, and things like that.

Herb: Now I grok what you were saying about the "functional." Let me try to restate the same thing, maybe from a different perspective. There’s really two different things going on. Usually, when you say, "A language is like this," it’s like you’re talking about the kind of code you write every day, the classes and functions and everything. C++ templates are nothing like functional in that sense; however, to the extent that templates get specialized, use other templates, there’s this whole system that gets evaluated at compile time, which is very functional in nature. Templates and template meta-programming, the people who’ve gone down that road, are doing something that is much closer to LISP than it is to C, for example.

Ted: Well, certainly a number of the functional languages support this notion of type inferencing, which some of the template expansion—is that the right term?

Bjarne: Template instantiation in C++ is join-complete, and in some ways equivalent to ML type inference—different, but with the same expressive power inside what you can do conveniently. Very different, but with the same kind of deductive mechanisms. And some of the new features—variatic templates, ability to create tuples, manipulate tuples—will be more familiar to functional programmers than to C programmers, say. So we’re trying sort of cautiously to see where the things can work together, where we have things that actually work, perform, fit into the type system. We’re not going whole-hog functional, and we’re not trying to graft something alien in that doesn’t work. A language is more than the sum of its individual parts; it’s in the combinations you get the strength.

Ted: See, now, this has me all curious. Could you do—and maybe you’ve already thought about this—could you do currying in C++ using templates?

Bjarne: Yes, we can; it’s one of the new features. It wasn’t in C++ 98. You can do currying of type arguments, yes.

Herb: But I really want to come back to where this is.

Bjarne: Yeah, people might not recognize the syntax and such; they’ll say, "Oh, but we can do all of these things. We can do everything." In C++, you can do some of the things—what can be done type-safe, statically.

Herb: But I really want to make sure that people who are listening to this understand that this is not the usual question about, "Will languages for concurrency and multicore, for example, become more functional?" This is a very different style of question, because you’re talking about the C++ template and type system, which is all at compile time. There are direct parallels there.

But when people talk about what functional language is, and multicore and concurrency, they’re talking mostly about the idea of, "When I write my code (among other things), first, everything is an expression, so I can evaluate subexpressions in parallel, so I get automatic concurrency just in the nature of the way I’ve expressed the program." That’s the one thing they would like. The drawback there is, today, it’s too fine-grained. Because the overhead of doing something concurrent, you want to ship it off to be done somewhere else, you want it to be of a certain size: "You must be this big to be worth the overhead of shipping somewhere." We’re driving that overhead down. But today, that’s too fine-grained for most applications of exploiting that.

But the other area that functional languages are great at (the pure ones) is immutable state. You copy, you modify a vector, one element in it, we just got a whole new vector with that one element change, which is great. And immutable, you need no locking, it’s wonderful—except that there are pure functional languages like that, and then there are functional languages that people actually use, for commercial code. Because you just aren’t going to copy every—

Ted: [Laughs.] You just earned a hate mail from somebody on that line.

Herb: I know! But the reality is that everybody has to make exceptions, because, for efficiency, you’re just not going to copy a million-element vector every time you change an element, so there’s always a compromise. Immutability is great, but there needs to be that balance. The one thing you see coming from functional languages that are coming into all languages are Lambdas and closures. C#, anonymous delegates; Java is working on it; and, as you know, C++0x.

Bjarne: I’d just like to add to this: The functional program community has owned a huge chunk of the educational establishment for 30 years. They have explained to generations of programmers why it was wonderful and has never gotten traction in industry. So, from my perspective, there’s lots I like, but I’m not going to bet everything on being able to go functional, because lots of people (probably smarter than me) have done that and failed.

Ted: Right.

Bjarne: We’re trying to adopt what can’t fit with other things. This is why I sort of talk about multi-paradigm programming, trying to figure out how to combine traditional C styles with object-oriented programming and generic programming; finding a sort of (if you’ll excuse me) "sweet spot" in the space, where you can do a lot of things—where you can do it with greater safety, easier writing, and still good performance. It’s tricky.

Herb: One thing about multi-paradigm development, C++ has always been big on that.

Ted: Jim Coplien wrote a book about it, if I remember.

Herb: He has, yes. And there he mentions it well and frequently, because you have your C cell-structured programming, you have object-oriented programming in the classic virtual-function dynamic polymorphism sense, you have type generosity of compile time, C++ templates—those are three big ones. But, to make them orthogonal and composeable—as soon as you say "multi-paradigm," I can apply whichever of those make sense to this part of the problem and combine them together. I can have a templated class with virtual functions and inherit from it. And people do this and it works. That is very hard. Because any time you want to make two things orthogonal, you want to make them at right angles so they don’t cast a shadow. If they’re wobbly, if you build a house that’s not square, then the roof will start having problems and cracks will appear. So working on the interactions has always been a big thing that I think C++ has done very well, so that you can in fact use these things together and actually have them interoperate, not just have three different silos that you can’t talk across.

Bjarne: I mean, people use generic algorithms on data types that turned out to be class hierarchies with virtual functions. They can fit together, and it’s not brain surgery.

Ted: Let me ask you this question real quick—and we’ll wrap up with this because, wow, the time just went like mad. Recently, at a language .NET seminar in Redmond, Anders [Hejlsberg] was in front of a crowd of mixed Microsoft and a large number of non-Microsoft folks (including Sun, some independents, and so forth). Anders said what I thought was a very, very interesting statement. He said that he believes that we are quickly approaching a point where the traditional taxonomies of languages are breaking down. Where you don’t have a language that is just object-oriented any more, or just functional, or just procedural—that we’re very quickly approaching a point where languages are just languages, and borrow from each of these historically separate categories. Talking about C++ as a multi-paradigm language, does this kind of resonate?

[Stroustrup sighs.]

Herb: You probably saw him [points to Stroustrup], because C++ has been there for 20 years.

Bjarne: I wrote a paper in 1980 explaining why you needed object-oriented techniques, inherits and encapsulations, and how you needed to have parameterization to deal with containers and algorithms on containers. I got the mechanism for that parameterization seriously wrong, but the point is that within a year of starting C++, I was talking about inheritance, parameterization (that’s parametric polymorphism and generic programming), and combining it with traditional systems programming. This is very old news.

Herb: But, having said that, Anders is making a very good point—that this is becoming more and more broadly recognized, more and more mainstream. And that’s why, for example, you see exactly the thing that I mentioned earlier, about many languages adopting Lambda functions and closures. Because you look at that, and you think, "Oh, that’s a really super-functional thing." Well, it is a part of the functional language that you don’t necessarily need to be in a functional language where everything is an expression for it to make sense. It makes sense in imperative languages. For concurrency, it makes great sense to talk about a piece of code that you pass around as a first-class thing. And, really, you know we talk about it in such an abstract way, it’s a shorthand for writing a function object. It’s a shorthand for writing a function, conveniently, locally—but, boy, what a difference it makes. The Java community has seen that, in its use of those things, and the C# community as well.

Ted: That’s one of the things a lot of Java programmers remark on, when they pick up a language like Python or Ruby that has that: "Oh, my gosh, this makes so much sense, to go collection.each.[block of code]. Oh, this is amazing! We should have that."

Herb: But let me point out, when you say exactly that—

Bjarne: Smalltalk had it in the dark ages! Again, a lot of this stuff goes way back. We’ve gone through periods where people have had all kinds of what I thought silly wars, and denouncing languages that didn’t look exactly like they expect. There’s hybrids, and—

Ted: Right. You didn’t have semicolons and curly braces; therefore, you suck.

Bjarne: Oh, it’s so silly.

Herb: What he said. [Laughs.]

Ted: Gentlemen—wow, as always, the time flew. I enjoyed myself most immensely. I hope you enjoyed yourselves.

Bjarne: Time flew.

Herb: Good to see you each year.

Ted: Yeah. We’ll have to do this again, same time, next year. I think they should do a movie or a play about this.

Bjarne: Something like that. Good idea, good idea.

Ted: Take care, and enjoy the rest of the conference.

Herb: Thank you. You, too.

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

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020