6 July 2010

An interview with Bjarne Stroustrup

Bjarne Stroustrup is the creator of C++, one of the most widely used languages that allows object-oriented programming. He also authored The C++ Programming Language and The Design and Evolution of C++. Stroustrup is currently the head of AT&T Labs’s large-scale programming research department in New Jersey. His research interests include distributed systems, operating systems, simulation, design, and programming.

LinuxWorld.com: Object-oriented languages have been around since the late 1960s. Yet, the object-oriented revolution took place more than two decades later. How do you explain this delay and which conclusions can we draw from it?

Bjarne Stroustrup: Part of the reason is that changes in people’s behavior always take far more time than we are willing to believe. Another major reason is that some people had (and have) unreasonable expectations about “revolutions.” The idea that there is one right way to solve essentially every problem for essentially every user is fundamentally wrong. I’m a great fan of the idea of object-oriented programming and the design ideals and techniques that it supports — originating with Simula 67. However, those are not the only effective techniques. Much programming is best done with techniques that do not fall within a narrow definition of “object-oriented.” And if you broaden the definition of “object-oriented” sufficiently for it not to be an obstacle to good programming and design, you get something that is basically meaningless. See my paper, “Why C++ isn’t just an Object-Oriented Programming Language.”

Yet, another reason is that people pushing “True OO” or “Pure OO” typically do so with languages and systems that impose enormous overheads for simple tasks compared to C and C++ code.

The conclusions that I drew (in 1980 or so) were that a general-purpose programming language must support multiple paradigms and that each paradigm must be supported well and with close-to-optimal runtime and space efficiencies. That said, I find that adoption of new ideas is seriously slowed by conservatism supported with myths of complexity and overheads.

Another problem is that many people, including many programmers, educators, and managers, are simply unwilling to face the complexities of software development. They dream of “silver bullets” and reject effective ideas because they are not perfect and not trivial to use by novices. This leads to real work being done using unnecessarily old languages, tools, and techniques while scarce resources are being squandered on a succession of fads. This underestimation of the problems also leads to every new “silver bullet” being too simplistic to address the rigors of real-world software development. And once something new has adapted to reality, it becomes vulnerable to criticism — fair and not — of complexity from the followers of the next “silver bullet.”

To get back on a semitechnical note: I think that any language that aspires to mainstream use must provide a broad base for a variety of techniques — including object-oriented programming (class hierarchies) and generic programming (parameterized types and algorithms). In particular, it must provide good facilities for composing programs out of separate parts (possibly writing in several different languages). I also think that exceptions are necessary for managing the complexity of error handling. A language that lacks such facilities forces its users to laboriously simulate them.

LinuxWorld.com: Which important programming trends are we about to see in the near future? What is the role of functional programming, rule-based programming, generic programming, and other programming paradigms in tomorrow’s software world? Will any of these become the mainstream or are they mere academic trifles?

Bjarne Stroustrup: I’m not good at predicting the future, so I won’t try, beyond pointing out that the future is usually more like yesterday than we like to believe. Note that COBOL, FORTRAN, and C still are major languages. Generic programming is real (mainstream) and you can see how the Standard Template Library (STL) borrows techniques from the functional programming community and uses them elegantly and efficiently in the context of C++. Rule-based programming (see the R++ link in Resources) has a record of failures and successes on a scale that didn’t lead to mainstream adoption. That’s a pity, but I don’t want to call it an “academic trifle.” Many of the ideas we today see as standalone languages will enter the mainstream as facilities and techniques embedded in a mainstream language, such as C++. The future will see much multiparadigm programming and many multilingual systems.

LinuxWorld.com: With the ratification of the new C99 standard, C/C++ compatibility seems more evasive than ever before. Is backward compatibility with C still one of the goals of C++? If so, what should be done to minimize the gaping chasms between the two languages?

Bjarne Stroustrup: C99 focused on extending the low-level facilities of C in the area of numeric programming. It basically ignored the abstraction facilities and the aims of generality embodied in C++. This makes compatibility harder as C adds more ad hoc, special-purpose facilities, where C++ addresses the same programmer needs through libraries implemented using general-purpose language facilities. An example is C99 variable-length arrays vs. C++’s vector. A more coordinated evolution of the two languages would have avoided this split.

My ideal is still a single language, and it is still technically feasible to merge C++ and C99 into a single, reasonably coherent language. I think such a language could meet every rational technical requirement. However, I’m not sure that the political will is there. For starters, it would require a merger of the C and C++ standards committees; it is not possible to have two different groups of people evolving two languages in parallel. Each committee attracts people who don’t share the ideals of the majority of the other and who dislike compromising with that majority. Thus, whereas a single committee fosters a shared community, trust, and compromise, two committees provide opportunities for divergence and for ignoring inconvenient facts and opinions. Personally, I think the committees should work out an agreement to merge, and then merge in good time before the ISO C++ standard comes up for renewal. The result would be a better language and a much stronger community.

You may have missed:

Comments are closed.