An Interview With C++ Creator Bjarne Stroustrup

Introduction

We had a great talk with Bjarne Stroustrup, the designer and original implementer of C++. He is also the author of The C++ Programming Language (Fourth Edition), A Tour of C++ (Second edition), Programming: Principles and Practice Using C++ (Second Edition), and many popular academic publications.

Enjoy the full interview below!

The Interview

Evrone: You’ve created one of the most efficient and fastest programming languages. No doubt, that has changed our world. Have you, as a person, changed while working on it?

Bjarne: Interesting question! Not one I have thought much about. I guess an answer will have to distinguish between properties that have remained constant and those that have changed immensely.

My interest in broad issues, including history and philosophy, has been constant from quite early on and I think it has been significant for the development of C++. I said so in D&E in 1994. Similarly, my desire to build things more that digging deep into academic pursuits has given an engineering bias to my work. I value performance, low cost, and reliability. That, combined with an emphasis on feedback, evolutionary progress, and appreciation of real-world problems, shaped C++.

One aspect of my work that has steadily increased over the years is education. As I tried to explain my ideas, I realized that you can’t just build something, you must teach people to use it well. That has always been a problem for C++. Often, my message was drowned by people with a simpler vision and a willingness to make larger claims. “We can’t teach teachers fast enough” was my common complaint in the 1980s and 1990s, so C++ was often taught in ways I thought were horrendous. No wonder some people got a very negative view of C++!

Had I known I’d spend much of my life speaking and writing English, I’d probably have paid more attention in my English (foreign language) classes. My travels gave me a lot of insight in a huge variety of problems and the range of problems you had to face to solve them. Many of the most difficult problems were organizational, management-related, and educational. In that, my reading of broader topics helped more than my technical education. I learned that a high degree of humility is needed for good language design. There is so much we don’t understand, the world changes constantly, our problems change constantly, and we change.

Evrone: Business environment requires respect for strong deadlines while implementing new features. How can developers keep balance between the code quality and the speed of development?

Bjarne: That is so dependent on the management structure and the technical culture. My personal opinion – developed primarily at Bell Labs – the ideal is that you hire the best people, and enough of them, so that you don’t have to have them all work on the next deadline. Some key people have to plan for the future, experiment, and build the first version of the next significant system, and maybe the next after that. I see a good organization building a steady stream of products, most of which will be evolutionary changes from products already deployed and requiring maintenance and upgrades. Clearly, this doesn’t match the common ideas of cost cutting and/or delivering a revolutionary system next year.

Evrone: There is a widespread opinion nowadays that using modern frameworks is more important than applying math knowledge. Could you give any advice to young programmers regarding this?

Bjarne: Time spent on math is never, well, rarely, wasted. Math is one of the best ways to train our brains, especially when combined with computing so that our mistakes become obvious pretty soon. Math teaches us to be accurate and not to believe in oversimplified or simply false ideas.

There are areas where math is essential, such as scientific computing, some forms of graphics, and much of the financial software, but for most people the key areas of math is probability and statistics. Is your code fast enough? Will it scale? What are the likely events, and their implications?

Of course, many applications don’t require math. However, if you build infrastructure or if you deploy an application at scale, capacity and energy costs enter the picture and mathematical naivety can cause harm.

Evrone: The powerful C++ meta-programming system is sometimes abused by developers who try to move as much as possible from runtime to compilation time. Is this a viable approach from your perspective?

Bjarne: Every new and powerful feature or technique will be overused and misused. I see no way around it. Our enthusiasm always runs away with us, so eventually we must learn to use our tools better and pull back a bit. The good thing is that the overuse teaches us a lot about the weaknesses so that we can remedy them. For example, template metaprogramming was so useful that many reasonable people were willing to ignore its ugliness and appalling error messages. Then, we learned enough to compensate with compiler-time evaluated functions (constexpr and consteval) and concepts, so as to dramatically simplify much of what people were writing.

Evrone: With the arrival of the AlphaCode neural network from DeepMind, there are more and more statements in the press that such neural networks will soon replace programmers. Do you think there are real prerequisites for this?

Bjarne: I don’t really know. I doubt that AI will replace programmers in the kind of programming that I care most about. Serious reliability and close-to-optimal performance are not very amenable to be standardized and averaged. When I hear about AI, which is not one of my strengths, I remind myself that TensorFlow and similar libraries are C++, so that means that I have done my bit – for good and bad.

Evrone: Sometimes we, as developers, can't find a proper solution for a programming task at hand. Have you experienced such situations, and could you share any recommendations on how to deal with them?

Bjarne: Of course! Nobody trying to do something novel or significant hasn’t spent hours, days, or longer being stuck and feeling awful and frustrated.

You always try to look logically at the problem to understand it. Measure, if there is anything that you can measure to get feedback. Think hard about what you are trying to do: maybe you are not doing it or maybe the requirements you have come up with are not reasonable. Occasionally, take a break and think of something else. If I can, I go for a run. Then, often, some useful ideas pop into my head as I’m relaxing.

