Stroustrup, Bjarne
▶ Watch on YouTubeCore ideas
Stroustrup traces his intellectual path from Algol 60 through Simula, the language that shaped nearly everything that followed: Simula let programmers define their own types rather than fitting into a language designer's fixed world, and demonstrated that program complexity could scale linearly with size rather than quadratically if code was properly modularized around user-defined types. He credits Simula's inventors (Kristen Nygaard and Ole-Johan Dahl) with effectively inventing object-oriented programming, inheritance, and runtime polymorphism as a byproduct of building better simulations — illustrating the value of inheritance with Simula's real 1960s use case of simulating Norwegian emergency vehicles, where a base "vehicle" class let each subtype (car, bicycle, fire engine) implement its own "turn left" behavior rather than forcing giant conditional statements. He frames Fortran as an earlier, equally important breakthrough — the first language letting programmers write in terms natural to humans (mathematical notation) rather than machine-specific code, incidentally yielding portability as a side effect — while noting Lisp, though historically important, doesn't fit his domain because he needs guarantees around performance, reliability, and deployability (e.g., debugging a telephone switch in Bogotá on a Sunday night with no engineer present) that highly dynamic languages don't provide.
Stroustrup recounts C++'s origin as an explicit synthesis: not "object-oriented" in a narrow sense (he says he never claimed that, only that C++ "supports" object-oriented programming among "nine other techniques"), but built around the idea that the best solutions to complex problems require combining ideas from object-oriented design, data abstraction, functional-style code, and traditional C-style low-level code. His central design commitment is the "zero-overhead principle": any abstraction should cost nothing compared to hand-written lower-level equivalent code — illustrated by C++ matrix multiplication libraries that, thanks to compiler optimizations like loop fusion and elimination of temporaries enabled specifically by the abstraction, can run faster than hand-written Fortran or C, a result that consistently surprises audiences skeptical that "rewriting it in C would be faster." He describes implementing virtual functions (borrowed conceptually, but not implementation-wise, from Simula) via the simplest possible mechanism — a jump table with a single indirection — specifically to keep object-oriented flexibility nearly free compared to ordinary function calls, and lets programmers opt out of virtual dispatch entirely when they don't need the flexibility. Generic programming via templates achieves similar zero-overhead status because the compiler combines the template and its concrete type parameter at compile time to generate code equivalent to what a programmer would have hand-written for that specific type — sometimes generating faster code than a human could write by hand, at the cost of notoriously difficult-to-read generated code and debugging, which Stroustrup addresses by debugging with optimizations turned off.
He walks through the multi-decade effort behind C++20's "concepts" feature — compile-time predicates that specify what operations and properties a generic template's type parameters must support (e.g., "sortable" requires a sequence with begin/end, random access, and a comparison operator) — explaining that his first attempt in the 1980s-2000s failed because early designs borrowed from the functional-programming community didn't fit C++'s support for implicit conversions and mixed-type arithmetic, and didn't meet his "draconian" performance requirements; only later designs (developed with Gabriel Dos Reis and Andrew Sutton) succeeded in compiling fast and running fast enough for production, finally shipping roughly three decades after he first wanted the feature. He identifies constructor/destructor pairs — the mechanism behind RAII ("Resource Acquisition Is Initialization," a name he self-deprecatingly calls poorly chosen) — as C++'s single most important and beautiful idea, since establishing an object's environment on construction and automatically cleaning up resources on destruction is what lets C++ avoid garbage collection while still achieving predictable performance and reliable resource management, extended further by rules for controlling copying and (later) move semantics.
On the ISO standardization process, Stroustrup describes an open, consensus-driven process (roughly $1,000+ to join, one vote per organization to prevent any single company from dominating, three one-week meetings a year across 15-20+ countries) that took its first standard (C++98) about a decade to complete, then dramatically overshot its second cycle's timeline (aiming for ~C++0x, actually delivering C++11 after 13 years) due to a "second system effect" of excessive ambition — a lesson the committee addressed by shipping on a fixed three-year cadence (C++14, C++17, C++20) so that any single missed feature only slips by a few years rather than a full decade, improving predictability for compiler and library implementers. He explains the historical proliferation of multiple C++ compiler implementations (Clang, GCC, Microsoft, EDG) as an inevitable consequence of the language being designed to target many different machine architectures, linkers, and operating systems from the start, and argues this competition (rather than a single canonical implementation) is healthy, since monocultures tend to stagnate without competitive pressure.
On safety and reliability, Stroustrup argues these are fundamentally systems properties, not properties of isolated components — a "secure" piece of code embedded in an insecure system provides no real security — and that the primary lever for making C++ programs more reliable is simplification: expressing ideas directly in code so that no critical logic remains only "in your head," which simultaneously improves testability, maintainability, and (often counterintuitively) runtime performance. He champions static analysis (checking code without running it, e.g. detecting resource leaks by verifying that allocations and frees match) as a complement to rules-based coding guidelines like the C++ Core Guidelines he helped create, framing good coding rules as analogous to craftsmanship rules for sculptors — necessary but insufficient for producing genuinely inspired, beautiful code, which still requires a spark that can't be regulated. Asked about machine learning, Stroustrup is candid that probabilistic, "fuzzy" systems represent a fundamentally different paradigm from the deterministic reliability he designs for, expressing particular concern about safety-critical systems that hand off edge cases to a human who may have only seconds to react — arguing that for domains like nuclear reactors or autonomous vehicles, the goal should be systems that never need to ask a human for help mid-operation, even while acknowledging machine learning's legitimate value in domains where high but imperfect accuracy is an acceptable and even superior alternative to human judgment.
Excerpts
On the zero-overhead principle as C++'s central design commitment:
“If you have an abstraction, it should not cost anything compared to writing the equivalent code at a lower level... we have actually gotten code that ran faster than Fortran, because once you had the right abstraction, you can eliminate temporaries and you can do loop fusion... A very common question after the talk... 'yeah, but if I rewrote your code in C, how much faster would it have run?' The answer is: much slower.”
On why constructors and destructors are C++'s most important idea:
“The way a constructor can establish the environment for the use of a type... and the destructor that cleans up any messes at the end of it — that is the key to C++. That's why we don't have to use garbage collection, that's how we can get predictable performance... it's also the best example of why I shouldn't be in advertising — I got the best idea and I called it 'resource acquisition is initialization.'”
On why he's wary of machine learning in safety-critical, human-in-the-loop systems:
“The idea that scares me the most... is you have this AI system, machine learning, all of these trained neural nets, and when something is too complicated, they ask the human for help — but the human is reading a book or asleep, and has thirty seconds or three seconds to figure out what the problem was that the AI system couldn't handle... it would be much better to design systems that never ask a human for help.”