Professor Bjarne Stroustrup

Speech Bjarne Stroustrup

Thank you for inviting me to speak at this august event. I’d like to briefly describe some issues related to the design of a programming language.
A language is a living thing. This is true for programming languages as well as for natural languages. As time goes by, new idioms and grammatical forms emerge, new vocabulary enriches the language and older words and usages go out of fashion. An artificial language does not spring fully formed from the mind of a designer and then never change. If anything, programming languages evolve faster than natural ones because the challenges from the varied uses of computers increase at a dizzying pace.
When I started designing C++ almost 40 years ago computers tended to “live” in air-conditioned rooms attended by dedicated staffs of operators. Today, your cell phone has 1000 times as much memory and 1000 times as much compute power than the most powerful computers then. Even your coffee maker may contain a more powerful computer than the computers I used to initially develop C++. To be useful in the long run, a language must cope with such dramatic changes. Most new programming languages die within a few years of their design.
Dennis Ritchie, my colleague at Bell Labs, who designed the C programming language, famously pointed out that “some languages are designed to solve a problem; others to prove a point.” Like C, C++ was designed to solve a particular problem. I wanted to build a distributed operating system – a system using several computers acting to accomplish common goals. Having such a very challenging problem was essential because a language is little more than a grammar and a dictionary before idioms are developed. Applying a language to a class of problems gives the feedback necessary to improve the fundamental constructs to enable elegant expression of ideas in a given domain. In the hands of inspired authors, natural languages grew in the same way. C++ may not have had a Homer to a Shakespeare, but it owes much to gifted programmers who invented its effective idioms. An example is Alex Stepanov’s development of generic programming. Also, this is just basic good engineering: we improve things through repeated refinement and incorporation of new ideas discovered in real-world use. We are guided by feedback.
One key early idea for C++ was not to offer tools for directly solving specific problems, but to offer tools for the programmers themselves to build such solutions. I borrowed – with acknowledgement, of course – that idea from the language Simula. Such tools support the idea of abstraction, the idea of programmers inventing new styles of expression to lift their use of the language from simple manipulation of computer machine facilities to something closer to the way we think: making the language fit for humans. For example, where early programmers dealt directly with bits, bytes, and words, C++ programmers can now express their ideas in a style suitable to their application domains. For example, engineers can use complex numbers, matrices, and Fourier transforms whereas linguists can express their ideas in terms of grammatical constructs and semantic nets. Each application domain has its own vocabulary and idioms; to be useful a language must adjust to allow their expression.
Writing software is not an exercise in pure logic. Our designs have to run on hardware and to meet the needs of its end-users. Our software must exploit the strengths of our hardware and compensate for its weaknesses. Human expectations have consistently outpaced even the incredible improvements of our computers and communication resources. The key limiting factor is the speed of light. We hit that absolute limit when trying to speed up processing and especially when we need to communicate with remote users. To some programmers, a nanosecond – a thousand millions of a second – is a long time. In a nanosecond, a signal can only cross a computer chip from edge to edge a few times. This limits how much computation we can do while people – or machines –wait for results. On a human time-scale, delays of just a fraction of a second can be noticeable and annoying, yet in our everyday lives we rely on sound, images, and messages being transmitted across the Atlantic; again, the speed of light becomes a factor in our designs. C++ was designed to allow programmers to exploit their hardware optimally and over the years its facilities for doing so have steadily improved. That’s uncommon; most languages are designed to protect programmers from the quirks and changes of hardware, rather than allowing them to manipulate hardware resources directly. This gives C++ a significant advantage compared to other languages in areas such as control of hardware devices, finance, video games, and just about anything involving mathematics and concurrency. You can express the essence of C++ in two lines:
    •    Direct support for hardware
    •    Zero-overheard abstraction
Then, you can spend a lifetime exploring the implications of that idea.
Education, together with research and engineering, is necessary for progress. The union of those three is essential! You can’t just give someone a new, powerful tool without guidance as to how to use it. I have compared C++ to a power tool. Arno Penzias, the president of Bell Labs and a Nobel Prize winner, elaborated that metaphor to help Bell Labs managers to understand C++: How would someone accustomed to sawing with an old-fashioned saw use a power-saw? By moving it forward and backwards over the wood, as they were used to. Doing that can make the power-saw jerk away with possibilities of serious injury. We must carefully consider the use of our new tool, C++, as part of design and guide the users towards effective use. Unfortunately, many prefer not to be educated, but I and others persist. We teach, we design curricula, we write articles, books, and blogs, we lecture and make videos. Educating a very diverse set of students and professionals is constant challenge. Each time we manage to get an idea across, a new set of learners come along and new ideas emerge.
These days, the further development C++ and the education of C++ programmers are intertwined. It is an enormous task. There are about 4.5 million C++ programmers world-wide and many, many thousands of teachers. We can’t even teach teachers fast enough. The further development of C++ is in the hands of an official international standards committee. Both the University of Carlos III and Morgan Stanley take part, as does most of the large technology companies, such as Google, Facebook, Microsoft, Intel, and IBM. It is an international effort involving people from many industries, research organizations, and user groups. Given the number of participants in the standards process and the variety of serious interests involved, it is fiendishly difficult to maintain a direction for the evolution of a language, to maintain coherence. Thus, the design effort is augmented by and constrained by efforts to communicate ideas, to analyze alternatives, and to negotiate among interested parties. This has to be done responsibly because errors would cause harm, potentially to millions of users. Also, stability of the language definition over decades becomes essential. All programmers want a simpler and a better language, but first of all, most say “Don’t break my code!”
I have now spent the almost 40 decades working on a programming language. Fortunately, the results are major and mostly positive. Essentially every one of you have used C++ today, indirectly through the computerized services you use: your computer, your phone, your car, your credit card, and more.
Thank you for listening and thanks to the University of Carlos III for honoring my work on design, programming, and C++. I treasure the distinguished title of Doctor Honoris Causa and feel that it honors not only my work, but also the significant contributions to the world of the huge C++ community.