Computer History Museum
C++ prevailed because coupling high-level modularity with zero-overhead hardware access solved surging software complexity without sacrificing the raw runtime speed demanded by scaled systems.
AI-assisted summary of Oral History of Bjarne Stroustrup — original source. Check the original for full context.
Source published:
Key ideas
- Bjarne Stroustrup designed C with Classes and C++ to bridge the gap between Simula's high-level object-oriented abstractions and C's bare-metal hardware efficiency, guided by the foundational zero-overhead principle. (34:29)
- The adoption of Alexander Stepanov's Standard Template Library (STL) succeeded in the ISO standards committee because vendor gridlock between proprietary object-oriented frameworks opened the path for an algorithm-centric, vendor-neutral alternative. (80:37)
- In modern computing systems, Stroustrup emphasizes that resource safety—encompassing deterministic cleanup of file handles, sockets, and mutex locks via RAII—is far more critical than narrow garbage-collected memory safety. (90:42)
- Stroustrup became the Computer History Museum's first third-generation Fellow, continuing a direct academic lineage from Maurice Wilkes to David Wheeler to himself. (117:08)
Detailed notes
## Background Published by the Computer History Museum on YouTube on September 4, 2015, this oral history interview features computer scientist Bjarne Stroustrup interviewed by Paul McJones on February 5, 2015, in New York. According to the page description, the discussion covers Stroustrup's upbringing, his education at Aarhus University and Cambridge, his career across AT&T Bell Laboratories, Texas A&M, and Morgan Stanley, and the design, evolution, and standardization of C++ from C with Classes through C++11 and C++14.
## TL;DR In this extensive oral history, Bjarne Stroustrup recounts his trajectory from working-class Aarhus to Cambridge, Bell Labs, academia, and financial computing, detailing the engineering pressures that motivated him to create C++. He explains how the tension between Simula's high-level abstractions and BCPL's bare-metal efficiency forged his zero-overhead design philosophy, which prioritized concrete resource management and performance over academic purity. Stroustrup reflects on the battles surrounding early Cfront releases, the standardization of the language, the integration of Alexander Stepanov's Standard Template Library, and modern language features like Concepts and constexpr. Throughout the interview, he champions real-world problem solving, laments the decline of foundational corporate labs and historical awareness in computer science, and underscores the vital importance of software preservation.
## Atmosphere & style The interview possesses an unhurried, scholarly, and candid tone, feeling like an intimate fireside reflection between two veteran computer scientists who share deep institutional memory. Stroustrup speaks with measured Danish-accented pragmatism, dry wit, and unpretentious modesty, frequently puncturing computing orthodoxies and academic elitism with plainspoken common sense. McJones acts as an informed, appreciative guide, allowing Stroustrup room to muse on everything from grueling compiler debugging sessions to the human toll of corporate downsizing, creating an atmosphere that feels intellectually rigorous, historically grounded, and quietly philosophical.
## Bulletin - [34:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2069s) Bjarne Stroustrup designed C with Classes and C++ to bridge the gap between Simula's high-level object-oriented abstractions and C's bare-metal hardware efficiency, guided by the foundational zero-overhead principle. - [01:20:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4837s) The adoption of Alexander Stepanov's Standard Template Library (STL) succeeded in the ISO standards committee because vendor gridlock between proprietary object-oriented frameworks opened the path for an algorithm-centric, vendor-neutral alternative. - [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) In modern computing systems, Stroustrup emphasizes that resource safety—encompassing deterministic cleanup of file handles, sockets, and mutex locks via RAII—is far more critical than narrow garbage-collected memory safety. - [01:57:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=7028s) Stroustrup became the Computer History Museum's first third-generation Fellow, continuing a direct academic lineage from Maurice Wilkes to David Wheeler to himself.
## Key takeaways - [02:30](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=150s) Stroustrup entered computer science at Aarhus University under the mistaken assumption that it was an applied branch of mathematics, quickly realizing programming and hardware architecture were separate disciplines. - [12:22](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=742s) Early contract programming for Burroughs exposed Stroustrup to end-to-end software delivery and customer accountability, shaping his view of engineering ethics. - [26:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1592s) During his Cambridge Ph.D., Stroustrup's simulator exhausted university mainframe resources when written in Simula, forcing a rewrite in BCPL and crystallizing his principle that good code must be fast code. - [34:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2069s) Stroustrup created C with Classes at AT&T Bell Labs to decompose Unix kernel services into modular components across distributed networks without sacrificing runtime speed. - [39:56](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2396s) To address severe type flaws in early C, Stroustrup introduced function prototypes, constructors and destructors (RAII), and unified value semantics. - [46:12](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2772s) For nearly a decade, Stroustrup operated as a solo developer and support desk for C++, writing 98% of the codebase, tools, and documentation while assisting early enterprise adopters. - [55:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3337s) The C++ template mechanism was engineered around three strict criteria: open-ended generality, zero-overhead runtime matching raw C arrays, and formal interface checking. - [01:05:33](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3933s) Standardization was driven by corporate enterprise users like HP and IBM to eliminate bus-factor risks rather than by Stroustrup himself. - [01:12:38](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4358s) Modern C++ features such as auto type deduction, lambdas, and constexpr unify functional programming techniques with pre-existing zero-overhead language constructs like function objects. - [01:20:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4837s) Stroustrup supported the STL after verifying it met 10 of 11 architectural criteria for container libraries, recognizing its adherence to zero-overhead generic algorithms. - [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) Comprehensive resource safety via RAII and move semantics is prioritized over garbage collection, as leaking non-memory resources like sockets or locks can crash systems far faster. - [01:33:41](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5621s) Bell Labs maintained an exceptional research environment by balancing loose, curiosity-driven long-term bets with pragmatic annual goals, an ethos dismantled during the telecom crash and corporate spin-offs. - [01:39:23](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5963s) Stroustrup criticizes academic computer science for chasing fads and publishing abstractions of abstractions disconnected from practical systems implementation. - [01:47:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6445s) Advice for aspiring language designers highlights that successful languages emerge from solving concrete, widespread industry problems rather than academic exercises in novelty. - [01:50:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6625s) Stroustrup warns against historical amnesia among computer science students, advocating for history education and software-focused preservation in museums.
## Detailed walkthrough ### [00:05](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5s) Introduction and Early Life in Aarhus
The interview opens on February 5, 2015, with interviewer Paul McJones in California speaking with Bjarne Stroustrup in New York City, accompanied by videographer John Plute behind the camera. Reflecting on the video link spanning several thousand miles, McJones points out that it is likely powered by C++ technology behind the scenes, to which Stroustrup agrees, observing: “and I was thinking that when I started on this we couldn't have done this”.
Stroustrup turns to his childhood in Aarhus, Denmark, where he lived for the first 23 years of his life. He grew up in an apartment in a working-class district. His father worked laying floors and later, following an illness, became a hospital porter; his mother worked as a secretary. Having completed middle school, his mother held the highest level of education in the family up to that time. Stroustrup attended the local school, which he notes humorously was statistically the worst school in town. He nevertheless qualified for high school and subsequently entered Aarhus University, a school that regularly features on lists of the top 100 universities in the world. He recalls a stable and pleasant upbringing living in standard European rectangular apartment blocks built around a communal grass courtyard known as “the yard.”
- Location of birth and upbringing: Aarhus, Denmark (first 23 years) - Father's occupations: Floor layer, later hospital porter - Mother's education and occupation: Middle school education (family record at the time), secretary - Residence: Working-class apartment complex around a central courtyard ("the yard") - Higher education institution: Aarhus University (Aarhus Universitet)
---
[02:30](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=150s) Entering Computer Science via Applied Mathematics
As a high school student, Stroustrup had no clear idea what career path to take, contemplating becoming a historian, an architect, a sociologist, or an engineer. Knowing his options were open as long as he kept his marks up, he earned grades high enough to get in anywhere. He initially contemplated attending the engineering university in Copenhagen, but ruled it out due to living expenses: although university tuition in Denmark was free, coming from a family of modest means made the prospect of taking on substantial debt to support a six-year course in Copenhagen daunting.
He decided to stay local in Aarhus. Because Aarhus University lacked an engineering school, and because he was reasonably good at high school mathematics, he enrolled in mathematics. However, he was determined to avoid pure theory, driven by an acute fear of becoming a schoolteacher:
> “I had an absolute dread of becoming a a teacher because I thought that was what happens to Bright kids who don't know what they're doing uh have no uh Role Models have no ideas what they're doing so I I didn't want to be a teacher so I needed to find some kind of Applied math something I could really do and so I signed up for computer science…”
In Danish, the title of the discipline did not include the word “computer” (*datalogi*), which allowed him to misunderstand it as an applied branch of mathematics. In his second year, he realized his mistake: machine architecture, data structures, and programming were not mathematics. This discovery proved fortunate, as he realized he was not quite as good at pure math as he had assumed, whereas learning computer science and working directly with machines was immediately engaging.
- Initial career interests: Historian, architect, sociologist, engineer - Reason for not going to Copenhagen: Cost of living and fear of accumulating student debt on a six-year degree - Degree program: Mathematics with computer science (Cand.Scient. / Master's degree) - Realization during Year 2: Programming, data structures, and computer architecture are fundamentally distinct from pure mathematics
---
[05:11](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=311s) Influences, Foundational Studies, and Pure Math
When asked about early mentors, Stroustrup notes there was no one who guided him down that specific career track. He had the same mathematics teacher for nine consecutive years who provided solid instruction, but the teacher had gone from middle school to a teacher's training college without attending high school, so he could not advise Stroustrup on university academics. Because no one in his family had higher education experience either, Stroustrup navigated his schooling largely on his own.
He completed his master's degree in mathematics with computer science (as Danish universities did not award bachelor's degrees at that time). Although he initially thought the heavy pure math requirements would never be useful, his perspective changed later in life. Decades later, concepts from abstract algebra became essential when dealing with type theory and Alexander Stepanov’s design of the Standard Template Library (STL). He reflects that while he might once have scoffed at algebra's relevance, “the kind of thinking I learned in algebra has actually been been very useful over the last couple of decades after being not useful at all for a couple of decades”.
- Early educational mentor: Math teacher of 9 years (trained as a Danish teacher via a teachers' training college) - Degree earned: Master's in Mathematics with Computer Science (no Bachelor's degrees existed in Denmark at the time) - Delayed utility of pure mathematics: Abstract algebra became directly applicable decades later to type theory and Stepanov's STL
---
[07:03](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=423s) Early Architecture Projects and BCPL Microcode
When asked about influential books from his university days, Stroustrup jokingly recalls a book on chess opening theory before mentioning David Gries’s *Compiler Construction for Digital Computers*. While Gries’s text focused primarily on parsing and formal grammars—which Stroustrup later realized was the least critical part of real-world compiler design—it sparked his initial interest in programming languages and implementation techniques.
Even so, Stroustrup emphasizes that he was not fundamentally a “programming languages guy”; his passions were computer architecture, operating systems, and microprogramming. During an early project at Aarhus, he wanted to run BCPL on existing hardware. Examining Martin Richards’s compiler pipeline, he noticed O-code, the intermediate assembly-like bytecode for BCPL. Instead of writing a conventional software interpreter or full machine-code backend, Stroustrup microcoded an engine in hardware to execute O-code directly. He designed a compressed representation of O-code data structures to conserve memory, effectively building a specialized virtual machine in microcode to run BCPL directly on the machine.
```mermaid flowchart LR accTitle: Stroustrup's BCPL Microcode Execution Engine accDescr: Diagram showing BCPL source compiling to O-code, being compressed, and running on a custom microcode engine in hardware. subgraph Compilation["Richards Compiler Stage"] A["BCPL Source Code"] --> B["O-code Bytecode"] end subgraph Implementation["Stroustrup's Virtual Engine"] B --> C["Compressed O-code Format"] C --> D["Custom Microcode Engine (Hardware Virtual Machine)"] end ```
- Key book: David Gries, *Compiler Construction for Digital Computers* (emphasized grammars) - Primary interests: Operating systems, microprogramming, and machine architecture - BCPL project: Created a microcode-level implementation of Martin Richards's O-code intermediate language using compressed data structures
---
[09:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=582s) Learning Languages and the SNOBOL Epiphany
By the time Stroustrup completed his master's degree at Aarhus, he had learned between a dozen and twenty programming languages, ranging from COBOL (which he disliked) to string-manipulation languages like SNOBOL. He did not make sharp distinctions between “research” and “practical” languages, viewing all of them primarily as functional tools to control hardware or test instruction sets. In the smaller language ecosystems of the era, one could spend a few hours reading a language manual while stuck in a waiting room, experiment with it for a few weeks, and move on.
Stroustrup recounts a major formative experience while working with SNOBOL, the pattern-matching language from the 1960s. After writing a program, he realized he had essentially written an ALGOL program using SNOBOL syntax:
> “one what I would call formative experience was realizing that I had written an alcohol program in snowbo and was a really stupid program it was complicated it was difficult to get to run it ran slowly and it was not how any sane snowball programmer would write it and so you had to go back and actually learn the idioms you can't just uh take a language and start writing it as if it was your previous language which is what we essentially all do…”
This taught him within his first six months of programming that learning a language requires mastering its distinct idioms rather than forcing another language's paradigm into its syntax.
- Programming languages known by master's graduation: ~12 to 20 (including COBOL, ALGOL, SNOBOL, BCPL) - Philosophy on languages: Languages were tools to make hardware execute the right instructions rather than an end in themselves - Formative takeaway from SNOBOL: Direct translation of algorithmic idioms from one language (like ALGOL) into another leads to inefficient, unmaintainable code; languages must be used according to their native paradigms
---
[12:22](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=742s) Commercial Contract Programming with Burroughs
To support himself without incurring student debt, Stroustrup took on contract programming assignments while finishing his master's studies. Some of this contract work involved microprogramming for Aarhus University, but he also took a commercial programming contract with Burroughs Corporation.
McJones mentions Steve Lohr’s book *Go To*, asking how this practical work influenced him. Stroustrup explains that while the job was initially just a way to earn living expenses and live frugally without debt, it gave him valuable firsthand exposure to real-world software engineering. Working for Burroughs exposed him to the entire lifecycle of software delivery: sitting in on discussions with the client to determine requirements, and navigating the gap between what sales representatives promised, what clients actually wanted, and what was technically feasible to build.
- Employment motive: Avoiding student debt and earning cash to live frugally while studying - Contract employers: Aarhus University (microprogramming) and Burroughs Corporation - Industry insights gained: Requirement negotiations, resolving tensions between client demands and sales commitments, and delivering realistic production software
[13:19](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=799s) Software Engineering in the Real World: Demos, Clients, and Accountability
Before pursuing further graduate work, Bjarne Stroustrup ran an independent software development loop, building customized systems under a very direct commercial incentive model. Operating with a straightforward business rule, if he could build a demonstration that a prospective client found valuable enough to pay for, he was hired to implement the full production system. This structure was safe for the corporation because failing to sell a working demo meant he simply was no longer employed by them. At the same time, it aligned his interests with the clients and the company to deliver the most polished, usable product possible.
Stroustrup carried out the entire lifecycle directly: conferring with clients, observing installations on site, troubleshooting installation failures, and training the actual end-users. A formative element of this experience was interpersonal and ethical. He often sat in living rooms talking with the clients' children, which made the practical stakes tangible: if his code failed or the project went awry, those families suffered real consequences. Over several years, he repeated this entire cycle between six and twelve times, observing software development from initial requirements discovery through emergency cleanups when systems broke down.
```mermaid flowchart LR accTitle: Client Demo to Production Lifecycle accDescr: The cycle of building a client demo, securing payment, implementing the system, and providing long-term field support. subgraph Sales ["Phase 1: Validation"] A["Build Prototype Demo"] --> B{"Client Pays?"} end subgraph Delivery ["Phase 2: Delivery & Support"] B -- Yes --> C["Implement System"] C --> D["On-Site Installation"] D --> E["User Training & Field Repairs"] end B -- No --> F["Contract Ends"] ```
These real-world engagements firmly established Stroustrup's perspective on what software engineering requires: - He developed a strong conviction that computing systems must be fundamentally “appropriate and reliable and affordable,” stressing: “I have a fairly strong opinion about systems being appropriate and reliable and affordable, which I think partly came out of that it is not something that is easily installed in a in a classroom setting.” - Paul McJones observed that this fieldwork reinforced Stroustrup’s early ambition to pursue an applied discipline rather than purely abstract theory. - Sitting on a client's sofa trying to explain to young kids what he was building for their father made the human responsibility of practical software engineering immediate and concrete.
---
[15:47](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=947s) Applying to Cambridge and the Wilkes–Needham Interview
Although Stroustrup was well-positioned to step directly into a conventional software career, his encounter with microprogrammable hardware in England diverted his path. He had visited the country prior to completing his master's degree because British institutions had access to advanced hardware platforms. Deciding that a Ph.D. would provide the ideal mechanism to remain in the United Kingdom and continue experimenting with sophisticated machines, he submitted applications to the prominent British universities he knew of, gaining admission to nearly all of them.
He leaned toward attending Newcastle, but his then-girlfriend (later his wife) gave him unequivocal advice: “if you have an offer from Cambridge you take it this is non-negotiable.” Reflecting on the choice decades later, he affirmed that she was entirely correct, calling Cambridge “probably still for practical computer science the best place in Europe.”
When interviewing at Cambridge, he faced a grueling admission panel consisting of Maurice Wilkes and Roger Needham: - Stroustrup was entirely unaware at the time that Maurice Wilkes was the originator who had actually invented microprogramming; he enthusiastically explained current developments in microprogramming to Wilkes without realizing Wilkes’s historical role. - Wilkes had received the second ACM A.M. Turing Award and was later honored as a Computer History Museum Fellow; Stroustrup noted that he represents the third academic generation of that lineage, following Wilkes and his adviser David Wheeler. - Needham, who later served as Vice-Chancellor of the University of Cambridge and founded Microsoft Research Cambridge, alternated grilling him alongside Wilkes in what Stroustrup described as the most demanding 45 minutes of his life. - Stroustrup recalled the intensity of the examination: “Halfway through they explained to me that I was all wrong and could I—was there anything else I could do? So I had to change horses in the middle of that interview.” Despite having to scrap his initial argument midway through, he successfully persuaded them and earned admission.
---
[18:59](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1139s) Advising Styles: David Wheeler, Roger Needham, and Maurice Wilkes
Entering Cambridge already holding a master's degree, Stroustrup bypassed regular coursework, enrolling in classes only when a specific technical need arose. His relationship with his supervisor, David Wheeler, followed an informal, self-directed rhythm. Stroustrup quickly determined that visiting Wheeler’s office roughly once a week was optimal. He would arrive eager to present new ideas, only for Wheeler to reflect quietly and utter the phrase Stroustrup learned to dread most: “yeah, yeah, yeah, Bjarne, that's not a bad idea, you know we almost did that for the EDSAC 2.”
```mermaid flowchart TD accTitle: Academic Influences at Cambridge accDescr: The contrast between David Wheeler's historical critique and Roger Needham's pacing discussions at Cambridge. subgraph Mentors ["Mentorship Dynamics"] DW["David Wheeler<br/>(Adviser)"] RN["Roger Needham<br/>(Senior Lecturer)"] end subgraph Modes ["Interaction Style"] DW -->|"Weekly meetings: Tracing ideas back to EDSAC 2 (c. 1956)"| O1["Polite deconstruction & impromptu 1-hour lectures"] RN -->|"Pub lunches: Two pints of Abbot Ale & corridor pacing"| O2["Dynamic two-way technical dialogue"] end ```
Wheeler’s comment meant that the Cambridge team had evaluated the concept around 1956—right when Stroustrup was entering primary school. Wheeler would then launch into an impromptu hour-long tutorial laying out why they had bypassed that choice, the engineering trade-offs encountered, what alternative path they attempted, why that alternative had faltered, and how they ultimately patched the design: - Wheeler’s supervision model was centered on patience and intellectual rigor: “basically the the tuition style was to listen what I said then shoot it full of holes ever so politely and then just giving an impromptu lecture for about an hour on topics related to it and then I was going away feeling about this big and then you come back next week for the same.” - Stroustrup interacted extensively with Roger Needham, then a senior lecturer. Needham joined students for pub lunches, casually drinking two pints of strong Abbot Ale while remaining fully capable of working throughout the afternoon. - During technical debates, Needham incessantly paced up and down corridors; Stroustrup developed a survival technique of stationing himself at a hallway corner to converse without tiring himself out from pacing after him. - Maurice Wilkes remained an august, distant figure whom junior research students rarely saw without scheduling time through his secretary. Stroustrup only came to know Wilkes well later in his career, hosting him at Bell Labs and encountering him at conferences, fondly noting that Wilkes managed to outlive his own autobiography by about a dozen years. - Stroustrup emphasized the profound cultural impact of institutions like Cambridge and Bell Labs: “One of the things that Cambridge could do and later Bell Labs can do is somehow raise people's expectations of themselves, raise the level that is considered acceptable.” Immersed in an environment where elite researchers produce exceptional work with apparent ease and constant courtesy, one is compelled to elevate their own standards of ambition and output.
---
[24:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1448s) Defining the Ph.D. Problem: Capability Hardware and Distributed Systems
On Stroustrup’s first day in Wheeler’s office, Wheeler challenged him by asking if he knew the fundamental difference between a master's thesis and a Ph.D. dissertation. When Stroustrup answered no, Wheeler clarified: “If I have to tell you what to do, it's a master's.”
Wheeler had temporarily forgotten that Stroustrup already possessed a master's degree from Aarhus and warned him gravely that failing out with only an English master's degree was a fate worse than death. Stroustrup was able to wait out the warning before calmly informing Wheeler that he had no need for another master's. It took Stroustrup roughly a full year of exploration to independently formulate his doctoral research topic.
Ultimately, his research focused on distributed computing, motivated by his previous work on microprogramming and hardware architecture: - He sought to construct architectural hardware support to enforce clean software modularity and facilitate secure communication between hardware-protected entities. - Cambridge had already designed and constructed the CAP Computer—spearheaded by Maurice Wilkes, David Wheeler, and Roger Needham—which featured hardware-based capability protection. - Stroustrup aimed to generalize these protection mechanisms beyond a uniprocessor, expanding the capability model across multiple processors sharing a single machine, and eventually across multiple discrete computers joined by a local area network. - Because multiprocessor configurations were virtually non-existent in the academic wild at the time and networks were prohibitively expensive, acquiring physical hardware to validate these ideas directly was impossible, forcing him to tackle the problem through software modeling and distributed systems simulation.
[26:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1592s) Cambridge PhD Simulator: From Simula to BCPL
While Bjarne Stroustrup was at the University of Cambridge, the department built its first distributed hardware, but when he initially began his research, no such machine existed. Consequently, he had to simulate it instead, keeping his focus on systems software and hardware issues. Having learned Simula in Aarhus—largely through extensive discussions with Kristen Nygaard—Stroustrup wrote his simulator in Simula. However, running the simulation brought the university mainframe to its knees before producing any meaningful data. Stroustrup notes that this is typical of simulations: you increase the data, entities, or duration until memory and CPU are exhausted. For a graduate student, doing that even once risked being kicked off the shared machine, especially when competing against chemists and astrophysicists who held vastly superior funding and political clout.
Faced with losing mainframe access, Stroustrup migrated his work to the Cambridge CAP computer, a capability-based machine with an unusual and beautiful architecture. Because it ran obscure programming languages, the CAP kept astrophysicists, chemists, and most computer scientists away. Stroustrup evaluated Algol 68C (Algol 68 without garbage collection) and BCPL. Having already implemented BCPL in hardware, he was adept at it and chose to rewrite the entire simulator from Simula into BCPL. The transition was agonizing: the high-level organization and clean structure that had made Simula pleasant to design and debug vanished completely. Yet, after painful debugging that cost him "half of my hair," the resulting BCPL implementation ran extraordinarily fast, had direct access to every system resource, and delivered the data needed to complete his PhD.
```mermaid flowchart TD accTitle: Trade-off between Simula and BCPL in Stroustrup's PhD Work accDescr: Diagram illustrating the contrasting trade-offs between Simula and BCPL that inspired the dual philosophy behind C with Classes and C++. subgraph Simula["Simula Simulator (Mainframe)"] S1["High-level abstractions & clean structure"] S2["Crushed mainframe memory & CPU"] S3["Kicked off machine by funded departments"] end subgraph BCPL["BCPL Simulator (CAP Machine)"] B1["Lost high-level modular structure"] B2["Painful, hair-pulling debugging"] B3["Direct hardware access & fast execution"] end Simula -->|"Rewritten onto CAP"| BCPL BCPL --> Result["Guiding Light: Good code must be fast code (Core thesis of C++)"] ```
This stark contrast cemented a permanent philosophy for his career. As Stroustrup formulated his key design principle: > “If you give people the choice of writing good code or fast code, there's something wrong; good code should be fast.”
- Stroustrup completed his PhD determined never again to tackle a problem with fundamentally unsuitable tools, refusing to accept an artificial trade-off between elegance and efficiency. - He left Cambridge still intending to dedicate his career to designing computers and building operating systems.
---
[30:38](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1838s) Career Decisions, Denmark, and the Bell Labs Interview
Following graduation, Stroustrup had no desire to enter academia. He viewed university teaching as a trap for bright individuals and believed there was an inherent flaw when a teacher's only prior job had been being a student, arguing: > “It's incestuous; there has to be some real world in there somewhere, and often there isn't for teachers and professors, and that weakens what is being taught and it weakens the credibility of the teacher.”
He explored industry opportunities back in Denmark, which he considered one of the finest places to live, but ran into cultural and intellectual friction. At the time, the prevailing Danish attitude assumed that anything worth doing was already being done there; since his distributed systems work was not being done, it was viewed with skepticism. Danish university openings were dominated by candidates waiting in line doing fashionable work. The local job offers were uninspiring: one position involved writing COBOL, while another for a government branch seemed to consist of counting submarines in the Øresund strait off Copenhagen.
Instead, a fortuitous interaction in Cambridge provided a different route. At The Eagle pub, where researchers gathered for a pint after work, either Steve Bourne or Sandy Fraser—both connected to the Computer Science Research Center at Bell Laboratories—told him to reach out if he ever needed a job. Stroustrup contacted them and arranged to fly over to the United States, paying his own travel expenses. When he arrived, jet-lagged and low on funds, Sandy Fraser greeted him abruptly: > “Sit down... you come at a bad time; we don't have any jobs.”
Rather than beginning at the Computer Science Research Center, Stroustrup was routed to a development-oriented group to deliver his presentation. The talk was so successful that they reversed course on the spot, drove him directly back, and put him through a full interview circuit in the research center. A week later, he received an offer, beginning a 16-year tenure at AT&T Bell Labs.
---
[34:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2069s) The Genesis of C with Classes: Marrying Simula and C
Arriving at Bell Labs, Stroustrup believed that the institution's abundant talent and hardware would finally allow him to construct the distributed modular operating system he had envisioned. The environment was rich with Unix pioneers: Ken Thompson, Dennis Ritchie, Brian Kernighan, Doug McIlroy, and Greg Chesson. At the time, everyone shared a single PDP-11/70, but multiprocessors and networking were on the horizon. Stroustrup set out to decompose the Unix kernel services into distinct modules that could run either across a shared-memory multiprocessor or over a network.
Within a couple of months, he discovered he was repeating his Cambridge mistake. C was the lingua franca of Bell Labs, but it lacked language-level constructs to declare module boundaries or specify what state was private versus shared; everything relied on poking directly into memory. At the same time, Algol 68 was virtually unused in that environment, whereas Dennis Ritchie and Brian Kernighan were right down the hallway to provide definitive answers about C.
To realize his design, Stroustrup needed a language offering both high-level modularity and direct hardware efficiency. Simula possessed the abstraction concepts—classes, inheritance, and object orientation—pioneered by Kristen Nygaard, but its runtime was heavy, and its compiler was expensive, difficult to port, and incapable of low-level machine manipulation. Conversely, C offered unmatched hardware access and runtime efficiency but lacked modular abstractions. Stroustrup realized he could not graft hardware access onto Simula, so he chose the inverse: grafting Simula's abstraction mechanisms directly onto C. This hybrid became "C with Classes," which evolved into C++.
- The language was designed around two fundamental pillars: direct hardware manipulation and high-level abstraction mechanisms that let programmers step away from low-level details. - Although initially built as a personal tool for his distributed systems research, Stroustrup engaged with colleagues across Bell Labs, listening to their problems and refining his designs based on real-world use cases.
[39:56](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2396s) Early Design Decisions: Prototypes, RAII, and Value Semantics
Reflecting on the earliest days of the language, Bjarne Stroustrup recalls several critical decisions that laid the bedrock for what was to come. First was the introduction of what are now known as function prototypes. Stroustrup found the lack of argument checking and conversions in C completely unacceptable: “The idea of square root of two not being a valid program was just no that that that can't happen.” When he complained about this limitation in C, Sandy Fraser gave him a simple challenge: “Why don't you just fix it?” So he did.
```mermaid flowchart LR accTitle: Core Early Design Pillars of C++ accDescr: Three foundational features implemented early on: function prototypes, constructors/destructors, and unified value semantics. A["Function Prototypes"] --> D["Rock-Bottom Core"] B["Constructors & Destructors (RAII)"] --> D C["Unified Value Semantics"] --> D ```
Second, Stroustrup's earliest notes dictated that classes required a constructor to acquire resources and establish an invariant, paired with a destructor to clean up when an object's lifetime ended. Third, he made a fundamental departure from languages like Simula by refusing to create a sharp divide between built-in types and user-defined types. In Simula, user-defined types had reference semantics and lived on the free store, whereas built-in types lived on the stack. Stroustrup was adamant that user-defined types should have first-class value semantics without forcing dynamic allocation. He questioned why an integer could be a local variable, but a complex number had to be allocated with `new` on the free store. Quoting Doug McIlroy from that era, Stroustrup notes: “There's nothing abstract about a complex number; it's as real as reals.” Within the first weeks or months, the language possessed type-checked function interfaces, classes with constructors and destructors, and direct support for value semantics.
- Function prototypes were created to enforce proper interface argument checking and implicit conversions. - Constructors and destructors were introduced together very early to establish invariants and handle automatic cleanup. - Rejection of the mandatory reference/pointer split found in Simula for user-defined types allowed user types (e.g., complex numbers, points, sockets, matrices) to be allocated directly on the stack.
---
[42:51](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2571s) Memory Models, Simula's Limitations, and Rejecting ALGOL 68
Paul McJones remarks that while the early 1970s saw intense research into abstract data types and extensible languages, most designers got sidetracked by inheritance and reference-oriented models, leaving Stroustrup as virtually the only one who pursued built-in-style value semantics for custom types. Stroustrup explains that this was a deliberate reaction against Simula's design. When he asked Kristen Nygaard why Simula forced user-defined types onto the heap, Nygaard told him that was simply the only way they could make the garbage collector work. Similarly, when Stroustrup asked Ole-Johan Dahl why Simula lacked multiple inheritance, Dahl replied: “I couldn't build an efficient garbage collector if I had multiple inheritance.”
Operating at the lowest levels of system programming, Stroustrup could not afford the overhead of a garbage collector. He wanted stack allocation because it combined peak runtime efficiency with automatic, deterministic resource management via destructors. While C already had value semantics at its base, Stroustrup considered applying these ideas to ALGOL 68 instead, but dismissed the idea because ALGOL 68 had failed to gain traction: “I wanted to do it to ALGOL 68 but decided that would be a really dumb idea, uh because nobody else liked uh um ALGOL 68, and if you wanted to do something practical, if you wanted to have an impact in the world, which I did, you have to do something that other people can understand.”
- Dahl and Nygaard constrained Simula's feature set (e.g., omitting multiple inheritance and forcing user types into heap storage) strictly to accommodate garbage collection. - Stroustrup prioritized stack allocation for both raw efficiency and deterministic lifetime control. - ALGOL 68 was bypassed as a host language because it lacked practical popularity and broad industry adoption.
---
[46:12](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2772s) From Research to One-Man Support Desk: The Shift to Language Work
Although Stroustrup had originally begun the project to write simulations for his research on distributed Unix architectures, real users adopted C with Classes within six months. As usage spread, his priorities were forced to shift dramatically: “When you have users you have responsibilities and you have to make sure sure that their projects succeed.” He found himself spending increasing amounts of time writing documentation, authoring tutorials, fighting bushfires, teaching, and bootstrapping user projects.
Consequently, Stroustrup never got around to building the distributed operating system he had envisioned, remarking that otherwise, “we might have Unix clusters and Unix multicores about '85.” Instead, he became a solo operation handling language design, implementation, and user support: “For the next 10 years I was doing this combination of language design and support of users. I mean I was the help desk for a long time.” Unlike other Bell Labs projects like Unix or C, where documentation and tooling were shared across multiple contributors, Stroustrup carried almost the entire burden alone.
- The first external user began using C with Classes approximately six months after its inception. - User support commitments derailed Stroustrup's planned research on distributed kernel architectures. - Stroustrup personally authored roughly 98% of the codebase, documentation, build scripts, and test suites for early releases.
---
[48:03](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2883s) Release 1.0, The "Brown Bag" Tape, and Cfront Cross-Compilation
Around 1984 and 1985, educational and tailored releases were provided to universities, leading up to the October 1985 commercial launch of C++ Release 1.0, nicknamed the "Brown Bag" release. For academic institutions, AT&T charged a nominal $75 fee to cover the physical cost of writing and shipping a magnetic tape. Commercial source licenses were sold for around $40,000, allowing companies to inspect and modify the source.
```mermaid flowchart TD accTitle: Cfront Portability Architecture accDescr: Process showing how Cfront used a target probe program to achieve cross-compilation to foreign C environments. subgraph Probe["Target Probing"] A["Probe program on Target Machine"] -->|"Runs on target"| B["Collects target specs (sizes, signs)"] B -->|"Mailed back"| C["Machine Description File"] end subgraph Compilation["Cross-Compilation via Cfront"] C -->|"+x option"| D["Cfront Compiler"] E["C++ Source"] --> D D --> F["Target-adapted C code"] F --> G["Native Target C Compiler"] end ```
To prevent the language from being locked into a single machine architecture, Stroustrup engineered his compiler, Cfront, as an adaptable cross-compiler that generated intermediate C code to leverage existing backends, debuggers, and tools. To overcome subtle incompatibilities across host C compilers, Stroustrup developed an automated probing technique: 1. A small probing program was run directly on the target machine. 2. The probe measured target-specific characteristics, such as the size of integers and pointers, and whether `char` was signed or unsigned. 3. The probe wrote out a configuration file, which was mailed back and passed into Cfront using the `+x` compiler flag to reconfigure its code-generation assumptions.
While complex or unusual architectures like Cray supercomputers or Univac mainframes required up to a month of porting effort, porting Cfront to typical Unix environments was regularly reduced to about three hours. Stroustrup notes that although they did not provide prebuilt binaries for all 20-plus target architectures on the physical distribution tapes, the flexibility of the generated C allowed users to rapidly bootstrap the compiler virtually anywhere.
- Educational distribution cost: $75 per magnetic tape; commercial source licenses: approximately $40,000. - Commercial 1.0 release occurred in October 1985, nicknamed the "Brown Bag" release. - Cfront utilized intermediate C code generation to hijack native platform toolchains. - The `+x` flag allowed Cfront to switch its internal machine model dynamically based on probe-generated configuration files. - Ports to mainstream architectures typically completed in roughly three hours, though unusual architectures like Cray or Univac took up to a month.
[53:07](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3187s) Operator Overloading, Value Semantics, and Virtual Functions in Early C++
During the transition from C with Classes to C++ in the winter of 1983–1984, Bjarne Stroustrup focused heavily on operator overloading to achieve true value semantics, particularly for user-defined assignment. While popular demand later favored arithmetic operators such as `+` and `-`, the initial impetus came from colleagues performing hardware and machine simulations who urgently needed bitwise operators like `&`, `|`, and `^`. Around the same time, Stroustrup introduced overloading for the subscript operator `[]` and the function call operator `()`. These additions proved foundational, directly paving the way for standard container types and modern function objects (functors).
Concurrently, Stroustrup introduced virtual functions, a mechanism he had learned from Simula. However, he encountered deep skepticism from colleagues accustomed to procedural systems programming. As Stroustrup recalled, “The attitude was: you want to call a function and you don't know which one it is, haven't you analyzed your problem?” Critics argued that if indirection was genuinely necessary, programmers should simply wire up function pointers manually. Stroustrup countered that managing manual function pointers could not scale across large projects or be taught cleanly. Along with dynamic dispatch, he added class hierarchies with multiple inheritance because he felt it was necessary. Reflecting on years of criticism, Stroustrup observed that multiple inheritance of interfaces eventually became ubiquitous across modern object-oriented languages, with platforms like Java 8 eventually admitting forms of multiple inheritance of implementation as well.
- **Key overloaded operators added in 1983–1984:** Bitwise operators (`&`, `|`, `^`) for hardware simulations, assignment (`=`) for value semantics, subscripting (`[]`) for containers, and invocation (`()`) for function objects. - **Resistance to virtual functions:** Peers believed indirection revealed incomplete problem analysis and favored explicit C-style function pointers. - **Multiple inheritance vindication:** Stroustrup noted that while he spent decades being told multiple inheritance was an outright design error, virtually all contemporary languages with interface definitions rely on multiple inheritance of interfaces.
---
[55:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3337s) The Need for Generics and the Birth of Templates
After shipping C++ Release 1.0 and Release 1.2, Stroustrup finally had time to step back from nonstop operational demands to think deeply about error handling and generic types. The conceptual need for parameterized types had been present from the earliest paper on C with Classes, where Stroustrup had argued that developers needed a generic `Vector<T>` rather than separate vector classes for integers and doubles. However, his initial approach relied on the C preprocessor. Stroustrup reflected on this misstep: “Again, macros is one of these solutions that works for one or two guys working closely together and knowing what they're doing; it does not scale.”
To replace preprocessor hacks, Stroustrup formulated three foundational design goals for what would become C++ templates:
1. **Generality:** Stroustrup recognized that a language designer cannot anticipate every use case. Having suffered under languages that strictly limited programmers to what the language creator deemed proper, he made templates completely open-ended. 2. **Zero-overhead performance:** The mechanism had to adhere strictly to Stroustrup's zero-overhead principle: “That is, once you use an abstraction mechanism, you run as fast as the best hand-coded alternative in the basic language.” In particular, Stroustrup wanted an abstraction that could put raw C arrays out of business. Because built-in C arrays are merely fixed sequences of memory that decay into untyped pointers at the slightest excuse, they are one of the most prolific sources of software bugs. To replace them, an abstraction like `std::vector` had to match raw memory layouts and array access speeds without incurring any runtime penalty. 3. **Decent interfaces:** The mechanism needed clean, modular interface specifications to validate generic type arguments.
```mermaid flowchart TD accTitle: Three Original Design Aims of C++ Templates accDescr: Diagram illustrating Generality, Zero-Overhead Performance, and Constrained Interfaces, noting the delayed resolution of Interfaces via Concepts.
subgraph Aims["Template Design Aims (1988)"] G["1. Generality<br/>(Open-ended; avoid designer paternalism)"] P["2. Zero-Overhead Performance<br/>(Match hand-coded C arrays; no runtime cost)"] I["3. Well-Defined Interfaces<br/>(Modularity and parameter checking)"] end
G -->|"Achieved in C++ 1988"| Impl["C++ Templates Engine"] P -->|"Achieved in C++ 1988"| Impl I -->|"Compromised: Vtables too slow, macros unmanageable"| Postponed["Postponed Design Problem"] Postponed -->|"30+ years of evolution"| Concepts["C++ Concepts Technical Specification (2015)"] ```
---
[58:45](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3525s) The Challenge of Constraining Interfaces and the Evolution of Concepts
Because achieving all three template goals simultaneously seemed impossible in the late 1980s without introducing runtime jump tables or messy macros, Stroustrup chose to prioritize generality and zero-overhead performance, reluctantly compromising on interface specification. This omission led to decades of notoriously impenetrable template compiler diagnostics and complex metaprogramming code. Attempts to resolve this in the early 2000s were derailed when proposals tried to make generic interfaces behave like object-oriented abstract classes or Haskell-style type classes, both of which rely on dynamic dispatch tables that compilers struggle to optimize away in large industrial codebases.
Stroustrup highlighted that after more than thirty years in gestation, constrained interfaces were finally becoming reality via Concepts. Work by Andrew Sutton (Stroustrup’s former postdoctoral researcher, later a professor at the University of Akron), Alex Stepanov, Paul McJones, and Stroustrup himself produced a streamlined design that avoided the performance traps of virtual dispatch. The C++ Standards Committee had just voted out the Concepts Technical Specification for a National Body vote, with an experimental implementation already functional in a GCC branch. Stroustrup expressed absolute confidence in its approval: “The C++ standards committee has never lost a national body vote; as a matter of fact, we have never had a negative vote in a national body vote.”
- **The compromise of 1988:** Unconstrained templates shipped without formal type interfaces, sacrificing clear compile-time error reporting to safeguard execution speed. - **Failure of the 2002 concepts effort:** Earlier attempts pushed C++ generic interfaces toward Haskell type classes or traditional object-oriented virtual tables, which could not be reliably inlined or optimized away in large-scale builds. - **Collaborative realization:** The modernized Concepts model emerged from Stepanov's foundational generic programming principles, Sutton's compiler implementation in GCC, and Stroustrup's focus on syntactic simplicity.
---
[01:02:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3749s) Zero-Overhead Abstractions, Fortran Lineage, and the Economics of Scale
Paul McJones observed that Stroustrup’s zero-overhead principle shares a direct philosophical lineage with John Backus’s work on the original Fortran compiler: “John Backus had a goal that he wanted a language that scientists and engineers could express their problems in, but that the professional assembly language programmers of the time could not do better hand optimization, and he was actually able to achieve that.” Stroustrup agreed, noting that achieving such efficiency requires balancing clean language constructs with an uncompromising compiler optimization model.
Addressing modern hardware trends, Stroustrup pointed out that contemporary smartphones and desktop computers possess thousands of times more compute capacity and memory than the PDP-11 or VAX systems on which C with Classes and early C++ were built. While everyday software can easily afford to waste 95% to 99% of available CPU cycles on high-level overhead, infrastructure software cannot. At the foundational layers of technology—graphics pipelines, networking stacks, digital signal processing, and hyperscale data centers—efficiency directly dictates cost and hardware footprints.
Stroustrup stressed that for companies operating on the scale of Google or Facebook, language performance translates immediately into physical server farms, electrical cooling, maintenance overhead, and real-world capital expenses: “If you look at Google or Facebook and their server farms, if you use a language that's half the raw performance, you need twice as many server farms.” For the core systems that run the modern world, a 2x, 4x, or 10x performance margin remains the decisive reason C++ continues to thrive.
[01:05:33](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3933s) The Reluctant Push into ANSI/ISO Standardization
Paul McJones turns the conversation to the origins of C++ standardization, asking Bjarne Stroustrup how he came to the conclusion that the language needed an official standard. Stroustrup clarifies with a chuckle that he did not actually initiate the effort himself: “No, I did not decide that we needed to standardize.” Instead, representatives from industry showed up uninvited at his office—Dmitry Lenkov from Hewlett-Packard alongside an engineer from IBM whose name Stroustrup cannot immediately recall. They informed him that they wanted ANSI standardization for C++. Stroustrup pushed back, arguing that the language was still evolving, incomplete, and simply not ready.
```mermaid flowchart TD accTitle: The Origins of C++ Standardization accDescr: Flowchart showing how industry pressure forced Bjarne Stroustrup to accept formal standardization.
subgraph ExternalPressure["Industrial Pressure"] A["Dmitry Lenkov (HP) & IBM representative"] B["Argument: 'Bus factor' risk in major corporate use"] A --> B end
subgraph Resistance["Stroustrup's Objections"] C["Language is not finished"] D["Needed more time to develop features"] C --- D end
subgraph Concession["Compromise & First Meeting"] E["'Arm-twisting' forces concession: agree to next year"] F["First ANSI meeting convenes in December 1989"] E --> F end
B -->|"confronts"| Resistance Resistance -->|"overruled by"| E ```
The visitors countered with a pragmatic corporate argument: major enterprises could not adopt a programming language where the entire design and implementation team could disappear overnight if someone got run over by a bus. Despite their polite phrasing, they applied steady pressure until Stroustrup gave in: “They sort of they twisted my arm a bit more and in the end I went ow ow ow yes I'll do it I'll do it we'll do it next year.” Although they initially agreed to wait until the following year, the process moved fast enough that the very first standards committee meeting convened in December. Stroustrup readily acknowledges that while he was too absorbed in his own technical work to see it at the time, their insistence on formal standardization was fundamentally the correct strategic move for the survival and industrial adoption of C++.
- Industrial delegates: Dmitry Lenkov of HP and an unnamed representative from IBM. - Core business justification: Mitigating the "bus factor" for enterprise adoption. - First organizational meeting: December (1989).
---
[01:07:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4045s) The Mechanics, Chaos, and Politics of Committee Design
Stroustrup candidly describes ANSI and later ISO standardization as “a huge pain in the neck with lots and lots of people involved.” He observes that the committee frequently suffered from a lack of unified vision. Some factions actively tried to stall change in the name of stability, wanting others to take the risks of innovation; others chased the latest industry fads. Throughout the 1990s, one camp constantly pushed to make C++ a pure object-oriented language by completely stripping away its C heritage, while a competing camp cared nothing for object-oriented paradigms and fought to keep it strictly aligned with raw C. Balancing stability and ongoing evolution proved excruciatingly difficult.
Stroustrup reflects that the process would have run much smoother had there been dedicated resources for an evolution or language-design sub-team working full-time on future architectural directions, leaving the broader plenary committee to polish wording, check details, and resolve compatibility edge cases. Instead, the committee split informally between forward-looking thinkers and members focused on immediate, everyday problems, with no budget or staff to run serious validation experiments. While modern innovations like parallel study groups (SGs) have helped organize domain-specific work, they introduced fresh communication overhead between internal subgroups.
- Standards bodies: ANSI, followed later by ISO. - 1990s committee factions: Pure object-oriented proponents seeking to purge C semantics versus C traditionalists resisting OOP abstractions. - Structural limitation: Lack of institutional funding or dedicated full-time resources for empirical language design experiments.
---
[01:09:41](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4181s) The Burden of the Lone Designer on a Standards Committee
McJones asks Stroustrup what it felt like emotionally to remain the principal designer while an open committee proposed and altered language features—likening it to watching a daughter grow up and get married. Stroustrup rejects the analogy, admitting that the reality was far more grueling: “It's nice when people improve things; it's really painful when people try and take the language into a direction I really disagree with and then then you have to stop.” He recounts the friction of advocating for designs he was certain were correct, only to be met with committee resistance, demands for unnecessary elaboration, or calls to follow passing trends.
Although he concedes that the committee’s brakes occasionally stopped him from pursuing directions that might have proven mistaken in hindsight, the sheer volume of proposals meant that suboptimal compromises inevitably slipped through. He notes that almost no other programming language operates under this dynamic: most languages either rely on a benevolent dictator for life (BDFL) or hand control over to a committee that is completely divorced from the original designer. Enduring the full standards process as the original designer is an exhausting, largely underappreciated ordeal, but Stroustrup maintained his active presence because he considered it vital for safeguarding the language's core integrity.
- Governance models compared: Benevolent Dictators for Life (BDFLs), independent bureaucratic committees, and the C++ model of original-designer participation. - Committee dynamics: Friction between minimalist design and political compromises that add excessive elaboration.
---
[01:11:38](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4298s) Modern C++ (C++11/C++14): Making Simple Things Simple
Looking at C++11 and C++14, Stroustrup expresses great satisfaction with the language's current trajectory, noting that modern versions provide far superior tools. Much of this success stems from his long-standing design maxim: “Simple things should be simple and complicated things well they'll have to be a little a little bit more complicated and I hate making anything impossible.” Popular adoption in C++11 has been driven less by complex technical additions and more by everyday ergonomic features that eliminate boilerplate, reduce repetition, and prevent trivial bugs.
Among these features is the range-based `for` loop and type deduction via `auto`. Stroustrup recalls that he had actually implemented a version of `auto` as early as 1983 or 1984, but was forced to remove it due to compatibility concerns with C's storage-class specifier and because contemporary programmers simply did not grasp what it was for. He also highlights coroutines as another foundational concept from his earliest work in the 1980s that is finally resurfacing for future standardization. While he cautions against the extreme modern obsession with minimizing keystrokes—pointing out that source code is read far more often than it is written and must retain semantic clues—he agrees that traditional C++ had grown far too verbose.
```mermaid flowchart LR accTitle: Syntax Simplification with Concepts accDescr: Comparison of verbose C++98 template declaration syntax versus the simplified Concepts syntax.
subgraph VerboseSyntax["Traditional C++98 Template Declaration"] direction TB A["template<typename I>"] B["void sort(I first, I last);"] A --> B end
subgraph ConceptsSyntax["Concepts-Based Terse Syntax"] direction TB C["void sort(Sortable& c);"] end
VerboseSyntax -->|"simplified by Concepts to look like 1982 function syntax"| ConceptsSyntax ```
As a primary example of simplifying without sacrificing rigor, Stroustrup points to Concepts. Rather than requiring dense, unconstrained template boilerplate like `template<typename I> void sort(I first, I last);`, Concepts allows clean, terse signatures such as `void sort(Sortable& c);`, echoing the clarity of the earliest function declarations from 1982. He explains that Concepts generalizes beyond single-type constraints: multi-type concepts, like a `Mergeable` constraint across input and output streams (`mergeable(I1, I2, Out)`), express precise mathematical relationships directly in the type system.
When McJones suggests that the terseness of C++11 and C++14 gives it the feel of a scripting language, Stroustrup pushes back on the terminology. He emphasizes that modern C++ is more strongly and statically typed than ever before. Rather than adopting the dynamic duck-typing found in scripting languages, Concepts grounds template programming in formal interface-based contracts, providing expressive brevity without losing compilation safety or hardware-level performance.
- Historical features restored: `auto` type deduction (originally built in 1983–1984; removed for C compatibility) and coroutines (rooted in his early Simula-inspired work). - Modern syntax additions: Range-based `for` loops and Concepts for constrained template signatures. - Readability philosophy: Code should not be compressed to absolute minimal keystrokes at the expense of comprehension, because software is read far more often than it is written.
---
[01:16:01](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4561s) Early Collaborations with Alex Stepanov
McJones brings up Alexander Stepanov and the development of the Standard Template Library (STL), inviting Stroustrup to explain how their relationship began. Stroustrup recounts that their interactions began well before the STL took its final form, during a period when Stepanov worked at AT&T (following an earlier stint at General Electric).
During their initial discussions at AT&T, Stepanov was programming primarily in Ada and tried to persuade Stroustrup to adopt Ada's model of generics for C++. While Stroustrup respected Stepanov’s rigorous mathematical foundations and learned a great deal from him, he refused to adopt Ada’s mechanics. In particular, Stroustrup was adamant that generic programming in C++ should not require explicit instantiation statements for every type, nor would he accept Ada's rigid restrictions preventing implicit conversions. Stroustrup notes that they maintain a philosophical disagreement to this day regarding mixed-mode arithmetic: Stroustrup firmly believes that multiplying a `double` by an `int` should work seamlessly, even inside complex generic code, despite the subtle design trade-offs and complexity that conversions introduce.
- Early affiliations: Alexander Stepanov worked at GE and AT&T prior to developing the STL. - Primary vehicle: Stepanov originally formulated his generic programming algorithms in Ada. - Fundamental design divergence: Stroustrup rejected Ada-style mandatory instantiation statements and supported mixed-mode arithmetic conversions in generic contexts.
[01:17:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4645s) The Arrival and Design Philosophy of the STL
Bjarne Stroustrup describes how his collaboration with Alexander Stepanov shaped his thinking. Stepanov demonstrated the critical need to preserve type information and allow the compiler to inline everything—an approach that matched Stroustrup's design philosophy: “This completely plays into my zero overhead um bias in in design.” After Stepanov departed and Stroustrup implemented the initial language support for templates, Andrew Koenig brought Stepanov's work on the Standard Template Library (STL) to Stroustrup's attention.
Initially, Stroustrup was skeptical. Like the prevailing mindset of the era, he assumed container libraries had to be fundamentally object-oriented, structured around deep inheritance hierarchies of containers and iterators. The STL looked alien:
> “And to be honest I thought it looked really ugly and it certainly looked completely wrong uh like everybody else at the time I had gotten this idea that that things had to be object oriented in the container world and you had to have a hierarchy of containers and you had to have a hierarchy of iterators...”
Upon examining the library closely, Stroustrup recognized that the STL was fundamentally different because it was built on generic programming and the implicit concept of Concepts, even though the core C++ language lacked explicit syntax to define concepts at the time. From a machine standpoint, it fulfilled the zero-overhead principle by generating efficient machine code. Moreover, it was not merely a container library, but an integrated framework of algorithms and containers—or as Stepanov saw it, an algorithm library that also provided containers.
```mermaid flowchart TD accTitle: Paradigm shift from OOP containers to STL accDescr: Comparison between standard 1990s OOP container hierarchies and Stepanov's STL design.
subgraph OOP["Conventional 1990s OOP Approach"] direction TB Base["Base Container / Iterator"] --> Derived["Polymorphic Subclasses"] Derived --> Overhead["Virtual dispatch, boxing, type loss"] end
subgraph STL["Stepanov's Generic Approach (STL)"] direction TB Algorithms["Generic Algorithms"] <--> Iterators["Iterators (Concepts)"] Iterators <--> Containers["Zero-Overhead Containers"] Containers --> CodeGen["Inlined, high-performance machine code"] end ```
Stroustrup evaluated the design against an 11-point checklist (later published in *The C++ Programming Language*, 3rd Edition) that he had assembled over years of analyzing container architectures: - The STL satisfied 10 of his 11 criteria (or perhaps 12 of 13). - The single missing requirement was a common root interface across all containers and iterators to simplify debugging, serialization, or common runtime queries. - Despite lacking that common base and looking unconventional, no other library had ever matched nearly all of his criteria while providing such expressive algorithm abstractions.
---
[01:20:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4837s) Navigating Committee Politics to Standardize the STL
Realizing the technical superiority of the STL, Stroustrup and Andrew Koenig resolved to bring it before the ISO C++ standards committee, despite long odds. Stepanov attended meetings to present his vision directly. Stroustrup recalls him as an “absolutely first rate rabble-rouser” who energized the committee like no one else.
Nevertheless, adoption faced fierce institutional pushback. The library was seen as complex and unreadable by members accustomed to classical OOP design. A turning point came when Beman Dawes, later a co-founder of the Boost libraries, intervened during a meeting where detractors were dismissing the library's perceived difficulty:
> “...When people were being somewhat rude about the STL and this complexity and this difficulty and it ugliness he spoke up and says you know I thought that too but since the last meeting I just thought I would try and see what it was and I implemented about a tenth of it and you know you're wrong it's not that complicated it's relatively easy to do and it's cleaner than what we're doing...”
Another hurdle was industry competition. Nearly every major vendor had built a proprietary object-oriented container hierarchy. When Texas Instruments prepared to propose their corporate OOP container framework immediately following a lunch session, word circulated quickly: - Within hours, at least five other major vendors—including IBM, Microsoft, Borland, and GNU—insisted that if one corporate class hierarchy was considered, their own container hierarchies had to be considered as well. - This corporate deadlock made an object-oriented library standard politically impossible. - Because the STL was radically different, algorithm-centric, and vendor-neutral, it avoided the corporate stalemate and was accepted into the draft standard after roughly two years of concerted effort.
---
[01:23:44](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5024s) Concepts and Restraining Template Metaprogramming with `constexpr`
The widespread adoption of the STL generated acute pressure to introduce explicit language-level Concepts. The need arose primarily from two defects: incomprehensible compiler error messages and the uncontrolled proliferation of compile-time duck typing. Without formal interfaces, template implementations frequently leaked details through instantiation errors, making template code exceedingly difficult to reason about and maintain. Stroustrup envisioned Concepts as the formal interface mechanism for generic programming and template metaprogramming, while acknowledging that certain fringe techniques, such as expression templates, rely on syntactic transformations that do not easily map to semantic concepts.
Concurrently, programmers discovered that C++ templates could evaluate compile-time values rather than just generating types, spawning esoteric and difficult template metaprogramming tricks to compute values such as constants or lookup tables. In response, Stroustrup and Gabriel Dos Reis designed `constexpr` functions:
> “And Computing a value you just use a function I mean we know how to do that that should be just that... We really wanted ordinary functions where you give arguments of a given set of possible types and you generate results in the appropriate thing and that's that's all it should be like we're back learning our first function...”
```mermaid flowchart LR accTitle: Evolution of Compile-Time Evaluation in C++ accDescr: Shift from macros and template metaprogramming tricks to constexpr functions.
subgraph Legacy["Historical Workarounds"] direction TB M["Preprocessor Macros (Typeless)"] TMP["Template Metaprogramming (Duck-Typed Hacks)"] end
subgraph Modern["Modern Clean Alternatives"] direction TB CE11["C++11 constexpr (Pure, Single Return)"] CE14["C++14 constexpr (Loops, Local State)"] Concepts["Concepts (Type & Interface Constraints)"] end
Legacy -->|"Replaced by"| Modern ```
Stroustrup outlines the evolutionary trajectory and constraints of `constexpr`: - **Alternative to macros and TMP:** Embedded developers historically relied on untyped preprocessor macros, while template authors relied on duck-typed recursive templates; `constexpr` replaces both with standard, type-safe functions. - **Language standards progression:** Introduced in C++11 with single-expression constraints, `constexpr` expanded significantly in C++14 to permit loops and local mutable state during evaluation. - **Purity rules:** Because compile-time execution runs before the rest of the runtime program state exists, `constexpr` functions must be pure and free of external side effects; any mutable state can only exist temporarily during compile-time execution. - **Dual-pronged modernization:** Concepts constrain the generic types, while `constexpr` reclaims value computation back into clean, traditional function syntax.
---
[01:28:07](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5287s) From Function Objects to First-Class Lambdas
Stroustrup connects the rise of functional programming styles in C++ to its historical foundations. Function objects—classes that overload the call operator (`operator()`)—date back to 1983 in the language's development:
> “So a function object in C++ is is is something with an application operator H Lambda is something that generates a function object in place and evokes it invokes it when necessary so it's a it's a shorthand notation for function objects that we'd had all the time and they run as fast as uh function objects possibly even faster if you do trickery with with stack frames...”
- **Function objects in the STL:** Stepanov's STL made heavy use of function objects because they enabled parameterization of algorithms with custom operations while remaining aggressively inlinable by the compiler. - **Lambdas as syntactic shorthand:** Modern C++ lambdas are essentially a direct, in-place syntax for generating anonymous function objects. - **Execution speed:** Because lambdas boil down to inlineable function objects with captured state, their performance matches or exceeds traditional function objects, providing modern C++ with an expressive and efficient functional programming model.
[01:29:24](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5364s) Unifying Paradigms and the Roots of Lambdas
Reflecting on how various paradigms converge in modern C++, Bjarne Stroustrup notes that the programming languages and concepts he studied during the 1970s—abstract data types, object-oriented programming, and direct machine access—are all integrated into a single cohesive framework. Although decades of evolution have accumulated syntactic complications, an underlying internal coherence binds these mechanisms together. For instance, modern lambdas are fundamentally function objects, a design element rooted in C++ long before the feature had dedicated syntactic sugar.
While Stroustrup was well versed in abstract data types, class hierarchies, and close-to-the-metal programming in the 1980s, functional programming was not an area he explored deeply back then. Over the years, functional programming concepts—many originating from the Lisp community—gradually matured and entered mainstream design. Stroustrup emphasizes that as these features were incorporated into modern C++, they were carefully tied back to foundational building blocks that had already existed in the language for decades rather than bolted on as foreign paradigms.
> “I mean that was why I emphasized that lambda is really a function object, and function objects have been there since before day one for C++, so it does fit together.” — Bjarne Stroustrup
[01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) A Language a Tenth of the Size: HOPL-III and Resource Safety
Addressing his retrospective HOPL-III (History of Programming Languages III) paper, Stroustrup elaborates on a central thought experiment: whether one could design a clean, drastically smaller language while preserving the essential spirit, hardware control, and zero-overhead performance of C++. Stroustrup firmly believes it is possible to create an alternative language possessing the same expressive power and raw hardware access as C++, yet measuring only one-tenth the size across any standard metric without degrading performance.
A cornerstone of this vision is comprehensive resource safety, an ambition that goes significantly beyond conventional memory safety. Thanks to move semantics—pioneered largely by Howard Hinnant after years of fragile workarounds—it is now feasible to construct closed systems that guarantee resources are never leaked. To Stroustrup, obsessing exclusively over memory ignores more severe operational failures: leaking system resources like thread handles, file descriptors, mutual-exclusion locks, or network sockets can incapacitate an operating environment far more quickly than an uncollected heap buffer. While garbage collection prevents dangling references, it introduces severe friction when handling pointers to local stack frames that outlive their activation records, a difficult challenge Stroustrup continues to ponder to find a solution that is simultaneously simple, elegant, efficient, and teachable. Crucially, Stroustrup would retain C’s underlying machine model of typed objects and direct pointers mapping to real hardware memory, even if much of C's legacy syntax were discarded.
> “I think we can build a language with the expressive power of C++ and the ability to deal with hardware the way C++ does, that's a tenth of the size measured any way you like for size and without loss of performance.” — Bjarne Stroustrup
> “People talk about memory safety—that is a relatively uninteresting thing; you can kill a system much faster by leaking file handles than any other leak I can think of, including memory.” — Bjarne Stroustrup
```mermaid flowchart TD accTitle: General Resource Safety vs Narrow Memory Safety accDescr: Diagram illustrating Stroustrup's view that true resource safety must govern system handles alongside heap memory.
subgraph Narrow["Conventional Focus"] MS["Memory Safety"] GC["Garbage Collection / Buffer Bounds"] MS --- GC end
subgraph Comprehensive["Resource Safety (Stroustrup's Model)"] RS["System-Wide Resource Safety"] FH["File Descriptors & Sockets"] TH["Thread Handles & Locks"] MO["Move Semantics (RAII)"] HW["Direct Memory & Hardware Model"]
RS --> FH RS --> TH RS --> MO RS --> HW end ```
[01:33:41](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5621s) The Golden Era of AT&T Bell Labs and Its Management Culture
The conversation shifts back to Stroustrup's professional life, beginning with the extraordinary creative epoch at AT&T Bell Laboratories during the 1980s and 1990s. The Computer Science Research Center housed a tight-knit cohort of roughly 30 to 60 scientists, an astonishing fraction of whom went on to become IEEE Fellows, ACM Fellows, and members of the National Academy of Engineering. The culture rested on an explicit philosophy: hire exceptionally smart researchers, give them freedom to pursue problems they found genuinely compelling rather than imposing a command economy, and support them through experienced department heads and directors who maintained organizational balance without stifling autonomy.
Research was sustained through a carefully curated portfolio. Every department was expected to produce tangible accomplishments each year, but that cadence did not restrict scientists to short-term deliverables; researchers were routinely entrusted with five-to-ten-year long bets. Outside of work, Stroustrup raised his children near Murray Hill, New Jersey—a suburban landscape that surprised visitors by its dense canopy of trees rather than industrial stereotypes. The lab environment was collegial and devoid of unnecessary posturing, filled with brilliant scientists who felt no impulse to let enormous egos derail constructive collaboration.
- The Computer Science Research Center maintained between 30 and 60 researchers during its peak years in the 1980s and 1990s. - Management relied on balanced research portfolios that paired yearly deliverables with long-horizon 5- to 10-year investigations. - High-level leadership gave researchers freedom of inquiry instead of enforcing top-down corporate research quotas.
> “Bell Labs, the philosophy that you could let smart people work on things they thought interesting rather than having a command economy, and that you had a management structure that kept that from going out of control—it puts a lot of emphasis on really good department heads, really good directors.” — Bjarne Stroustrup
[01:36:50](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5810s) Wall Street Pressures, Breakups, and the Research Downsizing
The golden era began to unravel when financial markets embraced prevailing management dogmas: the conviction that vertically integrated conglomerates were fundamentally obsolete and the naive assumption that all fundamental technological innovations had already occurred, rendering internal R&D dispensable. First came the broader divestiture of the Bell System, followed later by the split between AT&T and Lucent Technologies. Stroustrup found the rationale perplexing—severing the engineers who manufactured the telecommunication switches from those who wrote the switch software made little sense to someone whose career was anchored in bridging that exact hardware-software boundary.
Following the Lucent split, Stroustrup spent productive years at AT&T Labs–Research in Florham Park, situated across the Great Swamp from Murray Hill. However, the telecom bubble crash, exacerbated by the fallout from the WorldCom accounting scandal, spurred aggressive Wall Street-mandated cost-cutting. Short-term investor sentiment and zero tolerance for research horizons culminated in deep layoffs where roughly 40 percent of the PhD research staff were eliminated in a single sweep. As a department head, Stroustrup learned that two researchers from his own team had been discharged without his prior knowledge or consent—a bureaucratic circumvention likely meant to preempt his fierce resistance. Although Stroustrup retained his position and corner office, the intellectual vibrancy of the institution was gutted, leaving behind a risk-averse workforce after the most outspoken, principled innovators had been driven out.
> “I noticed that the people left behind was on average less interesting than the people that left; the people that left were the troublemakers, the people that would pin down an executive in the corridor and tell him he was all wrong.” — Bjarne Stroustrup
[01:39:23](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5963s) Transition to Texas A&M and Frustrations with Academic Research
With his youngest son graduating high school and heading off to college, Stroustrup decided to embark on a new chapter himself. Having spent 24 years in industrial research, he felt he finally had practical, battle-tested wisdom to impart to students. Encouraged by friends, he accepted a faculty position at Texas A&M University, joining a computer science department eager to advance its national standing. Over his tenure, the department climbed approximately twenty spots in academic rankings as Stroustrup revamped the computer science curriculum, advised PhD candidates, engaged in research, and personally taught both entry-level freshmen and advanced graduate students.
After a decade in academia, however, Stroustrup found aspects of university culture growing stale and detached from industrial reality. He observed a pervasive tendency in academic computer science to detach from practical engineering problems: researchers would abstract an issue from reality, construct a secondary abstraction atop that, and eventually solve an abstraction of an abstraction that bore zero relevance to real computing. He ran into resistance when trying to publish pragmatic systems research. In one instance, a paper co-authored with Gabriel Dos Reis detailing an abstract syntax tree representation thirty times more efficient than GCC’s was rejected by reviewers, whose initial critique was the bizarre claim that Stroustrup and Dos Reis simply did not understand C++.
- Stroustrup transitioned to academia after spending 24 continuous years in industrial research. - During his tenure at Texas A&M University, the computer science department climbed roughly 20 positions in national rankings. - Academic friction included peer review rejections on practical compiler tools, such as an AST design outperforming GCC by a factor of 30.
> “I have some problems with academic research: it has a tendency of drifting away from real problems; you abstract from a real problem, then you abstract from the abstraction, then you solve the abstraction of the abstraction of the abstraction, which may or may not relate to the original problem.” — Bjarne Stroustrup
[01:41:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6089s) Academic Publishing Frustrations and the Pull Back to Industry
Bjarne Stroustrup recounts a deeply frustrating experience trying to publish practical engineering research while in academia. Working alongside an esteemed French representative on the ISO C++ standards committee who had served as a release manager for GCC, they produced an engineering breakthrough yielding a 32-times performance improvement in a core component. Despite this dramatic achievement, their paper was rejected with reviewers claiming the work had already been done in GCC—an assertion Stroustrup calls "total bogus." When they pushed back on the rejection, the academic establishment dismissively replied:
> “Oh, that's engineering. We're computer scientists.”
Stroustrup remarks bitterly that if they had been in automotive engineering and invented a 32-fold improvement to an essential component of a vehicle, they would have been hailed as heroes. Instead, it took several agonizing attempts just to get the work into print, even though the implementation is now widely utilized across modern compilers.
These experiences grated on Stroustrup, particularly because academic incentives actively harm graduate students. To earn a PhD, students must publish frequently, which de facto requires chasing academic fads. Yearning to escape sanitized, distilled academic exercises and return to concrete, messy, real-world problems, Stroustrup found himself open to outside offers. For years, he had maintained a practice of traveling to give industry and academic lectures, swapping talks about his current research for inside accounts of the practical problems companies faced. Following one such lecture at Morgan Stanley in New York City, company representatives suggested he join their team.
```mermaid flowchart TD accTitle: Academic Friction to Industry Transition accDescr: Diagram showing the academic publication barriers that drove Bjarne Stroustrup back into industrial work.
subgraph AcademicObstacles["Academic Environment"] A["Develop 32x compiler improvement"] --> B["Paper rejected: dismissive review"] B --> C["Reviewers: 'That's engineering, not computer science'"] C --> D["Students forced to chase academic fashion"] end
subgraph IndustryReturn["Move to Morgan Stanley"] E["Industry lecture exchanges"] --> F["Morgan Stanley recruitment"] F --> G["Proximity to grandchildren (20-min window)"] G --> H["Managing real-world systems & scale"] end
D --> E ```
[01:43:44](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6224s) Joining Morgan Stanley
Initially, Stroustrup flatly rejected Morgan Stanley’s overtures, arguing that he was working on long-range language design problems that had little to do with banking. When he warned them that his projects operated on a minimum five-year horizon, they were unperturbed and answered, "no problem." Ultimately, they wore down his customary defenses by possessing a decisive, hidden advantage they were not even aware of:
> “Of all the organizations that had the properties that that I could work for, they were the only one who lived within 20 minutes of my grandchildren.”
Having established criteria that multiple institutions met, geography tipped the balance. Stroustrup took the position, settling into a Manhattan apartment conveniently located midway between his office and his grandchildren.
At Morgan Stanley, his work centers on high-stakes systems engineering: networking architectures, expressive coding techniques, and high-performance computing positioned very close to the metal. While the core themes of performance and reliability mirror his past career, banking introduces an uncompromising standard of correctness:
> “With money you can't do that, it's against the law; you have to get it right every time, not just on average.”
Unlike a video streaming platform that can drop a frame without serious consequence, or a fuel-injection system that can recover on the subsequent engine cycle if a single squirt is slightly off, financial calculations cannot be off by a single penny. Being surrounded by massive real-world codebases directly enriches his continuing work on the ISO C++ standards committee. Simultaneously, he took on a professorship at Columbia University, remaining an emeritus professor at Texas A&M because the university refused to let him leave entirely.
[01:47:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6445s) Advice for Future Language Designers: Problems First, Solutions Second
When interviewer Paul McJones asks what advice he would offer to a graduate student aspiring to make an impact on programming language design, Stroustrup cautions against the common urge to invent a new language, game, or operating system straight out of the gate. The fatal blind spot in most of these ambitious endeavors is failing to grasp an actual problem:
> “C++ succeeded not so much because I made a beautiful design, but because I was really lucky of having identified a problem that a lot of people were about to get, namely handling complexity... under the constraint of performance.”
During the era C++ emerged, hardware was shifting toward larger memories and faster processors, which suddenly enabled developers to tackle far more intricate applications. Stroustrup recognized that managing this soaring complexity could not come at the expense of raw performance—an interplay most contemporaries failed to address.
For newcomers, Stroustrup advises avoiding the trap of setting out to change the world overnight: - Do not build bespoke patches merely to satisfy next quarter's corporate deadline; that path quickly turns an engineer into a manager who "will never do something really useful again." - Begin by deeply studying a concrete operational pain point, then step back to generalize the problem so the resulting solution benefits a broader audience over a longer timescale. - Treat university theory and formal courses as an analytical toolkit rather than the starting point; the crucial skill is finding a genuine problem worth solving and defining its real constraints before engineering the solution.
[01:50:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6625s) Combating Historical Amnesia in Computer Science
Reflecting on Paul McJones's initiative to archive the original Cfront compiler source code, manuals, and photographs at the Computer History Museum, Stroustrup laments that computer science students and young practitioners suffer from profound historical amnesia:
> “Students are by and large ahistorical; they have not been taught history, they don't understand history, and they think that history has nothing to teach them—everything was invented yesterday, and everything is the latest fad.”
He criticizes contemporary educational pipelines for worsening this disconnect. Secondary schools steer prospective engineers toward science and math scores while discouraging humanities, and universities downplay a well-rounded liberal arts background. This culture is compounded by popular media that measures career success solely by how quickly one amasses personal wealth:
> “There is a lot of emphasis in the press and elsewhere about the best career being the one that gives you the greatest amount of money soonest, and that is not a long-term motivator.”
Engineers produced by such narrow tracks often lack empathy, broad perspective, and communication skills, which are best developed by reading widely and listening attentively to others. Stroustrup believes the Computer History Museum holds a vital role in remedying this cultural defect, but stresses that museum exhibitions must move beyond rows of antique metal casings that look like "one washing machine after another" and instead illuminate *why* past machines and software systems were designed the way they were.
[01:53:45](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6825s) The Dilemma of Preserving Software vs. Hardware in Museums
Reflecting on how computing history is displayed to the general public, Bjarne Stroustrup observes that hardware-centric exhibits tend to grow stale very quickly. While a practitioner might walk through a gallery and feel a personal spark of nostalgia—remembering having programmed a specific box, having fun with another, or failing to make a third machine work—ordinary visitors find little to motivate them in rows of metal cabinets. Raw hardware fails to explain why a machine was commissioned, what kinds of problems it was meant to tackle, or how humans interacted with it. Stroustrup points out that museums naturally gravitate toward hardware because it is tangible, photogenic, and can be physically tapped, but “showing just Hardware I think is is uninteresting and there's a tendency of focusing on Hardware because you can see it you can knock on it it's pretty pictures but a computer without software is sort of kind of a boat anchor right.” He argues that museums must put far more emphasis on software, its tools, and its human context rather than simply displaying another dishwasher-sized chassis stripped of meaning.
Stroustrup emphasizes that software artifacts—compilers, database management systems, and application programs—are essential historical records. In fact, because multiple software programs exist for every single piece of hardware, “there should be more software in the museum than Hardware uh if you want to reflect reality.” The fundamental challenge is presentation: because software cannot be touched, seen, or knocked on, the only effective way to display it is through the context of its use and the real-world problems it solved. Paul McJones agrees, noting that the Computer History Museum’s *Revolution: The First 2000 Years of Computing* exhibit was created to supply that broader context compared to the original visible storage format, and that plans are underway for a dedicated software exhibit showcasing roughly a dozen systems and applications in practical context. McJones also makes sure to credit Alexander Stepanov for inspiring him to collect historical software and source archives, to which Stroustrup warmly responds that Stepanov is at the root of many interesting things, while noting that it was McJones who actively prodded him into delivering his materials.
- Stroustrup cautions against displaying isolated hardware out of context, comparing bare computers to appliances or boat anchors. - He calls on computing museums to treat compilers, databases, and application suites as core historical artifacts. - McJones clarifies that Alexander Stepanov originally prodded him to gather C++ materials and software artifacts for preservation.
---
[01:57:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=7028s) Academic Lineage and the CHM Fellows Award
As the interview approaches its close, a crew member behind the camera prompts Stroustrup to reflect on his induction as a Computer History Museum Fellow and his relationship to Maurice Wilkes and David Wheeler, who are also Fellows. Stroustrup explains that he has followed the museum and its Fellow Awards for many years, both online and in person, because he believes computing history is vital to understanding the present day: “I mentioned earlier history and the importance of history and I don't think history is something dead it's part of our world it's part of the way we understand the world.” Being recognized alongside those figures is an immense honor, particularly because it marks a unique generational milestone: he believes he is the museum's very first "third generation" Fellow, tracing a direct academic lineage from Maurice Wilkes down to Wilkes's student David Wheeler, and from Wheeler down to Stroustrup himself.
```mermaid flowchart TD accTitle: Cambridge Academic Lineage of CHM Fellows accDescr: Three generations of Computer History Museum Fellows from Cambridge University starting with Maurice Wilkes down to Bjarne Stroustrup. subgraph CambridgeLineage ["Cambridge Academic Lineage"] MW["Maurice Wilkes<br/>(CHM Fellow)"] -->|"Advisor to"| DW["David Wheeler<br/>(CHM Fellow)"] DW -->|"Advisor to"| BS["Bjarne Stroustrup<br/>(CHM Fellow)"] end ```
Stroustrup notes that because computer science remains a very young discipline, such multi-generational Fellow lines are still rare, though he expects many more will emerge in the future. He also shares a personal observation about consuming museum material: while reading through the short biographical stories of fellow inductees, he often wished for comprehensive text transcripts alongside video interviews. Because videos move at an unhurried pace and busy professionals cannot always sit through long recordings, having written transcripts linked directly to the biographies makes the history far more accessible. Prompted by the crew to give a final closing thought on the Fellowship, Stroustrup delivers a concise, heartfelt summation: “and of course if I didn't say it already I am very honored and uh this this is very important to me thank you.”
- The academic lineage links Maurice Wilkes (PhD advisor to David Wheeler at Cambridge) to David Wheeler (PhD advisor to Bjarne Stroustrup). - Stroustrup notes that computing is young enough that three-generation Fellow sequences are only just beginning to appear. - He advocates for providing transcripts for oral histories and video presentations to serve researchers and busy readers who need to absorb material quickly.
## Notable quotes > [26:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1592s) If you give people the choice of writing good code or fast code, there's something wrong; good code should be fast. — Bjarne Stroustrup
> [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) People talk about memory safety—that is a relatively uninteresting thing; you can kill a system much faster by leaking file handles than any other leak I can think of, including memory. — Bjarne Stroustrup
> [01:02:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3749s) If you look at Google or Facebook and their server farms, if you use a language that's half the raw performance, you need twice as many server farms. — Bjarne Stroustrup
> [24:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1448s) If I have to tell you what to do, it's a master's. — David Wheeler
> [01:47:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6445s) C++ succeeded not so much because I made a beautiful design, but because I was really lucky of having identified a problem that a lot of people were about to get, namely handling complexity... under the constraint of performance. — Bjarne Stroustrup
> [01:50:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6625s) Students are by and large ahistorical; they have not been taught history, they don't understand history, and they think that history has nothing to teach them—everything was invented yesterday, and everything is the latest fad. — Bjarne Stroustrup
## Mentioned Ada, Alexander Stepanov, ALGOL, ALGOL 68, Andrew Koenig, Andrew Sutton, ANSI, Aarhus University, AT&T Bell Laboratories, AT&T Labs–Research, BCPL, Beman Dawes, Bjarne Stroustrup, Borland, Burroughs Corporation, C, C with Classes, C++, Cambridge CAP Computer, Cfront, Columbia University, Computer History Museum, David Gries, David Wheeler, Dennis Ritchie, Dmitry Lenkov, Doug McIlroy, EDSAC 2, Facebook, Fortran, Gabriel Dos Reis, GCC, GNU, Google, Haskell, Howard Hinnant, IBM, ISO, John Backus, Kristen Nygaard, Lucent Technologies, Maurice Wilkes, Microsoft, Morgan Stanley, Ole-Johan Dahl, Paul McJones, Roger Needham, Sandy Fraser, Simula, SNOBOL, Standard Template Library (STL), Texas A&M University, Texas Instruments, University of Cambridge, WorldCom
## Video description Interviewed by Paul McJones, on February 5, 2015 in New York, New York, X7399.2015
© Computer History Museum
Bjarne Stroustrup (born 30 December 1950) is a computer scientist who designed and evolved the C++ programming language, from an individual research project in the late 1970s, continuing to the present day as the internationally-standardized language that is ubiquitous in performance-critical systems and applications. The interview covers his youth, his education at the Aarhus University and the University of Cambridge, and his career at AT&T Bell Laboratories, Texas A&M University, and Morgan Stanley. It also covers his early experience with a variety of programming languages including Simula and BCPL. Finally, it focuses on his work on C++ and its predecessor C with Classes, including his goal of combining good abstraction mechanisms with direct access to the hardware. Specific language features discussed include value semantics, templates, concepts, the Standard Template Library, and highlights of the C++11 and C++14 standards.
* Note: Transcripts represent what was said in the interview. However, to enhance meaning or add clarification, interviewees have the opportunity to modify this text afterward. This may result in discrepancies between the transcript and the video. Please refer to the transcript for further information - http://www.computerhistory.org/collections/catalog/102740024
Visit computerhistory.org/collections/oralhistories/ for more information about the Computer History Museum's Oral History Collection.
Lot Number: X7399.2015 Catalog Number: 102740024
[Source](https://www.youtube.com/watch?v=ZO0PXYMVGSU)