Evrone: There is an (in)famous joke that any architecture problem can be solved by introducing a new layer of abstraction. Except for the problem of too many abstraction layers. A lot of C++ code we saw had an exceeding number of abstractions. Any advice from the language author on how to keep abstractions count at bay?

Bjarne: That’s David Wheeler’s “First law of computing”. I appreciate that you remember the second half – many people forget that, yet it is essential. David Wheeler was my thesis advisor. He was a wonderful person, and I learned a lot from him.

That “joke” reflects reality, probably more today than when David made it. People keep hiding the real work behind multiple levels of interfaces involving indirections. That can cost a magnitude or two in size and/or run-time. Much of modern C++ exists to allow people to have decent interfaces that a compiler can collapse into simple machine code without redundant indirections.

Evrone: In the past ten years we saw lots of syntax sugar added to the mainstream languages. What do you think about this trend of bloating syntax to provide a somewhat better tooling for experienced developers?

Bjarne: “Bloating syntax” is fine as long as it simplifies the lives of programmers. I tend to refer to it as “Make simple tasks simple.” I think the key idea is to enable a programmer to express fundamental ideas directly in code. For example, there is no virtue or benefit expressing a simple loop over a container in terms of a C-style loop. Better use a range-for or an algorithm. Those directly express the intent in most cases. Leave the detailed fiddling with loop variables to the unusual cases, such as visiting every second element of a container. The more direct expression of ideas is easier to write, easier to read, easier to maintain, and often more amenable to optimization that you need to run faster.

I do not believe that “there should be just one way to says things” is an adequate ideal. If you go that way, some things become very hard to express and others can be expressed only by saying far too much. Also, over the years and decades changes are needed, which naturally leads to language changes. In those respects, programming languages are not all that different from natural languages.

Evrone: Many people think of you as their mentor. Could you share your vision — what qualities should a good mentor have, for example, inside of the company/team?

Bjarne: A willingness to listen and to be serious about understanding the problem. Then, a degree of humility when it comes to giving advice – often, our understanding is incomplete. That said, a good Mentor must give concrete advice, not just general vague twaddle. If someone honors you with a serious question, it deserves a serious answer that helps the questioner to move forward. Giving advice is hard.

Good questions teach you a lot. They are a major source of progress. A good Mentor learns a lot from students.

Evrone: Could you spoil any upcoming language changes that you think are worth adding to the future C++ versions?

Bjarne: First, the community has to get used to the new, powerful, and simplified features of C++20. C++20 is an improvement on the order of that of C++11. Here, I will just mention just two language features. There are more, and of course standard library components.

• Modules: Finally, we can say import Mod to gain access to the interfaces exported by module Mod, and nothing else. This gives far better code hygiene than #including headers that leak implementation details and macros. Modules can also be dramatically faster to compile. For example, I compiled a simple use of import std ten times faster than #import<iostream> even though std holds all of the standard library and <iostream> less than 10% of that. Module std is currently experimental but has been voted to be put into C++23.
• Concepts: Before C++20, all templates were unconstrained; that is, they didn’t define an interface that people and tools could look at to determine the template’s requirements on its arguments. For example, template<typename Iter> for a template that needs an iterator type. Now we can define such requirements, called concepts, and use them: template<random_access_iterator Iter>. Such constrained template arguments have always been the ideal; I just didn’t know how to implement that idea without restricting flexibility or imposing runtime overheads. Now we can check template uses immediately, we can get much improved error-messages when we make mistakes, we can overload function templates, and even improve performance in places.

You can find much more detailed information on the web; for example, look for coroutines, ranges, calendars, time zones, formatting, span, and compiler time vector and string. The C++20 features are shipping in the

Now I can come back to your question: What about future versions? Much have been delayed by the pandemic. Many of us would have liked to see some significant projects finished for C++23, but that’s not happening for my favorites. Here, I will mention just three:

• Static reflection: we need a mechanism to generate code at compile-time based on the types in the program. That would give us almost the flexibility of run-time reflection without the cost in time or space. For example, it should be very simple to generate an optimal optimized Jason reader for a fixed set of types. Significant work has been done on this.

• Pattern matching: The ability to select an action based on how an expression matches a set of type or value alternatives is one of the most convenient ways of expressing alternative actions in many functional programming languages. We can do the same for C++ and in the process make the archaic switch-statement redundant. We have a pretty complete design with an experimental implementation, so I have hope for C++26.

• Concurrency model: We have been working on a general model for concurrency for years, but we keep finding use cases that don’t obviously fit, so we have had to postpone. I have hope for C++26. Please remember that it is not individual features that make programming convenient, safe, and efficient. We need a dense network of features that work in combination in the type system. Also, we can’t break the billions of existing lines of C++: compatibility and stability over decades are very importance features.

  
  

Also published as The interviewer is the Chief Editor at