Lex Fridman PodcastBjarne Stroustrup: C++ | Lex Fridman Podcast #48
CHAPTERS
- 0:00 – 3:20
Bjarne’s first programs: Algol 60, assembler, and discovering Simula
Bjarne recalls learning to program in university, starting with Algol 60 and early graphical/math experiments on paper printers. He describes moving from higher-level languages to assembler/microcode for performance and paid work, before encountering Simula as a formative influence.
- •First program: computing a super-ellipse and printing star patterns
- •Early language preferences: Algol 60 vs. Fortran/Pascal
- •Enjoyment of low-level work: assembler and microcode
- •Simula as a turning point for thinking about software structure
- 3:20 – 6:18
Simula’s big idea: user-defined types, modularity, and strong-but-flexible typing
Simula’s ‘class as user-defined type’ model reframes programming as building domain-appropriate abstractions. Bjarne contrasts Pascal’s restrictive, moralistic style with Simula’s extensibility and explains why a strong type system must also be adaptable.
- •Simula introduced classes, inheritance, and runtime polymorphism
- •User-defined types help complexity scale with program size (not size²)
- •Pascal’s type system as restrictive; Simula as extensible
- •Types as a way to build domain-specific languages
- 6:18 – 16:46
A personal history of languages: Fortran → ALGOL → Simula (and the Lisp divide)
Bjarne sketches key programming-language breakthroughs: Fortran’s portability via translation from human-friendly notation, ALGOL’s technical elegance, and Simula’s flexibility. He also explains why Lisp and dynamic systems matter historically but don’t fit his performance/reliability constraints.
- •Fortran: formula translation, portability, and efficiency goals
- •ALGOL: scope/types/translation phases as technical advances
- •Simula: flexibility via user-defined abstractions
- •Why dynamic languages (e.g., Lisp) are less relevant under hard constraints
- 16:46 – 23:20
Why learn multiple languages: perspectives, machine code, and functional thinking
Bjarne argues that the most important number of languages is ‘not one,’ likening it to learning cultures. He recommends exposure from machine code through C++ to functional languages and scripting languages, emphasizing understanding architecture and clean expression for optimization.
- •Second language matters most; learning expands design thinking
- •Still valuable to understand machine code and architecture (cache effects, etc.)
- •Modern optimization: simpler, clearer code can be faster
- •Suggested mix: machine code, C++, a functional language (ML/Haskell), and a rapid scripting language
- 23:20 – 25:07
Tools get used in unexpected ways: JavaScript, unintended use, and ethics
They discuss how language designers can’t fully control usage and must respond to real-world cuts and misuse. Bjarne defends JavaScript’s enabling role in the browser while acknowledging design compromises, and briefly notes uncomfortable uses like Bitcoin mining.
- •Designers adapt to how tools are actually used, not idealized usage
- •JavaScript enabled the web despite imperfections
- •Non-professional programmers shaped browser-language reality
- •Ethical discomfort: energy-heavy/criminogenic applications of computing
- 25:07 – 27:31
Origin motivation for C++: performance + reliability as real-world requirements
Lex and Bjarne frame C++’s origin around constrained environments where crashes are unacceptable: telephony, banking, and embedded control. Bjarne emphasizes that efficiency enables reliability (and affordability), especially in long-lived deployed systems.
- •Reliability examples: telephony quality, banking correctness, embedded stability
- •Efficiency isn’t just speed—it enables system-level dependability
- •Modern systems keep raising complexity, so constraints persist
- •Embedded control (e.g., cars) raises stakes for software correctness
- 27:31 – 36:44
Safety is a systems property: simplify first, then guidelines and analysis
Bjarne argues safety/performance/security must be addressed at the whole-system level, not by declaring individual components ‘safe.’ For C++ code, he prioritizes simplification—making intent directly expressible—then uses guidelines, review, and tooling to reduce common failure modes.
- •Safety/security/performance are emergent properties of whole systems
- •Simplification reduces bugs more effectively than ‘test everything’ alone
- •Express intent directly in code to reduce hidden ‘mental’ dependencies
- •C++ Core Guidelines: bridging what’s possible vs. what you should do
- 36:44 – 41:15
Static analysis explained: finding bugs before runtime (and avoiding impossible proofs)
They define static analysis as checking code without running it, using representations to detect problems like resource leaks. Bjarne stresses the combination of rules + analysis to avoid intractable complexity (e.g., halting-problem territory) and reduce error-handling burden.
- •Static analysis: inspecting code paths/representations without execution
- •Example: detecting malloc/free mismatches and ownership leaks
- •Rules constrain patterns to make analysis feasible and useful
- •Catching errors early reduces complex runtime error-handling needs
- 41:15 – 47:09
C++ design philosophy: not ‘OO language,’ but multi-paradigm with guiding principles
Bjarne pushes back on labeling C++ as purely object-oriented, describing it as a language supporting multiple techniques. He explains that coherent design requires principles—most notably the zero-overhead principle—rather than feature accretion.
- •C++ supports OO, generic, functional-ish styles, and low-level C-style code
- •Coherence requires design principles, not additive feature requests
- •Zero-overhead principle: abstractions shouldn’t cost more than lower-level equivalents
- •Best abstraction can produce best performance (e.g., eliminating temporaries)
- 47:09 – 54:45
How zero-overhead works in practice: compilers, techniques, and multi-compiler ecosystems
They explore how language features and implementations co-evolve: techniques, features, and compiler craftsmanship all matter. Bjarne explains why multiple compilers are natural (many platforms/linkers) and beneficial (avoiding monocultures, driving quality and compliance).
- •Performance comes from the combination of language design + implementation + technique
- •Early compiler work (Cfront) mattered for C++ adoption and optimization
- •Multiple compilers were inevitable across hardware/OS diversity
- •Competition among GCC/Clang/MSVC/EDG improves standards compliance and tooling
- 54:45 – 1:08:02
Core C++ building blocks: classes, inheritance, templates, and efficient implementation tricks
Bjarne outlines C++’s two major abstraction mechanisms: inheritance (runtime polymorphism) and parameterization (templates/generic programming). He explains efficient implementations (vtables, compile-time template instantiation), and why optimized code complicates debugging.
- •C++ aims: use hardware well while managing complexity via abstraction
- •Classes as user-defined types usable like built-ins (including efficiency)
- •Inheritance via virtual functions and vtables; pay only when needed
- •Templates generate specialized code at compile time; can outperform hand-written code
- •Debugging optimized/template-heavy code is hard; often debug with optimizations off
- 1:08:02 – 1:18:21
Concepts (C++20): compile-time requirements for templates, and why it took decades
Concepts add explicit compile-time constraints to generic code, turning implicit template requirements into checkable predicates. Bjarne traces the long road from 1980s desires to failed 2000s attempts, and finally a workable C++20 design that preserves flexibility and performance.
- •Concepts: compile-time predicates like ‘Sortable’ or ‘Integral’
- •Make template requirements explicit: better errors, stronger interfaces
- •Early goals for templates: flexibility + performance + constraint checking (hard to get all 3)
- •2000s concept designs struggled with compile speed, usability, and optimization demands
- •C++20 concepts became real through improved design and implementations
- 1:18:21 – 1:28:06
How C++ gets standardized: committee mechanics, consensus, and the shift to 3-year releases
Bjarne describes the origin of standardization pressure from industry, the ANSI-to-ISO evolution, and how meetings and voting work. He discusses why C++98 took years, why C++11 slipped, and how the committee moved to a predictable three-year cycle for delivery and implementation readiness.
- •Standardization began in 1989 due to industry dependence and ‘bus factor’ risk
- •Open process with organizational voting; global participation across many countries
- •Consensus focus avoids fracturing into dialects
- •C++98 shipped after long effort; C++11 took much longer than hoped
- •3-year cadence (C++14/17/20) improves predictability and implementation uptake
- 1:28:06 – 1:31:53
The most beautiful C++ feature: RAII, constructors/destructors, and the ‘life cycle’ of objects
Bjarne names constructors/destructors (RAII) as C++’s defining innovation, enabling predictable performance and systematic resource management without mandatory garbage collection. He connects this to controlling copying and movement to complete a type’s core operations.
- •Constructors establish invariants; destructors reliably clean up
- •RAII enables predictable performance and resource safety
- •Naming aside, RAII is central to robust, efficient systems
- •Controlling copy and move completes the object life-cycle model
- 1:31:53 – 1:44:21
Future of languages and ‘fuzzy programming’: convergence of principles, and limits of ML reliability
They discuss whether language design can converge on shared principles across paradigms, comparing maturity of computing to physics. Bjarne draws a sharp line between domains that tolerate probabilistic ML behavior and engineering domains requiring precision, while noting ML stacks still rely on systems languages underneath.
- •Shared design principles can exist even across very different languages (e.g., Lisp vs. C++)
- •Computing is young; expect gradual convergence within domains rather than one universal language
- •ML is valuable but often not reliable enough for safety-critical control loops
- •Human handoff in autonomy is a major safety challenge
- •Real systems are polyglot; different layers demand different tools
- 1:44:21 – 1:47:12
Looking back: impact, community, and seeing C++ power real-world engineering
Bjarne reflects on C++ as a mix of ideas, hard work, and luck, and why he keeps returning to it due to its reach. He describes the joy of seeing C++ used in telescopes, cars, and space exploration, and ends with optimism about making it better.
- •C++’s impact comes from both technical merit and adoption scale
- •Motivation: improvements can reach millions of users quickly
- •C++ enabled participation in diverse engineering domains (telescopes, automotive, JPL)
- •Community and real-world artifacts make the work meaningful
- •Commitment to continued evolution and improvement
