Stroustrup Links C++ Success to Merging Simula Abstraction With C

Oral History of Bjarne Stroustrup — Computer History Museum

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&lt;typename I&gt;"] B["void sort(I first, I last);"] A --> B end

subgraph ConceptsSyntax["Concepts-Based Terse Syntax"] direction TB C["void sort(Sortable&amp; 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)

中文简报

斯特劳斯特鲁普将C++的成功归因于Simula抽象与C语言的结合 C++之所以胜出,是因为将高级模块化与零开销硬件访问相结合,在不牺牲规模化系统所需的原始运行速度的前提下,解决了激增的软件复杂性。 在这段详尽的口述历史中,比雅尼·斯特劳斯特鲁普回顾了自己从奥胡斯工薪阶层到剑桥大学、贝尔实验室、学术界以及金融计算领域的历程,详细阐述了促使他创建C++的工程压力。他解释了Simula的高级抽象与BCPL的裸机效率之间的张力,如何塑造了他零开销的设计哲学,该哲学将具体的资源管理和性能置于学术纯粹性之上。斯特劳斯特鲁普回顾了围绕早期Cfront版本、语言标准化、亚历山大·斯特潘诺夫的标准模板库(STL)集成,以及Concepts和constexpr等现代语言特性的争论与博弈。在整个访谈中,他倡导解决现实问题,对企业基础研究实验室的衰退和计算机科学领域历史意识的缺失表示惋惜,并强调了软件保存的至关重要性。 比雅尼·斯特劳斯特鲁普在基础的零开销原则指导下,设计了C with Classes和C++,以弥合Simula的高级面向对象抽象与C语言裸机硬件效率之间的鸿沟。 (34:29) 亚历山大·斯特潘诺夫的标准模板库(STL)之所以能在ISO标准委员会获得通过,是因为各厂商在专有面向对象框架上的僵局,为以算法为核心、中立于厂商的替代方案打开了大门。 (80:37) 在现代计算系统中,斯特劳斯特鲁普强调,通过RAII对文件句柄、套接字和互斥锁进行确定性清理等资源安全,远比狭隘的基于垃圾回收的内存安全更为关键。 (90:42) 斯特劳斯特鲁普成为计算机历史博物馆的第一位第三代院士,延续了从莫里斯·威尔克斯到大卫·惠勒再到他本人的直接学术渊源。 (117:08)

Reading summary

In this Computer History Museum oral history, Bjarne Stroustrup argues that C++ succeeded by solving a concrete practical dilemma—managing soaring system complexity without sacrificing hardware-level performance. Grounding language design in real-world engineering rather than abstract theory, he reflects on the mechanics of zero-overhead abstractions, the friction of committee standardization, and the dangers of historical amnesia in computing. Pragmatic Foundations: From Microcode to Commercial Accountability (2:30) Stroustrup entered computing through applied mathematics (*datalogi*) at Aarhus University, motivated by a desire to avoid pure academic theory and a career as a schoolteacher. Instead of identifying as a programming language theorist, his early passions centered on computer architecture, microprogramming, and operating systems. To execute BCPL on local hardware, he microcoded an engine directly into hardware to run BCPL's intermediate O-code bytecode, an early demonstration of his focus on machine-level efficiency. Formative exposure to SNOBOL taught him within months that mastering a programming tool demands adopting its native idioms rather than forcing paradigms from prior languages. To finance his studies without incurring debt, Stroustrup ran commercial software projects for Burroughs Corporation and Aarhus University. He operated under a direct commercial incentive loop: building demonstrations that prospective clients valued enough to purchase, followed by complete system implementations, on-site debugging, and end-user training. These experiences instilled a lasting sense of professional accountability. Sitting in clients' homes and speaking with their families highlighted that software failures carried tangible consequences, reinforcing his view that software development must remain grounded in concrete operational demands. The Zero-Overhead Principle and Core Language Design (34:29) When Stroustrup arrived at Bell Labs, his goal was to construct a distributed modular operating system across networks and multiprocessors. However, he encountered a familiar roadblock: Simula provided high-level abstraction and modularity but suffered from an expensive runtime and garbage collection, while C offered raw efficiency but lacked language-level module boundaries and type checking. To bridge this divide, he created C with Classes, later C++, guided by the zero-overhead principle: an abstraction mechanism must execute as fast as the best hand-coded alternative in the basic language. Key design choices separated C++ from its contemporaries. Stroustrup mandated constructors and destructors to establish resource acquisition is initialization (RAII), unified user-defined and built-in types around value semantics, and rejected garbage collection because system software could not tolerate runtime overhead. When operator overloading and virtual functions were added in 1983–1984, they faced skepticism from procedural engineers who preferred manual function pointers. For generic programming, Stroustrup dismissed preprocessor macros in favor of templates, deliberately prioritizing open-ended generality and zero-overhead performance even though omitting interface constraints led to decades of cryptic compiler errors that Concepts were later designed to solve. Standardization Politics, Committee Friction, and the STL (65:33) Stroustrup did not seek official standardization; external corporate pressure from Hewlett-Packard and IBM forced him into ANSI meetings in December 1989 because enterprises feared the 'bus factor' risk of relying on a single individual. The subsequent ANSI and ISO processes proved chaotic, split between factions attempting to strip C++ of its C foundation to enforce pure object orientation and opposing groups resisting any departure from traditional C. Acting as an active designer within an open committee proved grueling, as Stroustrup lacked dedicated design teams or validation budgets to counter passing industry fads. This standardization framework was fundamentally reshaped by Alexander Stepanov's Standard Template Library (STL). Although Stroustrup initially considered the library alien because it rejected traditional object-oriented inheritance hierarchies, he embraced it upon recognizing that its generic algorithms matched his zero-overhead philosophy. Despite resistance from committee members accustomed to classical OOP and major vendors promoting proprietary container frameworks, interventions by Stepanov and early implementation proofs by Beman Dawes secured the STL's adoption, firmly establishing generic programming alongside object-oriented design in modern C++. Industrial Research Culture Versus Academic Detachment (93:41) Reflecting on his 24 years in industrial research, Stroustrup recalls Bell Labs' Computer Science Research Center as a unique environment that funded small cohorts of talented scientists, encouraged long-term bets spanning five to ten years, and maintained mutual respect across the hardware-software divide. This ecosystem dissolved under financial restructuring, the telecom bubble collapse, and Wall Street cost-cutting, which culminated in indiscriminate research layoffs and the corporate separation of switch manufacturing from switch software. Moving to Texas A&M University revealed a different dysfunction: an academic culture increasingly detached from physical computing reality. Stroustrup observed that academic computer science frequently incentivized researchers to solve 'abstractions of abstractions' and chase publishing trends at the expense of practical engineering. In one instance, a compiler engineering breakthrough achieving a 32-times performance improvement over GCC was rejected by reviewers dismissively labeling it 'engineering' rather than 'computer science.' This friction prompted his return to industry at Morgan Stanley, where high-performance financial systems enforce strict correctness and zero tolerance for failure. Countering Historical Amnesia in Computing (107:25) Stroustrup cautions aspiring language designers against creating languages or systems in a vacuum. In his analysis, C++ succeeded primarily because it correctly identified an emerging historical crisis: handling soaring software complexity under strict performance constraints as hardware memories and clock rates expanded. He advises newcomers to avoid chasing short-term quarterly fixes and instead thoroughly analyze concrete operational problems before abstracting them into general solutions. Addressing computer science education, Stroustrup laments a widespread ahistorical attitude among students who assume computing was invented yesterday. He criticizes secondary and university pipelines that discourage liberal arts and humanities, arguing that engineers trained without exposure to history and broad reading lack empathy, contextual understanding, and communication skills. Furthermore, he contends that museums like the Computer History Museum must move beyond displaying polished metal computer cabinets—which he likens to 'boat anchors' without their original software context—to properly preserve software systems, tools, and the real-world problems they were constructed to solve. Stroustrup's reflections demonstrate that enduring programming systems survive not through pure theoretical elegance, but through their ability to navigate messy machine-level trade-offs and sustained real-world utility. While modern additions like move semantics, `constexpr`, and Concepts have addressed long-standing syntactic and safety limitations, the unresolved challenge remains balancing essential historical backwards compatibility against the desire for a drastically smaller, safer language.

精炼阅读摘要

Bjarne Stroustrup 在访谈中回顾了开创 C++ 的技术与学术生涯,阐明该语言的核心在于将硬件效率与高层抽象结合,以解决在严格性能约束下驾驭系统复杂度的现实工程难题。他同时剖析了贝尔实验室研究体系的变迁、标准化委员会的博弈以及学术与工业界的文化断层,呼吁业界克服历史健忘症并坚持以解决真实问题为先。 抽象与硬件结合:C++的设计哲学 (34:29) Stroustrup 构思 C++(前身为带类的 C)并非出于纯粹的语言学兴趣,而是为了解决分布式系统模拟中的性能与组织瓶颈。在剑桥攻读博士期间,他使用 Simula 编写模拟器却因开销过大导致主机崩溃,被迫耗时改用 BCPL 重写。进入贝尔实验室后,他发现 Unix 环境下的 C 语言缺乏表达模块边界与私有状态的机制,而 Simula 虽具优秀的面向对象抽象,其运行时开销与编译器设计却无法满足底层系统操作的要求。因此,他决定将两者的长处融合,打造兼具硬件控制力与高层组织能力的工具。 在底层机制上,Stroustrup 引入了函数原型检查、构造函数与析构函数的配对管理(后确立为 RAII 原则),并坚决贯彻统一值语义。他摒弃了 Simula 强制将自定义对象分配于堆上的引用模型。据其了解,Simula 做出这一妥协是受限于垃圾回收器的实现;而在严苛的底层系统编程中,依赖栈分配与确定性析构消除了垃圾回收的性能损耗,提供了可预测的自动资源管理,奠定了 C++ 零开销抽象的基石。 泛型编程演进:从模板到概念机制 (55:37) 为取代脆弱的预处理器宏,Stroustrup 在 C++ 1.0 发布后提出了模板机制,确立了通用性、零开销性能与接口约束三大目标。20 世纪 80 年代末,为保证抽象机制达到手写底层代码的极致效率,他妥协了接口约束,导致 C++ 长期饱受晦涩编译报错之苦。历经三十余年演进,他与合作者设计的 Concepts(概念)才在不依赖虚函数表开销的前提下,以规范形式正式补全了严格的泛型约束。 在标准模板库(STL)的引入中,Stroustrup 克服了将容器视为深层面向对象继承体系的固有偏见,被 Alexander Stepanov 依托强类型内联优化与泛型迭代器解耦算法的思想所折服。尽管面临各大厂商私有面向对象框架的阻力,STL 最终成功进入标准。Stroustrup 指出,现代 C++ 的 Lambda 表达式本质上是早期函数对象的语法糖;而在其精简语言构想中,他主张将安全性拓展至涵盖文件句柄、互斥锁与套接字在内的全生命周期系统资源安全,而不仅局限于内存防泄漏。 一人支持负荷与国际标准化的博弈 (46:12) C with Classes 推出仅六个月便迎来了首批工业用户,这使 Stroustrup 在长达十年的时间里身兼核心设计者、编译器实现者(编写了 Cfront 约 98% 的代码)与全天候技术支持。原本计划中的分布式操作系统研究被迫搁置,他调侃称若非这种支持责任,Unix 多核集群可能早在 1985 年便已成型。为了让 Cfront 跨平台运行于各种异构 C 环境,他还发明了运行于目标机的数据探测程序以生成机器描述文件,实现了灵活的转译架构。 1989 年,在惠普与 IBM 等工业界代表的强力施压下,Stroustrup 虽认为语言尚未成熟,仍被迫启动了 ANSI 与 ISO 标准化进程。委员会运作带来了巨大的政治与沟通摩擦:纯面向对象学派试图彻底剔除 C 语言底层特性,而过程式学派则敌视任何抽象扩展,且委员会缺乏专职研发队伍来验证提案。作为语言的原始创造者,Stroustrup 长期留守委员会一线,在抑制短期技术狂热与妥协折衷之间艰难维护着语言设计的内在一致性。 工业研发解体、学术异化与重回前线 (93:41) Stroustrup 亲历了贝尔实验室计算机科学研究中心的黄金年代,该机构推崇科研人员自主选题与长期战略布局,汇聚了数十位顶尖科学家。然而 20 世纪 90 年代末起,伴随电信行业震荡与金融市场对纵向整合研发体系的拆解,管理层盲目推行短期降本,甚至越过作为系主任的 Stroustrup 直接裁撤其团队骨干,致使长线工业研究环境不复存在。 转入德州农工大学执教十年后,Stroustrup 感受到了学术界体制的严重异化。他批评学术计算机科学日益脱离工程实际,充斥着针对“抽象之抽象”的纯理论游戏;例如他与合作者研制的高效抽象语法树成果比 GCC 快 32 倍,却被学术审稿人以“这是工程而非计算机科学”为由拒稿。这种追逐流行论文发表指标的导向促使他最终重回工业一线加入摩根士丹利,专注于金融系统底层毫秒必争、零容错的分布式高并发架构。 历史盲目性批判与以问题为导向的研发 (107:25) 对于希望在编程语言领域有所建树的年轻学者,Stroustrup 告诫切忌盲目发明新语言或沉溺于应对公司下季度交付的临时补丁。他指出,C++ 的广泛成功关键在于敏锐抓住了在硬件性能增长期“在严苛性能约束下控制系统复杂度”这一广泛痛点。卓越的工程应当先深入研究具体的业务死结,再退后一步将解法泛化为通用方案。 与此同时,Stroustrup 严厉批评了当前计算机教育中普遍存在的“历史健忘症”。过度偏重狭隘算力指标与商业金钱回报的速成文化,使得年轻从业者误以为技术皆为昨日横空出世,忽视了人文社科修养对工程师全局视野与同理心的熏陶。作为计算机历史博物馆首位“三代同堂”院士(师承 David Wheeler,后者师承 Maurice Wilkes),他强调历史展陈不应止步于展示冰冷的金属机箱,而必须向公众展现软件算法与人类解决真实难题的思想轨迹。 Stroustrup 的学术与工业历程表明,编程语言的生命力扎根于对底层硬件特性的敬畏与对现实工程复杂度的响应,而非自闭于纯粹主义的形式美学。尽管历经三十余年演化后的现代 C++ 不可避免地背负着语法冗余与历史妥协,且他在回顾性思考中构想的“体积缩小九成而保持同等效能”的理想语言仍未完全实现,但他确立的零开销抽象与全方位资源安全理念,依然深远地主导着现代系统级软件工程的发展轨迹。

Detailed notes — zh

## Background 本内容由计算机历史博物馆(Computer History Museum)于 2015 年 9 月 4 日发布在 YouTube 平台。视频记录了 Paul McJones 于 2015 年 2 月 5 日在纽约对 C++ 语言缔造者 Bjarne Stroustrup 进行的口述历史深度访谈,系统回顾了其成长求学历程、在贝尔实验室的工作,以及 C++ 从单兵研发到国际标准化背后的设计哲学与演化史。 ## TL;DR 访谈详尽梳理了 Bjarne Stroustrup 从丹麦奥胡斯与剑桥大学起步,到在贝尔实验室孕育出 C with Classes 及 C++ 的技术轨迹。Stroustrup 重点阐述了将 Simula 的高层抽象与 C/BCPL 的底层硬件控制及零开销原则相结合的核心理念,回顾了函数原型、值语义、RAII、模板、STL 以及 Concepts 等里程碑特性的诞生始末。此外,他还分享了在德州农工大学执教与加盟摩根士丹利的经历,深刻反思了工业界研发与象牙塔学术脱节的现状,并呼吁年轻一代重视真实工程约束与技术历史。 ## Atmosphere & style 访谈氛围睿智、从容且充满工匠式的务实与反思,Stroustrup 与 McJones 的对谈如同两位老友围炉论道,技术洞见与幽默掌故交织。在回忆青年时代受挫与贝尔实验室拆分时,言谈间自然流露出时代变迁的唏嘘与痛心,而在阐述零开销原则和底层系统性能时,又展现出坚如磐石的技术执念。整体给人一种厚重而不失温情的历史临场感,让听众能切实体会到一位当代计算机大师在理想主义与工业工程现实博弈中的坚守与风骨。 ## Bulletin - [28:16](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1696s) Bjarne Stroustrup 设计 C++ 的核心哲学是“零开销抽象原则”,坚决融合 Simula 的高层面向对象组织能力与 BCPL/C 的直接硬件存取与极致性能。 - [39:56](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2396s) C++ 早期奠基性设计确立了函数原型、基于构造/析构函数的不变量管理(RAII 原型)以及与内建类型地位平等的栈分配“值语义”,拒绝了 Simula 等语言强制堆分配和垃圾回收的路线。 - [01:17:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4645s) Alex Stepanov 创造的 STL 凭借零开销泛型与算法容器解耦,克服了当时商业面向对象库的内卷阻力,奇迹般成为 C++ 标准库的核心。 - [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) Stroustrup 认为计算领域应追求涵盖文件、锁与套接字的全面“资源安全”而非单纯的内存安全,并指出工业界机房能耗与硬件成本使得底层极致性能依然关乎存亡。 ## Key takeaways - [07:03](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=423s) 奥胡斯大学的数学底子与编译器实操为 Stroustrup 奠定了理论与底层基础,他在早期曾直接为 Martin Richards 的 BCPL O-code 编写硬件微代码虚拟机。 - [13:19](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=799s) 早期在宝来公司等企业承接全流程商业合同编程的经验,让 Stroustrup 深刻体会到代码故障对现实家庭的影响,确立了软件必须兼顾“适用性、可靠性与经济性”的工程哲学。 - [19:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1148s) 在剑桥大学攻读博士期间师从 David Wheeler 与 Roger Needham,形成了 Maurice Wilkes、David Wheeler 到 Stroustrup 的三代计算机历史博物馆院士传承谱系。 - [26:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1592s) 在剑桥用 Simula 编写分布式系统模拟器导致大型机瘫痪、后被迫用 BCPL 重写掉光头发的经历,使他确立了终身信条:“好代码本身就应该跑得快”。 - [34:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2072s) 在贝尔实验室开发 C with Classes 的初衷是为了满足自己构建分布式 Unix 操作系统的架构需求,并非立志成为全职语言设计者。 - [42:51](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2571s) 坚决反对强制将用户自定义类型置于堆上由垃圾收集器管理的做法,主张无论基础类型还是复合类型均应原生支持栈分配与值语义。 - [48:03](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2883s) C++ 首个商业版 Cfront 凭借轻量级探测机制适配目标机架构并转译为 C 代码,在无现代打包工具时代实现了单人维护并跨平台移植至 20 多种硬件架构。 - [55:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3337s) 模板设计确立了通用性、零开销与良好接口规范三大目标,但在 1988 年受制于技术条件妥协了接口规范,为此后长达数十年的 Concepts 研发埋下了伏笔。 - [01:02:27](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3747s) 零开销原则在现代超大规模分布式系统(如 Google、Facebook)中具有切实的物理意义,运行速度减半直接意味着服务器机房数量、电力冷却与维护成本翻倍。 - [01:05:33](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3933s) C++ 启动 ANSI/ISO 标准化的直接诱因是 HP 与 IBM 等工业界巨头担忧语言设计者“被公交车撞倒”产生单点风险,迫使 Stroustrup 接受委员会制度。 - [01:11:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4302s) C++11 与 C++14 强调“让简单的事情变简单”,引入 range-based for、auto 与 lambda 等特性,其实质是在保持静态强类型前提下消除样板代码。 - [01:25:12](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5112s) constexpr 与 Concepts 的引入是为了治理模板元编程异化成“编译期鸭子类型”的混乱局面,将计算引导回常规纯函数并规范泛型类型契约。 - [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) 坚信可以构建出一种体积仅为现有 C++ 十分之一、保留底层硬件指针模型但具备移动语义与完整“资源安全”的高性能系统级语言。 - [01:33:41](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5621s) 贝尔实验室在 1980 至 1990 年代的辉煌得益于自由探索与产出交付的平衡,但随后因华尔街金融资本对基础研发的短视拆分与裁员而瓦解。 - [01:41:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6089s) 批评现代高校计算机学术界陷入追求“抽象的抽象”并排斥硬核系统工程的偏见,促使他先后加盟德州农工大学、哥伦比亚大学并最终在摩根士丹利直面苛刻的工程现实。 - [01:47:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6445s) 告诫年轻计算机研究者切莫盲目追求改变世界或随波逐流,应当深入复杂现实业务去挖掘具有长久通用价值的真问题。 - [01:53:45](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6825s) 呼吁计算机历史博物馆突破脱离情境的冷冰冰硬件陈列,应通过展示软件、编译器与工具链来呈现计算机当年究竟如何解决现实难题。 ## Detailed walkthrough ### [00:05](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5s) 开场与丹麦奥胡斯的童年岁月 访谈于 2015 年 2 月 5 日举行,由位于加利福尼亚州的 Paul McJones 主持,Bjarne Stroustrup 身处纽约市,摄像机后则是 John Plute。两人刚一连线便感叹技术的神奇,彼此相隔数千英里却能畅快视频交谈,Paul McJones 笑着指出幕后很可能正在运行某种 C++ 技术,Stroustrup 也深表赞同,感叹在自己当年刚起步研究时,这种远程交互完全是天方夜谭。 谈及成长背景,Stroustrup 回忆自己出生于丹麦的奥胡斯(Aarhus),并在那里度过了人生的前 23 年。他成长在一个工人阶级社区的普通公寓楼里,父亲最初是一名铺地砖工人,后来因病转行成为医院的护工;母亲是一名秘书,受过初中教育,这在当时的整个家族中已经是最高的文化程度。Stroustrup 就读于当地的一所社区学校,他坦言那所学校的办学质量并不好,甚至后来查阅统计数据时发现那是全镇成绩最差的学校。尽管起点十分底层,他仍凭借自己的能力考入高中,进而迈入了奥胡斯大学(Aarhus University)。 Stroustrup 对故乡奥胡斯怀有非常温情而稳定的回忆,小时候住的地方被大家称为“院子”(the yard),是欧洲非常典型的带中央草坪庭院的长方形公寓楼群。他后来走遍世界并在许多地方定居,但他强调这绝不是因为讨厌故乡,至今他在丹麦仍有亲人。 - 访谈日期与地点:2015 年 2 月 5 日,纽约与加州越洋连线 - 父母职业与背景:父亲为铺地板工、后任医院护工;母亲为秘书(初中学历) - 本地初等教育:就读于奥胡斯当地统计排名最差的公立学校,随后考入高中及奥胡斯大学 --- ### [02:33](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=153s) 专业抉择:从“避免当老师”到误打误撞进入计算机领域 高中毕业时的 Stroustrup 与绝大多数年轻人一样,对未来毫无头绪。他曾考虑过成为历史学家、建筑师、社会学家或工程师,因为不确定具体方向,他便努力考出能申请任何专业的高分。他原本考虑过前往哥本哈根的工科大学就读,虽然丹麦实行大学免费教育,但对于一个资源匮乏的家庭而言,为了长达六年的学业背负债务、在大城市艰难生活,代价实在过于沉重。因此,他决定留在本地大学。 奥胡斯大学当时没有工程学院,而他在高中的数学成绩相当不错,于是他报名了数学专业。但他内心笃定自己必须学习某种“应用数学”或实用技术,必须能做实际的工作。Stroustrup 坦陈自己当时对当中学教师有一种极端的恐惧感,在他看来,很多聪明孩子因为不知道该干什么、身边又缺乏榜样,最终往往就落得去当老师的下场。为了不做老师,他报了计算机科学方向。然而在丹麦语中,该学科名称里压根没有“计算机”(computer)这个字眼(即 Datalogi),以至于他完全误以为这门课属于纯数学。直到大二,他才恍然大悟:编程、数据结构和机器体系结构根本不是数学。幸运的是,他发现自己并不像原先以为的那么精通纯数学,反而对编程、钻研机器以及计算机科学本身产生了极大的乐趣,自此一往无前。 回顾这段求学经历,Stroustrup 并未获得任何导师的职业指引。他的数学启蒙得益于一位连续教了他九年的优秀数学老师,但这位老师出身于师范学院,也未曾读过普通高中,无法在高等学术道路上为他提供建议。不过,他在奥胡斯大学攻读数学与计算机科学硕士期间所打下的抽象数学底子,在数十年后展现出了惊人的后劲。谈及抽象代数的价值时,Bjarne Stroustrup 这样总结: > “如果你在比如二十年前告诉我代数学最终会非常有用,我大概会竭力反驳;但结合类型论以及 Alex 在 STL 上的研究等工作,我在代数中学到的那种思维方式,在被闲置了几十年后,反倒在过去的这二十年里变得极为有用。” --- ### [07:03](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=423s) 编译器启蒙与为 BCPL 编写硬件微代码虚拟机 在被问及早年是否有对自己产生重大影响的教科书时,Stroustrup 打趣说脑海里冒出来的第一本书其实是一本关于国际象棋开局的书,但那显然不属于计算机范畴。随后他提到了一本真正带他入门的书——David Gries 所著的关于如何编写编译器的经典教材(《Compiler Construction for Digital Computers》)。这本书非常注重实操,尽管整本书篇幅绝大多数都在讲语法分析,而在实际的编译器设计中语法往往是最次要的部分,但它成功点燃了他对编程语言及其实现机制的兴趣。 不过,Stroustrup 强调自己当年绝非纯粹的“编程语言爱好者”,他的真正兴趣始终落在操作系统、微程序设计(microprogramming)和机器体系结构上。在奥胡斯大学期间,他完成过一个极富特色的早期项目:为了在硬件上直接运行 BCPL 语言,他盯上了 Martin Richards 在 BCPL 编译器中生成的 O-code(一种面向虚拟机的中间字节码/汇编代码)。Stroustrup 没有走常规的软件解释或编译移植路线,而是直接编写了一套微代码(microcode),在硬件层面逐条指令实现了 O-code 的执行引擎,并结合压缩数据结构来紧凑存放程序代码。这项工作巧妙利用了编译器已有的中间表示,跳过复杂的全套工具链开发,直接在底层硬件上跑通了 BCPL。 ```mermaid flowchart LR accTitle: BCPL microcode virtual machine execution flow accDescr: Shows how Martin Richards' O-code was intercepted and executed directly in hardware microcode designed by Stroustrup. subgraph Frontend["编译器前端"] A["BCPL 源代码"] --> B["BCPL 编译器"] B --> C["O-code 中间代码"] end subgraph HardwareVM["底层微程序引擎"] C --> D["压缩数据结构表示"] D --> E["硬件微代码虚拟机<br/>(逐条指令硬件级实现)"] E --> F["直接在机器架构上执行"] end ``` --- ### [09:46](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=586s) 掌握二十种语言、SNOBOL 的顿悟与早期产业工程经验 在离开奥胡斯大学获得硕士学位前(当时丹麦大学没有学士学位,毕业即为硕士),Stroustrup 已经接触并学习了十几甚至二十种编程语言。在当时的学术环境中,研究型语言和实用工程语言之间并没有清晰的界限。他接触过各式各样的工具,既写过并厌恶过 COBOL,也深深被 1960 年代用于字符串处理和模式匹配的语言 SNOBOL 所吸引。 在学习 SNOBOL 的过程中,他经历了一次对其软件设计哲学产生深远影响的顿悟。他曾用 SNOBOL 编写过一个程序,完成后却发现该程序极其笨重、难以调试且运行缓慢,完全是一段披着 SNOBOL 外皮的 Algol 代码。谈到这段经历对理解语言特质的警醒,Bjarne Stroustrup 阐述道: > “你不能拿来一种语言就直接照搬上一门语言的习惯去写代码,虽然我们基本上所有人都会这么干;但必须意识到自己又在重蹈覆辙并及时纠正,而这一点我其实在编程的前半年就学到了。” 这种领悟让他明白,每种语言都有其特定的思维惯用法(idioms),不能生搬硬套。在那个语言规范、开发环境与运行时库相对小巧的年代,程序员只需在候车室或空闲时读上几小时手册,就能立刻上手编写程序,在几周或几个月内探索其适用的场景。但他始终坚持把编程语言视为一种达成目标的工程工具,而非终极目的本身。 为了赚取生活费以避免负债求学,他在大学期间承接了大量的兼职合同编程(contract programming)工作。除了学校内部的微代码开发项目外,他在宝来公司(Burroughs)的合同工经历尤其锻炼人。这份工作让他跳出了纯象牙塔代码的视角,第一次完整目睹了商业软件的落地全过程:从最前线与客户沟通业务诉求,到在销售人员天马行空的许诺与客户的实际欲望之间做权衡,最终评估并敲定在技术上究竟能够切实交付什么系统。这种早期的工业界真实磨砺,深刻影响了他后来务实、面向系统效能与解决实际问题的工程哲学。 ### [13:19](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=799s) 早期商业经验与实战软件工程观 在正式开启学术生涯之前,Bjarne Stroustrup 曾承接过多份商业软件外包项目。他采取了一套非常精简的商业模式:只要能为客户做出一个令对方满意并愿意付费的演示原型(demo),他就能拿到实现整个系统的合同。这种模式对企业而言极具保障,因为如果原型无法交付,雇佣关系便自然终止;而对于客户、企业以及 Stroustrup 本人来说,这种机制驱动所有人竭尽全力将系统做到最好。 在几年时间里,Stroustrup 重复经历过大约 6 到 12 次这样的全流程开发。他深入一线与客户沟通,驻场跟进安装调试,观察软件可能出现故障的卡点,并亲自培训一线操作人员。他甚至常常坐在客户家中的沙发上,与客户的孩子们闲聊。这种经历深深触动了他,使他切身意识到:自己的代码若出现重大漏洞,真实家庭的生计与福祉就会受到波及。这段经历覆盖了软件生命周期的每个环节——从前期探寻客户真正需要什么系统,到后期出现故障时的现场收拾与维护。正是在这套磨砺中,他形成了坚定的工程哲学:软件必须做到恰如其分、可靠且具成本效益(appropriate, reliable, and affordable)。他坚信,这种对责任与工程实践的深刻领悟,是在传统课堂环境中极难传授的。 - 商业履历:在数年间独立完成约 6 至 12 次完整的商业系统开发与交付。 - 工程原则:深刻确立了软件系统必须兼具“适用性、可靠性与经济性”的设计准则。 - 责任感来源:在客户家中与孩子交流的体验,让他直观理解到软件工程缺陷所带来的现实后果。 --- ### [15:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=929s) 前往剑桥大学攻读博士与艰难的入学面试 在获得硕士学位前,Stroustrup 曾接触过微程序设计(microprogramming)硬件,并专程赴英体验当地先进的硬件技术。这一趟经历激发了他对前沿硬件与系统的浓厚兴趣。为了能够长期留在英国摆弄更有趣的硬件,他将攻读博士学位视为最理想的解决方案。他向所有听说过的英国顶尖大学递交了申请,并几乎拿到了全部录取。 最初他一度打算去纽卡斯尔大学(Newcastle),但他当时的未婚妻(后来的妻子)极力劝阻,态度十分决断地告诉他:在英国,如果你拿到了剑桥大学的录取通知,接受它是一件毫无商量余地的事情。历史证明这是一个极其正确的决定,剑桥大学至今仍被他视作欧洲开展实用计算机科学研究最顶尖的殿堂。 在剑桥的入学面试中,负责考核他的是图灵奖得主 Maurice Wilkes 与 Roger Needham。戏剧性的是,Stroustrup 当时并不知道坐在面前的 Wilkes 正是微程序设计的发明人,便兴致勃勃地向对方大谈特谈微程序设计有多酷。整个 45 分钟的面试异常严苛,Wilkes 与 Needham 轮流发问、严谨审视,甚至在中途直接挑明他的设想完全是错的,逼问他还有没有其他方向可做。Stroustrup 只得在面试中途临时调整策略、换道论述,最终凭借出色的临场发挥赢得了录取。 > “My wife, my then-girlfriend explained to me that if you have an offer from Cambridge you take it. This is non-negotiable if you’re in England.” —— Bjarne Stroustrup 回忆未婚妻劝他接受剑桥录取时的果决态度。 > “That was the toughest interview I've ever sat through.” —— Bjarne Stroustrup 谈及 Wilkes 与 Needham 对他进行的剑桥博士面试。 - 剑桥传承:Maurice Wilkes(第二届图灵奖得主、计算机历史博物馆 Fellow)培养了 David Wheeler(计算机历史博物馆 Fellow),Wheeler 随后指导了 Stroustrup,形成了三代同堂的传承谱系。 - 面试考官:Maurice Wilkes(微程序设计发明人)与 Roger Needham(后任剑桥副校长、微软欧洲研究院创立者)。 --- ### [19:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1148s) 剑桥的师从导师:David Wheeler 与 Roger Needham 进入剑桥后,由于已拥有硕士学位,Stroustrup 无需修读常规课程,只需在必要时选修特定科目。他的导师 David Wheeler 采取了一种独特而高效的指导方式:Stroustrup 通常每周主动登门交流一次。初出茅庐的年轻博士生总是满脑子宏大设想,兴冲冲地向导师汇报。Wheeler 则会安静聆听,随后若有所思地说出那句让学生最害怕的口头禅:“我们在做 EDSAC 2 的时候差点就这么干了。” 这意味着早在 1956 年——大约在 Stroustrup 刚上小学的时候——剑桥的前辈们就已经构思并尝试过这套方案了。 紧接着,Wheeler 会用上整整一个小时,极其详尽地拆解当年他们为何放弃该设想、转而采取了何种替代方案、权衡考量何在、替代方案为何在某些细节上受挫,以及最后又是如何修补完善的。Wheeler 总是以极度礼貌的方式将年轻人的构想驳得体无完肤,顺势展开一场高水平的即兴学术讲座,让 Stroustrup 离开办公室时深感自身渺小,但下周又会重整旗鼓再次前来探讨。 与较为威严的 Wheeler 相比,Roger Needham 的行事风格则更为亲和。Needham 常与学生们共进午餐,惊人的是他能在中午喝下整整两品脱 Abbot 啤酒却依然在下午高效工作。在讨论问题时,Needham 习惯一边思考一边来回踱步交流,互动性更强。为了跟上他的思维节奏且不至于被他踱步绕得精疲力竭,Stroustrup 甚至摸索出了一套专有策略:稳稳站在走廊拐角处,看着 Needham 在视野内来回走动并展开深度辩论。 剑桥大学(以及后来的贝尔实验室)给 Stroustrup 留下的最深印记,是极大拔高了个人对自身标准的期望。置身于顶尖学者举重若轻解决难题、且待人极其谦逊友善的环境中,任何人都会迅速意识到必须全面提升自己的水平。 > “Yeah, yeah, yeah, Bjarne, that's not a bad idea. You know, we almost did that for the EDSAC 2.” —— David Wheeler 在听完 Stroustrup 的新点子后标志性的回应。 > “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.” —— Bjarne Stroustrup 谈顶尖机构对研究者追求极致标准的潜移默化影响。 --- ### [24:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1448s) 博士研究课题的选择:分布式系统与硬件能力体系 在剑桥的第一天,David Wheeler 在办公室向 Stroustrup 提出了一个直击本质的问题:“硕士与博士的区别究竟是什么?”面对 Stroustrup 的茫然,Wheeler 一针见血地给出了答案:如果需要导师告诉你具体去做什么,那充其量只是个硕士课题;独立探寻并确立有价值的研究方向,才是博士阶段首要也是最重要的任务。Stroustrup 足足花费了一整年时间来探索和确定自己的博士课题。 由于早前在微程序设计与硬件架构方面的积累,Stroustrup 最终锁定了分布式系统领域。当时剑桥正在研发著名的 CAP 计算机(由 Wilkes、Wheeler 和 Needham 共同设计),该系统从硬件层面上实现了基于“能力”(capabilities)的保护机制。Stroustrup 的核心目标是构建高层级的硬件架构支持,以实现模块化与硬件受保护实体之间的顺畅通信。他雄心勃勃地计划将这种基于硬件的保护能力拓展到单机多处理器、乃至通过网络互联的多台计算机集群之上。然而在当时的客观条件下,多核处理器在全世界范围内都屈指可数,他也根本无力负担真正的网络与多机硬件环境。 ```mermaid flowchart TD accTitle: Stroustrup 博士课题演进逻辑图 accDescr: 展示了从剑桥 CAP 硬件能力保护机制向多核多机网络分布式系统扩展的研究路径 subgraph HardwareFoundation ["剑桥 CAP 计算机硬件基础"] A["剑桥 CAP 计算机<br/>Wilkes, Wheeler, Needham 设计"] --> B["硬件级保护能力<br/>(Capability-Based Protection)"] end subgraph ExpansionGoal ["Stroustrup 的扩展构想"] B --> C["高层体系结构支持<br/>(硬件级模块化与实体通信)"] C --> D["单机多处理器扩展<br/>(多处理器环境)"] D --> E["网络分布式扩展<br/>(跨网络多机系统)"] end subgraph RealityCheck ["现实约束条件"] E -.-> F["硬件极其稀缺昂贵<br/>(多核与集群不可得)"] F -.-> G["催生后续软件仿真需求"] end ``` > “If I have to tell you what to do, it's a master's.” —— David Wheeler 对硕士与博士本质区别的经典定义。 - 选题历程:耗时整整一年才独立确立研究方向,将软件模块化思想与底层体系结构结合。 - 核心技术渊源:剑桥 CAP 计算机及其硬件能力保护机制(Hardware Capabilities)。 - 硬件限制:受制于当时全球范围内多核及网络硬件极其匮乏且昂贵的客观环境,研究被迫转向针对分布式体系结构的模拟与仿真。 ### [26:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1592s) 剑桥博士研究:Simula 的优雅与大型机的崩溃 在剑桥大学攻读博士学位期间,Bjarne Stroustrup 专注于分布式系统相关的体系结构与系统软件问题。由于当时 Cambridge Ring(剑桥环形网络)尚未建成,他只能通过软件模拟来验证自己的构想。此前他在奥胡斯大学曾跟随 Simula 语言的共同发明人 Kristen Nygaard 深入学习过 Simula。Stroustrup 幽默地回忆起与这位计算机科学先驱的互动:“你其实并不能真正和 Kristen Nygaard 展开讨论;你开个头说一句话,他就滔滔不绝地给你讲上一阵子。但他是个极棒的人,我从他身上学到了很多。” 于是,Stroustrup 选用 Simula 编写了分布式系统模拟器。然而,代码刚在剑桥大学的大型机上运行,便“让整个大学的大型机跪倒在地”(brought the university mainframe to its knees)。在得出任何有效数据之前,模拟器对内存和 CPU 的巨大需求就彻底耗尽了计算资源。Stroustrup 指出,这实际上是系统模拟的常态——只要向模拟器中喂入更多数据、更多实体或延长运行时间,机器迟早会资源枯竭。但对于研究生而言,后果是致命的:“作为研究生,这种事你顶多只能干一次,之后就会被直接踢下机器,因为天体物理学家和化学家拥有好得多的资金支持和政治话语权。” ```mermaid flowchart TD accTitle: 剑桥博士期间的模拟器技术路线演进 accDescr: 展示了从Simula的高抽象低性能导致大型机崩溃,转向CAP与BCPL的高性能低抽象,最终促成二者结合的设计哲学。 subgraph SimulaRoute["Simula 方案"] A["高层抽象与模块化设计"] --> B["内存与 CPU 资源耗尽"] B --> C["大学大型机崩溃 / 被踢出机器"] end subgraph CAPRoute["CAP 计算机与 BCPL 方案"] D["CAP 机器 (能力机制架构)"] --> E["重写为 BCPL 代码"] E --> F["调试极其艰难 (掉了一半头发)"] F --> G["运行极快 / 跑出数据取得博士学位"] end SimulaRoute -->|"倒逼换用低层级工具"| CAPRoute CAPRoute --> H["形成核心理念:优雅与高效必须兼备"] ``` ### [28:16](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1696s) 转战 CAP 与 BCPL:确立“好代码必须高效”的设计哲学 为了避免与财大气粗的学科竞争大型机机时,Stroustrup 转向了剑桥实验室自主研制的 CAP 计算机。CAP 是一台基于能力机制(Capability-based)的机器,体系结构极具独创性但非常罕见,其冷门程度让天体物理学家、化学家以及绝大多数计算机科学家都望而却步。CAP 上可供选择的编程语言极少,主要是在缺少垃圾回收机制的 Algol 68C 与纯 BCPL 之间权衡。由于此前有过用硬件实现 BCPL 的经历,Stroustrup 对 BCPL 的底层运作驾轻就熟,最终决定用 BCPL 将整个模拟系统重写一遍。 重写付出了沉重代价:Simula 原本优美的类结构、高层组织方式和便于排错的设计全部荡然无存。Stroustrup 回忆,在经历艰难的调试并“在这一过程中掉了一半头发”之后,BCPL 代码终于运转起来,不仅速度极快、能压榨出硬件的全部性能,还能直接与机器上的任何底层接口通信。他借此顺利拿到了博士学位,但这段痛苦的折腾经历催生了他终身坚持的技术信念: > “如果让人在编写‘好代码’还是‘快代码’之间做选择,那一定是哪里出了问题;好代码本身就应该跑得快。”(“If you give people the choice of writing good code or fast code, there's something wrong; good code should be fast.”) - **Simula 的教训**:表达能力出色、抽象优美、极易用于设计和排错,但由于底层运行开销过大,根本无法胜任大规模真实系统的负荷。 - **BCPL 的教训**:执行极其高效,能随心所欲控制机器资源,却剥夺了程序员组织大型系统所必需的高级抽象结构。 - **终极设计诉求**:绝不在“优雅”与“高效”之间妥协,必须打造一种既有 Simula 般抽象能力、又有 BCPL 般底层性能的工具。 ### [30:38](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1838s) 拒绝象牙塔:求职碰壁与贝尔实验室的转折 博士毕业后,Stroustrup 坚定地排除了留校任教的选项。他尖锐地批评了那种从学生直接无缝转为教师的学院路线:“如果一个老师的前一份工作就是当学生,那从根本上就是有问题的,这近乎一种近亲繁殖;里面必须得有真实世界的经验。”缺乏工业界或现实经验的教学,不仅削弱了授课内容的说服力,也降低了师生间知识传授的效能。 出于对故土的喜爱,他原本极度渴望返回丹麦工作。然而,当时丹麦计算机界弥漫着一种封闭心态——人们笃信“凡是正确优秀的东西都已经在丹麦被发明了;既然你做的东西丹麦没人做,那你一定是搞错了”。大学里的教职往往只留给在本地按部就班熬资历、跟随学术潮流的人,而他在分布式操作系统方面的研究在当时的丹麦属于冷门。他在丹麦接到的工作意向也让人啼笑皆非:一份是去写 COBOL 代码,这极可能毁掉他的技术生涯;另一份则是为政府机构工作,内容似乎就是在哥本哈根外的海峡数潜艇。 柳暗花明的是,剑桥实验室与贝尔实验室(Bell Labs)之间素有学术往来。在剑桥著名的老鹰酒吧(The Eagle)喝啤酒闲聊时,Sandy Fraser(或 Steve Bourne)对他说:“如果你找工作,给我们打个电话。”Stroustrup 随即联系了贝尔实验室计算机科学研究中心,并自费飞越跨大西洋前往新泽西面试。到达时,迎接他的 Sandy Fraser 却冷冷地让他坐下,并劈头扔下一句:“你来得真不是时候,我们现在一个职位空缺都没有。”对于一个刚下飞机、顶着严重时差、银行存款所剩无几的年轻人来说,这堪称最糟糕的开局。Sandy Fraser 先安排他去了一个偏工程开发的部门做学术报告。令人惊喜的是,Stroustrup 的技术报告打动了全场,评审组立即回心转意,将他专车送回计算科学研究中心进行全套深度面试。一周后,他就拿到了正式录用信,在此开启了长达 16 年的职业生涯。 ### [34:32](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2072s) C with Classes 诞生:嫁接 Simula 抽象与 C 语言性能 进入贝尔实验室后,Stroustrup 雄心勃勃地打算依托实验室充足的人力与设备资源,真正实现他构想中的分布式操作系统。彼时贝尔实验室正处于 Unix 发展的黄金时代,内核作者 Ken Thompson、C 语言设计者 Dennis Ritchie,以及 Brian Kernighan、Doug McIlroy、Greg Chesson 等技术巨匠都近在咫尺。他们共享着 PDP-11/70 等机器,局域网与对称多处理器的发展雏形也已呼之欲出。 Stroustrup 的设计蓝图是将 Unix 内核的服务拆解成若干解耦的“模块”(即后来的对象),使它们既能在单机多处理器上并行执行,也能透明地跨网络节点分布。但在用 C 语言尝试重构数月后,他惊觉自己重蹈了当年的覆辙:纯 C 语言虽然紧贴硬件,却没有任何机制来界定模块的边界与共享规则;一切数据指针都直接在内存中随意穿刺,缺乏高层模块化与实体概念。当想要在概念架构层面思考系统时,C 语言的抽象维度显得过低。 经过深思熟虑,他发现不能走把底层硬件控制硬塞进 Simula 的死路,因为 Simula 的编译器不仅昂贵且难以移植,目标代码也无法直面底层硬件;唯一现实的出路,是把 Simula 顶级的面向对象抽象(类、继承等机制)移植并嫁接到 C 语言之上。这一思想直接孕育了 C++ 的前身——C with Classes。正如他总结的那样:“这里面有两个核心部分:直接操纵硬件的能力,以及从中进行抽象的能力,这样你就不必时刻紧贴着硬件工作。”在开发这个最初服务于自己项目的工具时,Stroustrup 深入走访实验室走廊里的同事,虚心听取大家在日常系统编程中的实际痛点,最终将广泛的工程实践经验沉淀到了这门新语言的设计之中。 ### [39:56](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2396s) 函数原型、资源管理与值语义:奠定 C++ 根基的早期抉择 在回顾 C++ 萌芽期的设计时,Bjarne Stroustrup 指出,他在项目极早期做出的几项关键决策从根本上塑造了这门语言。首先是引入了后来被称为“函数原型”(function prototypes)的机制。当时的 C 语言缺乏强有力的接口检查机制,甚至连像 `sqrt(2)`(传入整型而非浮点型)这种基本调用都无法自动转换并被视为非法程序,这让 Stroustrup 无法忍受。当他向贝尔实验室的同事 Sandy Fraser 抱怨 C 的这一缺陷时,Fraser 随口反问他:“那你为什么不直接修好它呢?”(“Why don't you just fix it?”),Stroustrup 便动手加上了原型检查与类型转换。 第二个奠基性的概念是构造函数(Constructor)与析构函数(Destructor)。翻阅自己最早期的笔记,Stroustrup 就明确写道:需要构造函数来构造对象、获取运行所需的资源,用现代术语来说就是“确立类的不变量”(establish an invariant);而当对象使用完毕时,则需要析构函数来“收拾残局”(clean up the mess)。这一机制构成了现代 C++ 资源管理(即后来的 RAII)的核心。 更关键的分水岭在于对“用户自定义类型”的处理。在诸如 Simula 等先驱语言中,语言在语义上割裂为两块:内建类型直接分配在栈上且具备值语义(Value semantics),而用户通过 `new` 创建的类型必须生存在自由存储区(堆)上并遵循引用/指针语义(Reference/pointer semantics)。Stroustrup 极为反感这种人为的人为区隔: > “我从来无法理解,为什么整型可以作为一个普通变量直接存在,而复数——因为是我自己定义的复数——就必须放在自由存储区并用 `new` 来分配;从根本上讲,它们就是同一种东西。”(“I never could understand why an integer was something you could have a variable of and a complex number because I defined the complex number was something you had to put on the free store and allocate with new I mean these are fundamentally the same thing.”) 当时 Douglas McIlroy 也曾对他说过一句精辟的名言:“复数一点都不抽象,它和实数一样真实。”(“There's nothing abstract about a complex number, it's as real as reals.”)。因此,在最初的数周到一个月内,函数接口检查、带有构造/析构函数的类以及对值语义的原生支持就已全部就位,这构成了整门语言坚不可摧的底层基石。 --- ### [42:51](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2571s) 拒绝全盘托管:栈分配的极致性能与务实哲学 面试官 Paul McJones 指出,20 世纪 70 年代学术界对可扩展语言和抽象数据类型展开了海量探讨,但绝大多数研究最终都被基于引用的继承模型牵着鼻子走,唯独 Stroustrup 坚持走通了另一条路——赋予用户自定义类型与内建基础类型完全相同的地位与掌控力。 Stroustrup 回忆,这也是他对 Simula 最为不满的地方。他曾就此与 Simula 的发明者 Kristen Nygaard 探讨,Nygaard 坦言将自定义类型扔到堆上是不得已为之,否则根本无法构建垃圾收集器(Garbage Collector);后来 Stroustrup 询问 Ole-Johan Dahl 为何 Simula 不支持多重继承,Dahl 也给出了相同的回答:在多重继承下无法构建出高效的垃圾收集器。 但对于从事系统底层软件开发的 Stroustrup 而言,他追求的是极致的执行效率,根本无法承受垃圾收集器的开销。堆分配在底层非常昂贵,而把对象放在栈上能够获得最严密的控制权、最自动化的资源生命周期管理以及最高的执行性能。这一想法在他离开剑桥大学时就已在心中酝酿——并非当时就立志要做一门语言,而是为现有语言做不到这点深感困扰。虽然学术上 Algol 68 具备优秀的栈模型,但他深知如果改造 Algol 68 将是极其愚蠢的做法,因为没有工业界开发者喜欢它;若想在现实世界产生真正的影响,就必须站在已被广泛接受的现行潮流(即 C 语言)之上。 ```mermaid flowchart TD accTitle: Value Semantics vs Reference Semantics Comparison accDescr: 对比 Simula/托管语言与 C++ 在用户自定义类型内存布局与生命周期管理上的差异 subgraph Simula_Model["传统面向对象/托管语言模型 (Simula 等)"] A1["内建基础类型 (int, float)"] -->|栈分配 / 值语义| B1["直接存取, 零额外开销"] A2["用户自定义类型 (Complex, Point)"] -->|强制堆分配 / 引用语义| B2["垃圾收集器 (GC) 介入管理"] end subgraph Cpp_Model["C++ 核心设计模型"] C1["内建基础类型 与 用户自定义类型"] --> D1{"统一一等公民设计"} D1 -->|栈分配 (默认)| E1["值语义: 确定性生命周期 / 零GC开销"] D1 -->|堆分配 (按需)| E2["构造函数建立不变量<br>析构函数严格自动清理"] end ``` --- ### [46:12](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2772s) 意外的转向:从分布式系统研究到全职语言支持 语言最初的诞生仅仅是为了满足自身的研究需要。在构想中,Stroustrup 希望编写一套模拟程序来设计分布式系统架构。作为基于宏与转换脚本的预处理器,C with Classes 起步非常轻巧。然而发布仅六个月,他就迎来了第一位真实外部用户。 一旦有了用户,就带来了维系其项目成功的沉重责任。随着使用者几何级数增长,Stroustrup 的工作重心彻底偏移:他不仅要持续演化语言规范,还要亲自撰写文档、编写入门教程、四处奔波“扑灭技术火灾”(fighting bush fires)、开班培训并辅导项目落地。 > “我当时彻底分心了,在接下来的十年里,我一直在做这种语言设计与用户支持的结合工作;有很长一段时间,我一个人就是整个项目的服务支持台。”(“I got totally distracted and 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.”) 他半开玩笑地感慨,如果不是因为陷入了全职支持用户的泥潭,大家可能早在 1985 年左右就能用上 Unix 集群或 Unix 多核操作系统了。相比贝尔实验室内部 Unix、C 语言等由庞大团队分工维护的系统,在相当长的时间里,C++ 几乎完全依靠他一个人的单打独斗。 --- ### [48:03](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=2883s) 商业首发“棕袋版”与 Cfront 的跨平台移植奇迹 1984 年至 1985 年初,C++ 先后通过教育版和定向授权向学术界及特定合作者开放。1985 年 10 月,C++ 推出了第一个正式的商业版本,在内部被称为“棕袋版”(Brown Bag release)。之所以得此诨名,是因为其开发成本极低——Stroustrup 一个人包揽了 98% 的代码、文档、构建脚本及测试套件,从贝尔实验室公司的财务视角看,这几乎是“零成本”孵化的产物。面向高校的分发仅收取 75 美元,这仅仅是制作一盘磁带并邮寄的物料运费,实质上等于免费;而针对商业机构的源码授权费则高达约 40,000 美元,但企业获得了完整的源码许可证并能在其上开展业务。 在硬件兼容性上,Stroustrup 很早就意识到死守一种架构(如 PDP-11)是绝不可行的。他开发的编译器前端 Cfront 本质上是一个天然的交叉编译器,通过将 C++ 转译为目标机上的 C 代码,巧妙地借用了目标机既有的 C 编译器代码生成、汇编器、链接器以及调试工具链。 为了解决 C 语言在各硬件平台间细微的不兼容性,Stroustrup 发明了一套极简而高效的探测机制: - 他编写了一个小巧的探测程序,先放到目标系统上编译运行。 - 该程序会自动嗅探该机器的硬件特性(例如 `int` 的长度、指针大小、字符是有符号还是无符号等),并将参数生成一份环境描述文件。 - 用户把描述文件回传,Stroustrup 只要在编译时通过 Cfront 的 `+x` 参数将该文件注入编译器,Cfront 就会即刻将代码生成逻辑从本机视图切换为目标机视图。 - 面对 Cray 超级计算机或 Univac 这种极度古怪的异构架构时,移植可能需要整整一个月;但在绝大部分常规 Unix 系统上,整个移植适配过程被缩短到了仅仅 3 个小时。在没有现代大型自动化打包工具的年代,这种设计展现了惊人的工程效率。当 1.0 版本正式发运时,目标支持的硬件架构已经突破了 20 种。 ### [53:07](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3187s) 从 C with Classes 到 C++:运算符重载、虚函数与多重继承 在 1983 年至 1984 年的冬天,语言正式从 C with Classes 演化为 C++。Bjarne Stroustrup 回忆,当时驱动他设计新特性的核心需求之一是“值语义”(value semantics),因此他极度需要赋值运算符重载;而身边的同事则因从事机器硬件模拟等工作,迫切需要位运算符(如 `&`、`|`、`^`)的重载,加减运算符反而是后来才一并加入的。更具深远意义的突破是重载下标运算符 `[]` 与调用运算符 `()`,它们构成了日后 C++ 标准库中各种容器与函数对象(function objects)的基石。 虚函数(virtual functions)也是在这一阶段正式引入的。Stroustrup 虽然早在 Simula 中就了解并熟悉该机制,但起初在贝尔实验室完全无法说服其他人接受虚函数的价值。当时主流程序员的反响充满怀疑,他们质问:“你想调用一个函数,却连它究竟是哪一个都不知道?难道你没分析过自己的问题吗?”(“You want to call a function and you don't know which one it is? Haven't you analyzed your problem?”)还有人提出,如果非要实现这种间接调用,用函数指针不就可以解决?Stroustrup 则坚决反驳,认为完全靠手写函数指针在大型工程中根本无法规模化管理,也无法进行体系化教学。 伴随类层次结构而来的还有多重继承(multiple inheritance)。Stroustrup 当时认为自己确实需要这一特性。尽管多年来这被许多人诟病为语言设计上的失误,但他指出,如今几乎所有具备接口规范能力的语言都在使用多重接口继承;看到像 Java 8 这样的语言最终也以某种形式引入了多重数据/行为继承(如默认方法),他感到相当欣慰: > “I guess the main reason I'm mentioning it is that I've had so many years being told it was a design error, so it's interesting to see another major language adopting it in some form.”(我想我提到这件事的主要原因是,多年来我一直被人告知这是一个设计错误;因此看到另一种主流语言也以某种形式采纳了它,确实很有意思。) --- ### [55:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3337s) 泛型类型的探索:宏的局限与模板的三大设计目标 在发布了 CFront Release 1 与 Release 1.2 之后,Stroustrup 在经历数年忙乱后终于有时间静心思考更深层的问题,特别是错误处理(error handling)与泛型(generic types)。其实早在 C with Classes 的第一篇论文中,他就已经阐明了为什么需要对类似向量(vector)的结构进行类型参数化:程序员要的绝不只是针对 `double` 或 `int` 的特化版本,而是能够容纳任意类型 `T` 的通用向量 `Vector<T>`。当时他天真地声称通过 C 预处理器宏就能解决问题,但后来他意识到宏只适合一两个彼此极为熟悉、高度协同的程序员;一旦面对庞大的用户群体,重度依赖宏便会带来灾难。 为了寻找真正可扩展的解决方案,Stroustrup 着手设计了模板(templates),并为此确立了三大核心设计目标: 1. **通用性(Generality)**:语言设计者绝不能自以为是地限定用户能做什么。他曾深受那些“只允许你做设计者认为合适的事”的语言之苦,因此必须确保机制足够通用。 2. **零开销抽象原则(Zero-overhead principle)**:这是 Stroustrup 的立身原则,即“使用抽象机制时的运行速度,绝不能低于直接使用基础底层语言手写的最优代码”。他极其厌恶原始的 C 风格数组,认为其只是一段固定大小的内存硬件抽象,既不知道自身大小,又动辄隐式退化为指针并随意转换,是程序缺陷的最大温床。他迫切希望用类似 `std::vector` 的安全类型彻底淘汰 C 数组,而前提是抽象机制的开销必须完全匹敌原始数组。 3. **良好的接口定义(Well-specified interfaces)**:能够清晰界定类型参数的约束条件与接口约定,从而保障代码的模块化。 然而在当时的技术条件下,三者不可兼得。在鱼与熊掌之间,Stroustrup 别无选择地优先保留了通用性与零开销,被迫在接口规范上做出了妥协。 ```mermaid flowchart TD accTitle: 模板的三大设计目标与妥协 accDescr: 展示 Stroustrup 为模板设定的通用性、零开销以及良好接口三个目标,以及受时代限制放弃接口约束的妥协。 subgraph CoreAims["模板的核心设计目标"] G["通用性<br/>(Generality)"] Z["零开销抽象<br/>(Zero Overhead)"] I["良好的接口规范<br/>(Well-specified Interfaces)"] end subgraph 1988Outcome["1988 年模板的现实妥协"] G --> P1["成功达成:完全通用的泛型编程"] Z --> P2["成功达成:直接生成高效机器码,比肩原生 C 数组"] I -.->|"当时无法无开销实现"| P3["暂时放弃:导致报错晦涩繁琐<br/>(后由 Concepts 弥补)"] end ``` --- ### [59:45](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3585s) 漫长的“概念”(Concepts)之路与性能开销的权衡 由于缺乏直接的接口约束机制,1988 年问世的模板虽然取得了巨大成功,但也遗留了显著缺陷:编译错误信息极其冗长晦涩,代码编写也过于复杂。为了解决这一痛点,设计团队进行了长达三十多年的探索。2002 年前后,委员会曾尝试推进某种接口机制,但过程被两股思潮带偏——一方试图做纯粹的面向对象接口,另一方则希望全面效仿 Haskell。这两种方案都不可避免地引入了虚表(vtable)或间接跳转表,而为了消除这些间接开销,编译器需要进行极其费力且无法在工业级大型软件中可靠扩展的“英雄式优化”(heroic optimizations): > “You can get really good performance of a sort of a POPL-sized program fits in a in one column in a POPL paper, but if you're doing it in industrial scale software, the optimizations don't get good enough and you get costs as if you're going through a interface to a abstract class or something, which we can't afford—not if you want to compete with arrays.”(对于能在 POPL 论文排版里占一栏的小型示范程序,你或许能获得极高的性能;但如果是面对工业级规模的软件,这类优化根本达不到足够好的效果,你将付出等同于通过抽象类接口调用的性能代价。只要我们还想与原生数组竞争,这就绝对无法承受。) 采访进行时(2015 年初),C++ 委员会刚刚投票将 Concepts 技术规范(TS)提交至国家机构表决阶段。Stroustrup 介绍,前博士后研究员 Andrew Sutton(当时任职于阿克伦大学)已在 GCC 分支中实现了该特性。这一机制融合了包括采访者 Paul McJones、泛型编程大师 Alex Stepanov 以及 Stroustrup 本人在内的多年心血:Stepanov 主导了其语义内涵与表达模型的设计,而 Stroustrup 则着力于使语言层面的语法表达尽力保持简洁清晰。 --- ### [01:02:27](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3747s) 零开销原则的现实意义:为什么性能关乎机房数量与能耗 针对零开销原则,Paul McJones 指出其渊源可追溯至 John Backus 与早期的 Fortran 项目:Backus 的目标就是让科学家既能方便地表达问题,其生成代码的效率又不会输给当时专业的汇编程序员手写优化。Stroustrup 极为赞同这一对比。他坦率承认,现代手机的算力已经是当年开发 C with Classes 所用的 PDP-11 或 VAX 小型机的上千倍,内存亦然;在很多上层业务领域,哪怕浪费 95% 甚至 99% 的算力也无可厚非。 然而在系统的最底层——图形渲染、视频解码、网络协议栈、数字信号处理以及需要全球最大型计算机连续运行数月的超级计算中——效率关乎生存: > “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. This can be measured very easily: you just count cooling, twice the maintenance, twice the monitoring, twice everything.”(看看 Google 或 Facebook 的服务器集群,如果你使用的语言原生性能只有一半,你就需要两倍数量的机房集群。这非常容易衡量:直接算算两倍的制冷能耗、两倍的维护成本、两倍的监控投入,所有一切都要翻倍。) 正是由于在网络基础设施与系统底层能带来相对于其他高级语言 2 倍、4 倍、10 倍乃至 50 倍的性能优势,C++ 才能在现代工业体系中不可替代、历久弥新。 - **版本更迭节点**:1983 至 1984 年冬,C with Classes 正式转变为 C++;1988 年正式确立模板设计。 - **Concepts 推进时间线**:经历了 1981 年的遗憾与 2002 年的弯路,终于在 2015 年通过国家委员会投票形成技术规范(TS),并由 Andrew Sutton 在 GCC 分支中落地。 - **算力与硬件参照**:现代移动设备的算力与内存规模已达到当年 Bell 实验室 PDP-11/VAX 机器的 1000 倍以上。 ### [01:05:33](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3933s) C++ 标准化的缘起:“被公交车撞倒”假说 谈及 C++ 走向标准化的历史,Bjarne Stroustrup 澄清这并不是他自己的初衷。当时惠普(HP)的 Dmitry Lenkov 和一位来自 IBM 的代表径直来到他的办公室,提出希望对 C++ 进行 ANSI 标准化。Stroustrup 最初极力反对,认为这是一个愚蠢的想法,因为当时的语言尚未完善,他还需要更多时间来演化和设计。 然而两位说客给出了一个让他无法反驳的工业界现实理由:大型工业界无法依赖一门随时可能因为“设计与实现团队被公交车撞倒”就彻底停摆的编程语言。Stroustrup 回忆说,虽然对方态度非常礼貌,但他依然试图争取时间,最终在对方的坚持下只能举手投降:“‘哎哟哎哟哎哟,好吧,我做,我做,我们明年开始。’”(“ow ow ow yes I'll do it I'll do it we'll do it next year”)。尽管他们商定第二年启动,第一次委员会会议最终在当年的 12 月便迅速召开了。Stroustrup 坦言,自己当时整天忙于自己的技术工作,根本没有意识到标准化是多么势在必行。 ```mermaid flowchart TD accTitle: C++ 标准化推动历程 accDescr: 展示惠普与 IBM 代表如何说服 Bjarne Stroustrup 启动 C++ 的 ANSI 标准化进程 subgraph External ["工业界推动"] A["HP 的 Dmitry Lenkov 与 IBM 代表"] B["提出关键痛点:<br/>工业界无法承受语言设计者'被公交车撞倒'的单点风险"] end subgraph Internal ["Stroustrup 的回应"] C["最初反对:<br/>语言尚未设计完成,需要更多演进时间"] D["被迫妥协:<br/>同意成立委员会并于 12 月召开首次会议"] end A --> B B --> C C --> D ``` - 来访推动标准化的核心人物为 HP 的 Dmitry Lenkov 以及一位 IBM 代表。 - 启动标准化的根本动力是工业界对单点故障(如设计者意外丧命)的风险规避。 - 首次标准化筹备会议于当年 12 月正式召开。 --- ### [01:07:24](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4044s) 标准委员会内部的博弈与体制困境 Stroustrup 将 ANSI 及随后的 ISO 标准化进程形容为一件“极其令人头疼的事”(a huge pain in the neck)。大量人员投入了极其艰苦的劳动,却往往对语言的未来走向缺乏清晰的共识。委员会内部派系林立,各执一词:一部分人希望放慢演进步伐,认为只要遏制变化就能获得稳定优良的语言,创新应当留给别人;另一部分人则热衷于追逐技术潮流。在整个 1990 年代,许多人极力主张抛弃 C 语言的底层包袱,将 C++ 改造成一门纯粹的面向对象语言;与此同时,委员会中还有大量对面向对象不屑一顾的成员,坚决主张让 C++ 尽可能贴近 C 语言。 在这种环境下保持清晰的设计方向异常艰难。Stroustrup 指出,委员会体制最大的缺陷在于缺乏专项资源:没有一个全职的演进或设计小组去深入实验语言的未来蓝图,整个委员会都在疲于应付抛光、校验和兼容性问题。尽管后来引入了并行工作的研究组(Study Groups)和内部小组,但各个组之间的沟通成本与隔阂又带来了全新的问题。 - 1990 年代委员会内部关于“全盘彻底面向对象化”与“坚守 C 语言底层兼容”之间存在长期拉锯。 - 标准化组织缺乏能够全职从事重大语言特性验证与实验的资源。 - 为分担工作设立的 Study Groups 带来了一定的效率提升,但也引发了跨组沟通协调的难题。 --- ### [01:09:41](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4181s) 语言设计者的痛苦:身处委员会的独特性与妥协 采访者 Paul McJones 问及,在他人不断向语言塞入特性和提议的过程中,作为首席设计者是否有一种“女儿长大出嫁”般的复杂感受。Stroustrup 苦笑表示这并不贴切,真正令人煎熬的是两种情况:一是当有人试图将语言引向自己坚决反对的方向时,必须竭尽全力去踩刹车;二是当自己对正确方向深信不疑时,其他人却以“这做不到”为由推脱,或是为了追逐时尚而把方案搞得过度繁琐复杂。 Stroustrup 坦言,自己的判断并非每一次都完全正确,委员会这道刹车有时确实避免了他误入歧途;但在委员会这种庞大体系下,个人不可能无处不在,不可避免地会导致一些本不该通过的特性被写入标准。他感慨其他语言要么由与原作者脱节的委员会掌舵,要么依赖“终身仁慈独裁者”(BDFL)模式,而像 C++ 这样由原设计者始终深度参与 ISO 标准化全过程的案例几乎绝无仅有。正如他所总结的:“标准流程有其优势和劣势,如果你是语言设计者,这过程当然非常痛苦,但或许又是必不可少的。”(“going through the standard process has its strength and weaknesses and it's certainly very painful if you're the language designer but possibly necessary”)。 --- ### [01:11:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4302s) 让简单的事情变简单:C++11 与 C++14 的语法演进 谈到《C++ 程序设计语言》最新版中所流露出的满意情绪,Stroustrup 欣慰地指出,C++11 和 C++14 已经成为好得多的生产力工具。这很大程度上源于他长期践行的核心设计理念——“让简单的事情变简单”(make simple things simple)。许多在 C++11 中让开发者最感振奋的并不是深奥的高级特性,反而是那些能够减少冗余样板代码、降低犯错几率的简化特性: 1. **基于范围的 for 循环(Range-based for loop)**:让容器遍历变得直观自然。 2. **`auto` 类型推导**:类似于其他语言中的 `var` 或 `let`。Stroustrup 透露,他早在 1983 至 1984 年间就已实现了 `auto`,但当时因为与 C 语言关键字兼容性冲突以及“当时没人能理解它的用途”而被迫删去,直到 C++11 才得以重见天日。 3. **协程(Coroutines)**:这同样是他早年就着手研发却历经数十年未能推入标准的特性,如今也已排上日程。 Stroustrup 澄清,自己并不认同当下一味追求极致缩减代码敲击量(minimizing typing)的极端潮流,因为过度省略会导致代码丢失意图,而代码“被阅读的次数远多于被编写的次数”。但 C++ 此前的确过于冗长,语法简化的实质是提升表达的清晰度。 --- ### [01:13:22](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4402s) 概念(Concepts)与强类型接口范式 在讨论泛型语法的简化时,Stroustrup 以概念(Concepts)为例进行了对比。在传统的泛型语法中,声明一个排序函数往往需要极其冗长晦涩的模板前缀: ```cpp template<typename I> void sort(I first, I last); ``` 而在引入 Concepts 后,代码可以直接写成: ```cpp void sort(Sortable& c); ``` 这种形式回归了他在 1982 年左右习惯的经典函数声明风格。从理论模型上看,Concepts 将传统上“类型的类型”这一旧观念泛化为“一组满足特定准则的类型与值”。例如在合并操作中,可以通过 `Mergeable` 约束两个输入流和一个输出流之间必须满足的交互规范。 针对 McJones 提出“C++11/14 是否让编程体验变得像脚本语言”的疑问,Stroustrup 坚决否定了这一说法。他指出,现代 C++ 的类型系统实际上比以往更加严格,而且是完全的**静态强类型**。脚本语言依赖运行时的“鸭子类型”(duck typing),传统 C++ 模板在某种程度上也类似于静态层面的鸭子类型;而 Concepts 的核心目标正是彻底摆脱鸭子类型,转向全面基于显式接口(interface-based)的计算模型。 --- ### [01:16:01](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4561s) 与 Alex Stepanov 的交锋:STL 前夕的 Ada 争论与混合算术分歧 在谈及 Concepts 的源起时,话题自然延伸到了 STL 之父 Alexander Stepanov。Stroustrup 回忆了与 Stepanov 早期结识的经历:Stepanov 曾在通用电气(GE)工作,后来跳槽到 AT&T 的某个部门。在 Stepanov 构思出 STL 之前,两人在 AT&T 期间展开过密集的学术探讨。 当时 Stepanov 主要使用 Ada 语言来表达其泛型算法思想,并极力劝说 Stroustrup 采纳 Ada 的设计模式。Stroustrup 从中汲取了大量灵感,但坚决拒绝照搬 Ada 的技术路径。他明确拒绝了两个特性: 1. 拒绝像 Ada 那样引入显式的语句来实例化泛型类型; 2. 拒绝强行禁止类型转换的严苛限制。 Stroustrup 特别指出,他和 Stepanov 在混合模式算术(mixed-mode arithmetic)的设计哲学上至今仍存分歧:Stroustrup 坚持认为允许 `double` 与 `int` 直接相乘是实用编程不可或缺的便利,尽管这在泛型上下文中不可避免地会引入额外的类型推导复杂性。 ### [01:17:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4645s) STL 的诞生与 Bjarne 最初的审美冲击 Bjarne Stroustrup 回忆起从 Alex Stepanov 那里学到的设计洞见:能够将一切彻底内联(inline)的重要性,以及绝对不能丢失类型信息。这些理念完美契合了 Bjarne 长期以来在设计中所坚守的“零开销原则”(zero-overhead principle)。在 Alex 离开后,Bjarne 亲手实现了 C++ 模板(templates)的第一个版本。不久之后,通过 Andrew Koenig 的引荐,Alex 的成果以 STL(Standard Template Library,标准模板库)的形式重新出现在 Bjarne 眼前。 面对刚成型的 STL,Bjarne 的第一反应是极其排斥:“老实说,我觉得它看起来丑陋极了,而且完全显得不合常理(To be honest I thought it looked really ugly and it certainly looked completely wrong)。”当时包括他在内的整个编程界都深受面向对象思想的禁锢,普遍认为容器库必须是面向对象的——理应包含一整套严格的容器继承层级,以及与之对应的迭代器(iterators)继承层级。然而 STL 彻底打破了这一套体系。它在底层依赖于“概念”(Concepts)的抽象哲学(尽管当时没有任何语言层面的机制支持),完全基于泛型编程(generic programming)构建。尽管设计看起来极其异类,但从机器运行的角度来看,STL 满足了零开销原则,所生成的机器码异常精美高效。更为重要的是,它不是一个单纯的容器库,而是将容器与算法深度融合;在 Alex 看来,它甚至是一个附带了一些容器的“算法库”。 ```mermaid flowchart LR accTitle: STL 架构核心解耦关系 accDescr: 展示 STL 如何通过迭代器在泛型算法与各类数据容器之间建立统一抽象接口 subgraph Algo ["通用算法层 (Algorithms)"] A["sort / find / for_each 等算法"] end subgraph Iter ["抽象接口层 (Iterators / Concepts)"] B["泛型迭代器与 Concept 契约"] end subgraph Cont ["数据结构层 (Containers)"] C["vector / list / map 等容器"] end Algo -->|"遍历 / 访问"| Iter Iter -->|"解引用 / 操作"| Cont ``` - Bjarne 多年间总结过一份优秀容器库的设计标准清单(收录于《C++程序设计语言》第三版),共包含约 11 条准则。 - 经过几天仔细对照评估,Bjarne 惊讶地发现 STL 居然满足了其中 10 条(或 12/13 条之多),除了一项尚未达成外,其余表现无可挑剔。 - 唯独缺少的一项特性是“为所有容器或所有迭代器提供共同的基类设施”,例如统一的调试接口或序列化功能;但除此之外,STL 彻底超越了市面上所有现存方案。 --- ### [01:20:37](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=4837s) 标准委员会的激辩与将 STL 推入 C++ 标准 尽管 STL 的品质毋庸置疑,但 Bjarne 心知肚明,让 ANSI/ISO 标准委员会接纳这样一套前所未见的激进架构,几率极其渺茫。然而这套设计实在太优秀,必须放手一搏。为此,Bjarne 和 Andrew Koenig 联合在委员会内部积极运作,并特意将 Alex Stepanov 邀请到了会议现场。Bjarne 赞叹 Alex 是极其出色的布道者和煽动者,以无人能及的激情感染了委员们。 在随后的漫长博弈中,阻力接踵而至。在一次会议中,针对 STL 的复杂性、晦涩度和代码的“丑陋”,委员会内部爆发了苛刻的指责。这时,Boost 库的创始人之一 Beman Dawes 站了出来,给出了一记强有力的助攻:“你们知道吗,我原本也是这么想的,但自上次会议后,我试着自己去写了写看,实现了其中大约十分之一的内容;你们都错了,它并没有那么复杂,实现起来相对容易,而且比我们正在做的东西要干净得多。”这番基于实操的证言极大扭转了委员会的消极氛围。 - 当时各大商业软件公司都开发了各自专有的面向对象容器继承层级体系,库标准化阻力巨大。 - Texas Instruments 原定在某天午饭后正式提案其自研的优秀面向对象容器库;消息在午餐期间传开后,IBM、Microsoft、Borland 以及 GNU 阵营等巨头纷纷施压,扬言一旦讨论 TI 的方案,委员会也必须同步审议各自公司的专有容器库。 - 面对注定无法妥协的商业阵营割裂,STL 凭借迥异的泛型架构以及独创的算法体系,跳出了面向对象继承层级的恶性内卷,奇迹般成为了唯一的突破口,历时数年最终被正式接纳为 C++ 标准库的核心。 --- ### [01:23:44](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5024s) 模板元编程的混乱与 Concepts 的引入动因 随着 STL 的广泛普及,模板系统的局限性也迅速演变为全行业的痛点。Bjarne 指出,对“概念”(Concepts)语言特性的迫切需求主要来自两个方面:其一是模板实例化失败时,编译器喷涌出令人绝望的、长达数屏的低质错误信息;其二是程序员们对模板隐式提供的“编译期鸭子类型”(compile-time duck typing)走向了极端的狂热。由于缺乏正式的接口契约定义,模板实现的底层细节被迫暴露,社区写出了大量能完成惊人操作、却复杂到无法理解和维护的晦涩代码。 Bjarne 强调,引入 Concepts 的根本目的在于为传统泛型编程以及部分模板元编程赋予规范严密的“类型接口”(proper interfaces)。在泛型应用中,并非所有领域都能直接套用语义概念;例如表达式模板(expression templates)本质上是在操纵单纯的语法树结构,在最终求值之前并不具备语义含义,这类特化场景仍然需要其他手段来解决。 “我的观点是,我们需要 Concepts 来为传统的泛型编程以及某些模板元编程引入正式的接口(So my view is we need Concepts for the traditional generic programming and for some of the template meta programming to introduce proper interface)。”—— Bjarne Stroustrup 阐明了 Concepts 规范类型契约的初心。 --- ### [01:25:12](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5112s) `constexpr` 与编译期计算的范式正规化 伴随着模板技术的发展,程序员们逐渐挖掘出了模板不仅仅能用来生成类型,还能用来生成诸如 `2`、`32` 或 `99` 这样的数值,由此催生了被称为模板元编程(TMP)的领域。早期许多最古怪、最难以阅读的 C++ 代码正是出自此类数值推导。针对这种异化的现状,Bjarne 与 Gabriel Dos Reis 展开合作,探索一种更干净、自然的编译期计算方案,并最终创造了 `constexpr`。 在嵌入式编程世界中,开发者长期依赖 C 预处理器宏来进行编译期配置,从而沦落到毫无类型保护的境地;而在 C++ 模板界,开发者依靠偏特化和递归实例化来实现编译期数值运算,又陷入了缺乏约束的鸭子类型泥潭。Bjarne 认为,计算数值的本质应当就是调用普通的函数:输入一组明确类型的参数,计算并输出特定类型的结果,“就像我们第一次学习编写函数那样简单直观”。这一设想在 C++11 中落地,并在 C++14 中得到了大幅放宽,允许在 `constexpr` 函数内部编写循环和局部变量。 - `constexpr` 函数的核心法则:所有运算必须在编译期完成,因此严禁产生外部运行时的副作用,在本质上属于纯函数(pure functions)。 - 函数执行期间的所有内部状态仅存于计算过程本身,不会污染外部环境。 - 治理病态模板元编程的双重战略:通过 Concepts 规范常规泛型接口,通过 `constexpr` 将编译期数值计算引导回常规函数形式;同时,`constexpr` 函数本身也可以是受 Concepts 约束的模板函数。 --- ### [01:28:10](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5290s) 从仿函数到 Lambda 表达式的演进 探讨现代泛型与函数式风格时,Bjarne 追溯了函数对象(Function Objects / Functors)在 C++ 中的起源。早在 1983 年,Bjarne 便允许在类中重载调用操作符(即 `operator()`),这就是函数对象的开端。随着 STL 的成熟,函数对象作为向泛型算法高效传递可定制操作的手段,成为了语言体系的基石。 当 C++11 引入 Lambda 表达式后,许多人将其视为全新的高深特性,但 Bjarne 揭示了其本质不过是已有机制的语法糖。C++ 中的函数对象是包含 `operator()` 的实体,而 Lambda 表达式仅仅是在调用处“就地生成未命名的局部函数对象”,并在需要时将其触发。正因如此,Lambda 在运行时的性能与手写函数对象完全一致,甚至能够通过编译器对栈帧和内联的深度优化达到更极致的速度。至此,现代 C++ 顺理成章地构建起了一套高度自洽且运行极为高效的函数式编程支撑体系。 ### [01:29:24](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5364s) 统一范式与多范式语言的演进 Bjarne Stroustrup 回顾了 1970 年代以来编程语言的核心思想——包括面向对象编程、抽象数据类型(ADT)以及底层硬件编程,强调这些并非分散孤立的概念,而是全部统一在 C++ 的同一个框架之中。他特别以 Lambda 表达式为例指出,很多人以为这是突兀加入的新特性,但 Lambda 的底层本质依然是函数对象(Function Object),而函数对象早在 C++ 诞生的“第零天之前”就已经存在了。尽管代码中积累了大量历史遗留的语法包袱(barnacles),使得编写代码变得繁琐复杂,但其深层机制依然具备严密的内在逻辑。 Stroustrup 坦陈自己在 1980 年代并未深入接触函数式编程,当时他对抽象数据类型、类层次结构以及贴近机器的底层操作了如指掌,而函数式思想(尤其是源自 Lisp 阵营的诸多概念)则是随着时间推移逐步成熟的。如今 C++ 吸收了函数式编程的诸多特性,但它们都与语言中早已存在的既有机制紧密缝合在了一起。 --- ### [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) 构想“十分之一体积”的轻量化 C++ 与资源安全 在访谈者 Paul McJones 提及第三届 HOPL(编程语言历史会议)论文后,Stroustrup 阐述了他长期思考的一个核心命题:能否设计出一种体积仅为现有 C++ 的十分之一、却完整保留其硬件操控能力与表达力的全新语言?Stroustrup 坚定地认为这完全行得通: > “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.” 围绕这一目标,Stroustrup 强调必须实现“资源安全(Resource Safety)”,而非仅仅是狭义的“内存安全(Memory Safety)”。他指出人们过度执着于内存安全是抓错了重点,在实际生产系统中,泄露文件句柄或套接字会比内存泄露更快搞垮整个系统。通过 Howard Hinnant 完善的移动语义(Move Semantics),现代 C++ 已经能够构建出一个杜绝资源泄漏的封闭体系。不过,垃圾回收(GC)无法解决一个深层矛盾:一旦将指向局部变量的指针存储起来并跨越栈帧生命周期,系统就会发生严重崩溃;如何在兼顾简洁、优雅、高效和易于教学的前提下彻底根除逃逸悬挂指针,仍是他持续探索的方向。他同时强调,这样的语言绝不能抛弃 C 语言基于对象、指针与物理内存直接映射的核心机器模型。 ```mermaid flowchart TD accTitle: C++ 资源安全与精简模型 accDescr: 展示从底层 C 内存模型出发,通过移动语义与生命周期管理,达成超越单纯内存安全的全面资源安全架构。 subgraph HardwareMapping["底层核心模型"] A["C 语言机器模型<br/>(对象 / 指针 / 内存映射)"] end subgraph SafetyLayer["安全与语义控制"] B["移动语义 (Move Semantics)<br/>(杜绝深拷贝开销与泄漏)"] C["栈生命周期管理<br/>(解决局部指针逃逸问题)"] end subgraph Target["终极目标"] D["全面资源安全 (Resource Safety)<br/>(文件句柄 / 锁 / 套接字 / 线程)"] E["1/10 体积的紧凑高性能语言"] end A --> B A --> C B --> D C --> D D --> E ``` - **资源安全涵盖范围**:除内存外,全面接管文件句柄(File Handles)、线程句柄(Thread Handles)、互斥锁(Locks)及网络套接字(Sockets)。 - **指针模型取舍**:精简语言可以彻底丢弃 C 的冗余语法,但绝不能放弃其直接映射硬件内存的对象与指针模型。 --- ### [01:33:41](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5621s) 贝尔实验室的黄金时代与工业研究的瓦解 访谈话题随后转向 Stroustrup 的个人职业生涯。Stroustrup 充满感情地回忆了 1980 至 1990 年代贝尔实验室(AT&T Bell Labs)的辉煌鼎盛时期。当时的计算机科学研究中心仅有 30 至 60 人,却诞生了难以计数的 ACM Fellow、IEEE Fellow 以及美国工程院院士。那里的科研文化摒弃指令性计划经济,依靠出色的部门主管和主任建立起一种兼顾自由探索与成果交付的平衡机制:既保证每年都有实际成果落地,又允许研究人员专注于耗时五到十年的长线课题。那里的人际氛围极其融洽,即便行业内不乏自命不凡之辈,贝尔实验室的大多数顶尖学者却谦逊温和。Stroustrup 在新泽西州默里山(Murray Hill)附近抚养孩子长大,称赞那里森林环抱,是个极佳的生活与工作之地。 然而,华尔街资本力量的介入彻底粉碎了这一理想环境。金融资本迷信“纵向一体化企业必死”,强行分拆贝尔系统,更抱有一种极其荒谬的偏见: > “They also had the idea that everything that can be invented has been invented so you don't need research or advanced development organization so you have to cut that.” 贝尔系统先遭拆分,随后 AT&T 与朗讯(Lucent)分道扬镳,硬生生将制造交换机硬件的团队与编写交换机软件的团队隔离开来,完全违背了软硬件协同的技术规律。后来在香农实验室(Shannon Laboratory,位于佛罗伦萨公园),由于 WorldCom 财务造假虚报行业前景引发连锁崩盘,华尔街再度强推严酷裁员。贝尔实验室在一场“大屠杀”式的裁员中失去了 40% 的博士员工。身为部门主管的 Stroustrup,甚至在事先未获任何通知的情况下被高层强行解雇了两名下属。管理层此举正是害怕他会当场暴怒。眼看着敢于在走廊拦下高管当面驳斥的优秀“刺头”纷纷离去,留下的人变得平庸乏味,Stroustrup 感到那里的科研氧气已被彻底抽干,即便保留着体面的拐角办公室,他也决心离开工业界。 --- ### [01:39:23](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5963s) 执教德州农工大学与学术界的研究异化 随着小儿子考入大学独立生活,在工业界打拼了 24 年的 Stroustrup 接受了学术界朋友的建议,于 2002 年加盟德克萨斯农工大学(Texas A&M University)担任计算机科学系首席教授。他认为自己拥有数十年的丰富实战经验,比起刚走出校门的年轻博士,能带给学生更多真正有价值的洞见。在德州农工大学期间,他大刀阔斧重构了本科核心课程,亲自给大学一年级新生和研究生授课,指导博士论文,带领该系在全美学术排名中跃升了约 20 名。 但在执教十余年后,学术生活逐渐变得沉闷停滞,Stroustrup 也深切感受到了高校纯学术研究的异化弊端。他批评学术界严重脱离工程现实,习惯于从现实问题中抽象出一层模型,再从抽象中提炼更深层的抽象,最终仅仅是在解决“抽象的抽象的抽象”,与最初的现实工程痛点毫无关联。更有甚者,真正贴合工业痛点的硬核系统研究反而在同行评议中饱受排挤。他举例提到,自己曾与 Gabriel Dos Reis 合作撰写了一篇关于抽象语法树(AST)重构的论文,该技术在性能上比 GCC 快了足足 30 倍。然而这篇成果却遭到审稿人无情拒稿,其中一个荒唐的拒稿理由竟然是审稿人认为身为 C++ 缔造者的 Stroustrup 自己“根本不懂 C++”。 - **德州农工大学学术建设**:全面重构本科生与研究生计算机教学体系,使该系在全美专业排名上升约 20 位。 - **学术界同行评议怪相**:Stroustrup 与 Gabriel Dos Reis 合作开发比 GCC 效率高 30 倍的 AST 实现方案,被审稿人以“作者不懂 C++”等荒谬理由拒稿。 ### [01:41:29](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6089s) 学术界对工程研究的偏见与重返工业界的契机 Bjarne Stroustrup 谈到了在学术界遭遇的令人沮丧的审稿经历。当时他们提交了一篇关于编译技术的重大改进论文,合作者包括标准委员会的法国代表(也是 GCC 的发布经理之一)。审稿人不仅错误地声称这项工作已经在 GCC 中实现过,而且在作者提出申辩后,给出的回复居然是:“哦,那是工程学,而我们是计算机科学家。” 对此 Stroustrup 感到非常气愤与无奈。他指出,如果这发生在汽车工程领域,有人将关键零部件的性能提升了 32 倍,那个人绝对会被当作英雄;但在计算机科学界,这项成果却历经多次波折才得以发表(如今该成果已被各大编译器广泛采纳)。Stroustrup 坦言,这种学术氛围极其磨人、令人灰心,尤其对培养学生非常不利:博士生必须依靠发表论文才能毕业,而现实中发表论文就不得不盲目迎合学术界的流行潮流(follow fashion)。 这种环境促使他萌生了重返工业界、去解决真实问题的想法,而不是停留在学术界那种经过层层提纯和净化的虚拟问题上。 ```mermaid flowchart TD accTitle: 学术界与工业界研究路径对比 accDescr: 对比学术界追求论文潮流与工业界直面真实性能问题的不同路径 subgraph Academia["学术界困境"] A["重大工程突破 (32倍性能提升)"] --> B["被指责为'只是工程而非科学'"] B --> C["必须迎合发文章的学术潮流"] C --> D["脱离真实的复杂场景"] end subgraph Industry["工业界现实"] E["真实的系统问题与物理约束"] --> F["直面性能与高可靠性挑战"] F --> G["演化具有实际价值的语言特性"] end D -.->|"驱动转变"| E ``` ### [01:43:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6188s) 加盟摩根士丹利:意料之外与“秘密武器” 多年来,Stroustrup 一直保持着在工业界和学术界巡回演讲的习惯。他通常用一场技术分享,换取与对方深入探讨实际工程痛点的机会,从而确保 C++ 的设计和演化始终拥有明确的现实方向。在纽约摩根士丹利(Morgan Stanley)做完一次演讲后,对方循例邀请他加入。 起初 Stroustrup 断然拒绝:“你们是一家银行,我做的这些东西根本不是你们感兴趣的。”对方表示非常感兴趣,他又提出自己的研究周期根本不适合金融机构:“有些我真正想做的事情,至少需要耗时五年。”但摩根士丹利方面毫不介意。真正促成他做出决定的,是对方一个连自己都没意识到的“秘密武器”:在所有符合他工作标准的机构中,摩根士丹利是唯一一家距离他的孙辈只有 20 分钟路程的公司。最终他接受了邀请,安家在介于孙子家和公司之间的地方,享受着理想的家庭与工作平衡。 - **调研方式**:通过技术演讲换取企业的真实业务问题反馈,以此校准 C++ 演化路线。 - **决定性因素**:办公地点与孙辈居所仅相距 20 分钟车程。 - **双重教职**:离开全职学术界后,他不仅受聘为哥伦比亚大学(Columbia University)教授并定期讲课,德州农工大学(Texas A&M University)也保留了他的教授头衔。 ### [01:45:00](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6300s) 金融领域的计算边界:绝对精准度与性能约束 在摩根士丹利,Stroustrup 的工作涵盖了网络架构、高阶代码表达方式以及极致性能调优。他指出,金融交易系统的核心需求依然极其贴近底层硬件,与他以往的研究方向一脉相承,但金融业务具备极为苛刻的正确性约束: > “他们确实有一个很有趣的要求:你绝不能丢掉一分钱,计算结果必须精确到最后一分钱。” Stroustrup 举例对比:在视频播放系统中,偶发性丢一帧画面无关紧要;在发动机电喷控制系统中,即使单次喷油量出现极其微小的偏差,发动机依然可以运转并在下一个冲程修正。但在金融领域,丢钱是违法的,系统必须每一次都完全正确,绝不能仅仅满足于统计意义上的“平均正确”。这种性能、可靠性与绝对正确性交织的严苛环境,为他设计未来 C++ 标准提供了极其宝贵的一线现实反馈。 ### [01:47:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6445s) 给年轻研究者的建议:先找真问题,切莫盲目追求改变世界 当被问及对有志于从事程序设计语言研究的研究生有什么建议时,Stroustrup 直言,许多年轻人带着某种执念而来——一心想要创造一门新语言、写一个全新的操作系统或打造一款全新的游戏,但他们最缺乏的恰恰是对“问题本质”的理解。 > “C++ 之所以成功,主要倒不在于我做出了一个多么优美的设计,而是我非常幸运地抓准了一个当时许多人即将面临的重大问题——那就是在面对更大的内存和更快的处理器时,如何应对日益膨胀的复杂度。” 他强调,解决复杂度不仅要靠抽象机制,更要受制于“性能”的严格约束,而这一点在当时几乎被所有人忽视。因此,他给后辈提出了一套循序渐进的研究路径: 1. **不要一上来就妄图拯救或改变世界**:深入理解真实场景中的问题集合,再去构思解决方案。 2. **警惕短视与纯粹功利**:如果仅仅为了满足下个季度的截止日期去写打补丁式的代码,或许能迅速升职为管理者,但从此再也做不出真正有价值的成果。 3. **从具体问题中提炼通用性**:利用大学学到的理论与工程知识,总结经验并进行概念抽象,探寻能够惠及更广泛人群、适应更大时间跨度的通用解决方案。理论的意义在于提供工具,但前提是必须先找到真正值得解决的问题与约束条件。 ### [01:50:25](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6625s) 计算机历史博物馆与技术史教育的缺失 谈及将早期 C++ 编译器 Cfront 的源代码、手册和历史照片捐赠给计算机历史博物馆(Computer History Museum)一事,Stroustrup 感谢了采访者 Paul McJones 的提议。借此机会,Stroustrup 对当代工程教育中“历史维度的缺失”表达了深切忧虑。 他指出,现在的年轻学生普遍处于一种“非历史性”(ahistorical)的状态:他们从未被系统地教授过历史,甚至认为历史毫无价值,误以为所有技术都是“昨天才刚刚被发明出来的”,整天追逐最新的短暂潮流。学校和媒体也在助长这种功利心态——只看重数理工程成绩,忽视高中的历史课程与大学的人文通识教育(Liberal Arts),媒体更是一味宣扬“哪种职业能在最短时间内赚最多钱”。 Stroustrup 严肃地指出:“靠这种方式取得世俗成功的人,往往不是非常好相处的人(not very nice people)。”他们把青春全部禁锢在狭窄的技能树里,排除了一切人文素养。他呼吁工科生应当多读通用历史,多倾听他人以提升沟通能力。同时,他也建议计算机历史博物馆不要只做冰冷的硬件陈列(不要把各个时期的机箱摆得像一排排洗衣机),而应着重阐释每项技术在当时被创造出来的“前因后果(why things were done)”,用鲜活的技术演化逻辑去启迪后人。 ### [01:53:45](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6825s) 计算机博物馆的展示困境:纯硬件陈列与软件上下文的缺失 Bjarne Stroustrup 直率地分享了他对计算机博物馆展览策划的看法与建议。他回忆自己漫步展厅时的感受:虽然看到某些特定机器时会短暂感到兴奋,心里会嘀咕“我当年给这台机子编过程序”、“那台机器可好玩了”,或者“天哪,当年我怎么也调不通它”;但这种纯粹出于个人怀旧的情感很快就会消退。他指出,对于普通大众来说,光秃秃的机器并不能激发他们的兴趣,因为冷冰冰的硬件根本没有传达出关键的信息:这台机器当年究竟是为什么而被制造出来的?它曾被用来解决哪些现实生活中的难题? 在 Stroustrup 看来,单纯展示硬件其实是相当乏味的。博物馆之所以往往偏好聚焦硬件,很大程度上是因为硬件“看得见、摸得着,敲上去咚咚作响,拍成照片也光鲜亮丽”。但追根究底,没有软件的计算机不过是一块废铁般的“船锚”。他强烈呼吁,博物馆应当将更多重心放在软件之上——这不仅仅指程序设计语言本身,更要展现那台计算机当年靠什么“谋生”(how it did for a living)、人们如何与它交互、它协助攻克了什么难题,以及除了裸机硬件之外工程师还借助了何种软件工具来达成目标。他半开玩笑地直言,自己实在不想再在展厅里看到又一台脱离了实际历史情境、看起来像洗碗机一样的硬件铁盒子了。 Stroustrup 进一步论述道,博物馆的核心使命是收藏文物,而在计算世界里,编译器、数据库和各类应用程序都应当属于至关重要的核心文物。现实中每一款硬件背后往往都对应着千千万万套软件;若要忠实映射计算世界的真实历史,馆藏中软件的分量理应远远多于硬件。然而他也坦承,展示软件是一项巨大的策展挑战,因为软件既不可见、不可触摸,也无法敲击。要解决这个难题,唯有将计算机放置在其具体的历史背景与应用场景中,讲述它所解决的问题。 对于硬件与软件在博物馆呈现上的错位,Stroustrup 一针见血地指出: > “A computer without software is sort of kind of a boat anchor right and so more emphasis on software not just languages but what did that computer do for a living how did people interact with that computer what kind of problems was it used to solve what kind of tools did people use in addition to the hardware to provide those solutions I think a greater emphasis on that would be helpful.” - **纯硬件展示的弊端**:外形类似洗碗机或铁盒,缺乏应用背景,公众无法得知其建造初衷与实际价值。 - **软件展品的独特性与挑战**:无法像硬件那样产生实体触感(“you can't see, you can't feel, you can't knock on it”),必须依托问题背景与系统工作流才能向观众具象化呈现。 ```mermaid flowchart TD accTitle: 软件与硬件在博物馆呈现中的价值关系 accDescr: 对比单纯陈列硬件与结合软件展示计算应用场景的两种博物馆呈现模式 subgraph Traditional["传统硬件陈列模式"] H1["裸机硬件 (像洗碗机一样的铁盒子)"] H2["视觉与触觉直观 (能看、能敲、拍照好看)"] H3["痛点:脱离上下文,宛如无用的船锚 (Boat Anchor)"] H1 --> H2 --> H3 end subgraph Ideal["软件与情境导向模式"] S1["软件文物 (编译器、数据库、应用系统)"] S2["历史情境 (面向的难题、人机交互、配套工具)"] S3["最终呈现:展现计算机如何谋生与改变世界"] S1 --> S2 --> S3 end ``` --- ### [01:56:01](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=6961s) 软件历史文物的抢救与 Alexander Stepanov 的推动 Paul McJones 随后回应了 Stroustrup 的建议,表示博物馆目前已经有了明显的进步。例如博物馆策划的“Revolution”(革命)常设展览,在交代历史背景方面就比早期的“可见库房”(visible storage area)要好得多。此外,博物馆正在积极筹备一个专门的大型软件展览,虽然目前仍需筹集部分资金,但该展项的构想正是把十余个经典应用软件与操作系统置于真实的历史情境中,向参观者直观展示“当年需要解决的到底是什么问题”。 在话题转向软件文物的收集时,Paul McJones 谦虚地补充说明,自己之所以投身于收集 C++ 及其他众多关键软件历史文物的行动中,真正的灵感来源其实是 Alexander Stepanov(STL 之父)。听到这个名字,Stroustrup 会心一笑,感叹道 Stepanov 确实是业界许多深具远见的精彩构想的源头。虽然 Stroustrup 此前并不知道是 Stepanov 在背后促动了 McJones,但他非常清楚正是 McJones 一遍又一遍的执着督促与追问,才让自己最终静下心把 C++ 早期的大量珍贵历史档案、源码和文献整理并交付给了博物馆保存,他对此表达了由衷的赞赏与感谢。 关于这层渊源,Stroustrup 笑着点评道: > “Alex is at the root of many interesting things. I didn't know he had prodded you in that direction, but I certainly know it was you who prodded me so that I delivered the stuff, right?” --- ### [01:57:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=7028s) 三代院士荣衔传承与对口述历史资料的期许 在采访行将结束之际,现场摄制组的一位幕后工作人员通过耳机向 Paul McJones 示意并打断了流程,提出希望 Stroustrup 能在镜头前分享一段关于“学术世系传承”的感想——在计算机历史博物馆院士(Fellow)的名单上,Maurice Wilkes、David Wheeler 与 Bjarne Stroustrup 师生三代人竟然全部名列其中。提问者请 Stroustrup 谈谈这种跨越数十年、犹如学术家族血脉延续般的殊荣带给他怎样的感受。 Stroustrup 深情地回顾了自己对历史的态度。他重申历史绝非尘封僵死的陈年旧账,而是构成当今世界认知模式的基石。也正因如此,多年来他无论是亲自实地参观还是浏览官方网站,都对计算机历史博物馆及其院士名录保持着长期的关注。能够入选院士、获得同侪与历史的认可,让他感到无比荣幸与激动。他特地指出,计算机科学仍然是一个非常年轻的学科,而自己很可能是该博物馆有史以来第一位“第三代院士”(third generation Fellow)——他的博士生导师 David Wheeler 是院士,而 Wheeler 的导师 Maurice Wilkes 同样是院士。他真诚地希望,随着计算领域的不断成熟,未来能够涌现出更多薪火相传的三代乃至多代院士世系。 谈及博物馆网站上的院士档案,Stroustrup 坦言自己其实阅读了大量院士的传略短篇。然而他在阅读过程中经常觉得意犹未尽,很想探寻文字背后更丰满的细节。他提到自己平时工作繁忙、容易疲惫,看视频录像往往觉得进度太慢,因此极度渴望在传记页面能直接链接完整的采访文字记录(transcripts)。对于他相识的老一辈先驱,简短传记足以勾起往昔回忆;但对于不甚了解的人物,详尽的采访文字记录以及现场口述录像,才能让那些行色匆匆的后人真正触碰到有血有肉的历史。 在被提问者要求重新凝练地给出结语时,Stroustrup 郑重地面向镜头,为整场访谈画上了句号: > “I don't think history is something dead; it's part of our world, it's part of the way we understand the world. And so for that reason I have known about the Computer History Museum and its fellows for many years because it's one of the things I've been looking at. I've been there physically, I've been there on the web, and I find it's really cool. I mean, not only being a fellow there, so having been part of all of this and being recognized to be part of all of this is very, very exciting for me and I'm very honored. But I'm probably the first third-generation fellow—that is, my advisor was a fellow, and his advisor was a fellow.” - **学术世系脉络**:Maurice Wilkes(EDSAC 奠基人之一,院士)$\rightarrow$ David Wheeler(子程序与 Wheeler 变换发明者,院士)$\rightarrow$ Bjarne Stroustrup(C++ 之父,院士)。 - **口述历史形式的实用价值**:音视频忠实记录神态与语气,而完整的文本整理(Transcript)则极大方便了快节奏学者的高效检索与精读。 - **结语表态**:Stroustrup 在访谈落幕之际再次向馆方郑重致谢:“Of course, if I didn't say it already, I am very honored and this is very important to me. Thank you.” ## Notable quotes > [28:16](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1696s) 如果让人在编写‘好代码’还是‘快代码’之间做选择,那一定是哪里出了问题;好代码本身就应该跑得快。 — Bjarne Stroustrup > [01:02:27](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=3747s) 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 > [30:38](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1838s) 如果一个老师的前一份工作就是当学生,那从根本上就是有问题的,这近乎一种近亲繁殖;里面必须得有真实世界的经验。 — Bjarne Stroustrup > [19:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=1148s) 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. — Bjarne Stroustrup > [01:30:42](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=5442s) 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 > [01:57:08](https://www.youtube.com/watch?v=ZO0PXYMVGSU&t=7028s) I don't think history is something dead; it's part of our world, it's part of the way we understand the world. — Bjarne Stroustrup ## Mentioned Bjarne Stroustrup, Paul McJones, John Plute, David Gries, Martin Richards, Alexander Stepanov, Maurice Wilkes, Roger Needham, David Wheeler, Kristen Nygaard, Ole-Johan Dahl, Sandy Fraser, Steve Bourne, Ken Thompson, Dennis Ritchie, Brian Kernighan, Doug McIlroy, Greg Chesson, Dmitry Lenkov, Andrew Sutton, John Backus, Andrew Koenig, Beman Dawes, Gabriel Dos Reis, Howard Hinnant, C++, C with Classes, BCPL, Simula, SNOBOL, Algol, Algol 68, Algol 68C, COBOL, Ada, Lisp, Java, Cfront, STL, Concepts, CAP 计算机, EDSAC 2, PDP-11, PDP-11/70, VAX, Cray 超级计算机, Univac, GCC, 奥胡斯大学, 剑桥大学, 贝尔实验室, 宝来公司, 德克萨斯农工大学, 哥伦比亚大学, 摩根士丹利, 计算机历史博物馆, 惠普, IBM, 微软, Borland, 德州仪器, Google, Facebook, WorldCom, 朗讯科技, AT&T ## 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)

Source quotes

[28:16] Bjarne Stroustrup: 如果让人在编写‘好代码’还是‘快代码’之间做选择,那一定是哪里出了问题;好代码本身就应该跑得快。 [62:27] Bjarne Stroustrup: 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. [30:38] Bjarne Stroustrup: 如果一个老师的前一份工作就是当学生,那从根本上就是有问题的,这近乎一种近亲繁殖;里面必须得有真实世界的经验。 [19:08] Bjarne Stroustrup: 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. [90:42] Bjarne Stroustrup: 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. [117:08] Bjarne Stroustrup: I don't think history is something dead; it's part of our world, it's part of the way we understand the world.

Source quotes

[26:32] Bjarne Stroustrup: If you give people the choice of writing good code or fast code, there's something wrong; good code should be fast. [90:42] 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. [62:29] Bjarne Stroustrup: 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. [24:08] David Wheeler: If I have to tell you what to do, it's a master's. [107:25] Bjarne Stroustrup: 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. [110:25] Bjarne Stroustrup: 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.

Original transcript

[0:05] today it's February 5th 2015 I'm Paul MC [0:08] Jones in [0:10] California and intervie I'm b b St in [0:15] New York [0:16] City and behind the camera is John plute [0:20] how are you bana uh fine thanks uh [0:23] thanks for taking the the effort here [0:25] and um it's amazing we can sit chatting [0:28] like this yeah several thousand miles [0:31] apart using probably some C++ technology [0:34] under behind the scenes definitely and I [0:37] was thinking that when I started on this [0:39] we couldn't have done this right right [0:43] um I thought it would be good to sort of [0:45] start at the beginning if you could tell [0:46] us a little bit about your parents where [0:48] you grew up um okay yeah I was uh born [0:53] in orus and Denmark and I lived there [0:56] for for the first sort of 23 years of my [0:59] life [1:01] um lived in an apartment in a in a [1:04] working class District my father was a [1:07] uh somebody who laid down floors and [1:10] later after an illness he was a hospital [1:12] Porter uh my mother was a secretary um [1:16] so she has had a middle school education [1:18] which was the most anybody in the family [1:21] had had by then um so I went to the [1:24] local school which wasn't a great school [1:28] actually I've seen the statistic it was [1:30] the worst school in [1:31] town but uh somehow I managed to get [1:34] into high school and uh from there to to [1:39] the local University and uh that happens [1:42] to be a good one University of or who [1:44] sort of appears on the top 100 [1:46] universities in the world ever so [1:49] frequently not every year but lots of [1:53] years and [1:56] um I actually had a a pretty nice time [2:00] in all who's growing up and a very [2:03] stable situation we we lived in in one [2:06] place and known as the [2:09] yard some of those standard uh [2:12] rectangular uh apartment buildings that [2:15] you got in uh in Europe with a with a [2:18] yard in the Middle with some grass and [2:20] such very nice very nice place um I've [2:25] traveled far and lived in other places [2:27] but it's not because I disliked where I [2:29] came from [2:30] uh still got family in [2:33] Denmark uh I I studied mathematics with [2:38] computer science in in the [2:42] university and uh that's actually [2:46] curious because like like most gr uh [2:49] most high school students I had a clue [2:51] what I wanted to do so I was looking [2:54] around I wanted to be a historian an [2:57] architect a sociologist [3:00] um an [3:02] engineer and [3:04] um decided I didn't know so I just got [3:08] grades that are sufficient to get into [3:10] anywhere and so I was thinking of going [3:13] to the engineering school in Engineering [3:15] University in Copenhagen but decided [3:18] that the the cost were too high uh in [3:21] Denmark of course you have free tuition [3:23] so that's not a problem but uh coming [3:26] from a family with few resources the [3:29] idea of taking on debt to for a sixe [3:35] course living in a in a big bad City [3:38] meaning Copenhagen um was just too much [3:42] so I decided I'll do something local and [3:44] since we didn't have an engineering [3:46] school and since I'd been reasonably [3:48] good at math in high school I I signed [3:51] up for math but I was convinced that I [3:55] needed to do some practical math I I [3:58] wanted to to actually practice something [4:01] to do something I had an absolute dread [4:03] of becoming a a teacher because I [4:06] thought that was what happens to Bright [4:08] kids who don't know what they're doing [4:11] uh have no uh Role Models have no ideas [4:13] what they're doing so I I didn't want to [4:15] be a teacher so I needed to find some [4:17] kind of Applied math something I could [4:20] really do and so I signed up for [4:22] computer science uh the word computer is [4:26] not in the title of that in Danish so so [4:30] I was quite um capable of [4:32] misunderstanding it and thinking it was [4:35] math and in my second year I realized [4:38] that I've been wrong and uh programming [4:42] data structures machine architectures is [4:45] not [4:46] math um at least not at that level and [4:51] uh this was pretty good because it turns [4:53] out like most other people I wasn't [4:55] quite as good as math as I thought I was [4:59] uh on the the other hand programming was [5:01] was really fun and learning about [5:04] machines and computer science in general [5:06] was was really fun and haven't looked [5:09] back [5:11] since well that's pretty interesting [5:13] were there any sort of mentors or [5:15] anybody who had influenced you down this [5:17] path up to this point not not not in any [5:20] sort of real sense um I've thought about [5:23] this problem before and I I did have a [5:25] math teacher for actually 9 years [5:27] running who was a very good math teacher [5:31] so that's probably why I didn't didn't [5:33] flunk math and I actually was reasonably [5:37] good at it um but he himself had been [5:41] trained as a Danish teacher and had [5:43] never actually been to a high school he' [5:46] been from middle school to a um a [5:49] teacher's training college and and and [5:51] he couldn't guide me beyond that and uh [5:55] nobody in my family could so uh once I [5:58] was in high school was sort of on my own [6:01] and uh with a bit of luck uh I ended up [6:06] uh in that uh computer science program [6:09] and got my masters in mathematics uh [6:13] with computer science um never regretted [6:16] the um amount of pure math I ended up [6:20] doing um you never know what comes in [6:23] handy in your career and if you told me [6:27] say 20 years ago that algebra turned out [6:30] to be a really useful thing I would [6:33] probably have argued strenuously against [6:37] it but with type Theory and Alex's work [6:41] on the STL and that kind of stuff the [6:44] kind of thinking I learned in algebra [6:47] has actually been been very useful over [6:49] the last couple of [6:50] decades after being not useful at all [6:53] for a couple of decades right but it was [6:56] sort of Laten there it was there [7:00] Pard it was there right do you remember [7:03] you know particular textbooks that that [7:07] seemed you know important to you at the [7:11] time what pops into my head is a book on [7:14] the opening game of chess um I I don't [7:18] think that counts no I I don't think oh [7:21] gree's book on how to write a [7:24] compiler uh very practical the only [7:27] problem was it was mostly grammar and [7:30] when it came to real um real design it [7:33] was the the least important part of the [7:36] compiler but it got me started and [7:38] interested in in languages and and how [7:41] to implement [7:43] languages um I was never a languages guy [7:47] um I was interested in operating systems [7:50] I dealt with microprogramming a lot uh [7:53] machine [7:55] architecture uh one of my early projects [7:57] in orus was to [8:00] uh design [8:02] a [8:04] um a virtual machine um in hardware for [8:10] for bcpl I needed to run bcpl or rather [8:13] I wanted to run p bcpl and I looked at o [8:17] code which is basically a simply code [8:19] for U bcpl and thought well why don't I [8:23] just Implement that in Hardware so I [8:25] wrote a little um piece of micr code [8:29] that implemented in instruction for [8:31] instruction I made a little [8:33] representation of O code with compressed [8:37] um data structures so that you could [8:39] have a compact program and now I could [8:41] run [8:42] bcpl so this is not quite the [8:45] traditional way of implementing a [8:47] programming language but Martin Richards [8:49] had kindly provided this intermediate [8:51] step in the compiler which I could [8:54] hijack and uh I I [8:58] learned uh [9:00] probably a dozen maybe 20 languages [9:03] before I left orus uh I got a masters [9:06] that's what you got in those days there [9:08] was no [9:09] Bachelors uh so I was not a languages [9:12] guy but I did know say 20 [9:15] languages so that probably included the [9:18] sort of the applied on like for and so [9:21] on we have hold on for one second I'm [9:22] Mak a slide [9:25] adjustment can you see him okay Paul yes [9:28] that's everything's [9:37] good checking [9:42] Focus okay go ahead I was just curious [9:46] Having learned that many different [9:48] languages did that include sort of [9:50] practical ones and also some of the [9:52] research [9:53] languages um the distinction between [9:56] practical and research languages was [9:58] never explained to me and I I don't [10:00] think I appreciated it I [10:05] was the first course I think had three [10:08] or four [10:09] languages um I remember writing some [10:12] cobal and hating it uh writing some um [10:17] oh well lots of languages and some of [10:20] them I liked some of them I didn't like [10:21] when I say 20 languages it doesn't mean [10:23] I have completed a major project in each [10:26] but it means you've written a couple of [10:28] programs you appreciate what it can do [10:30] and what it cannot do [10:33] um [10:35] uh what is that the string manipulation [10:39] pattern matching language from the [10:41] 60s snowball snowball that's right I [10:45] remember uh finding snowball really [10:48] interesting and useful and [10:51] one what I would call formative [10:53] experience was realizing that I had [10:55] written an alcohol program in snowbo and [10:59] was a really stupid program it was [11:02] complicated it was difficult to get to [11:04] run it ran slowly and it was not how any [11:08] sane snowball programmer would write it [11:11] and so you had to go back and actually [11:13] learn the idioms you can't [11:15] just uh take a language and start [11:18] writing it as if it was your previous [11:20] language which is what we essentially [11:22] all do uh and then we realize we're [11:24] doing it again and and correct but but [11:27] that I actually learned I think in the [11:29] first half year [11:30] programming and so I picked up quite a [11:33] few programming [11:35] languages um I mean you can pick on in [11:39] the old days when languages were simpler [11:42] uh programming environments were less [11:44] complicated libraries was less extensive [11:47] you could actually find yourself Sitting [11:49] Waiting for a couple of hours and then [11:52] uh read the manual and go back and write [11:55] some programs when when when you got out [11:57] of the waiting room or wherever it was [11:59] you were stuck and then you could play [12:01] with it for a couple of weeks or a [12:02] couple of months do something it was [12:04] suitable for and get on with something [12:05] else but languages were never my main [12:09] concern uh languages was a tool for [12:12] doing something like for getting [12:14] Hardware to to do the right thing or or [12:17] getting Hardware to have the right [12:18] instructions set or something like that [12:22] right right in Steve laur's book goto he [12:26] mentioned that you were a contract [12:28] programmer at that time did that have a [12:32] a strong influence on you uh it did um [12:36] it wasn't meant to it was just meant to [12:38] give me some cash so that I could uh [12:40] avoid taking on debt and and live [12:44] frugally but reasonably uh up to my uh [12:47] master's degree um some of the [12:50] microprogramming again was was done on [12:52] contract uh from the University but this [12:56] job from Burrows was actually [12:58] interesting [12:59] because there I got to see the process [13:04] from uh negotiating with the client what [13:08] should be done to deciding what could be [13:12] done out of what the salesman wanted and [13:15] what the uh client wanted and then [13:19] building a demo and I had a very uh [13:23] simple business model if I could build a [13:25] demo that the uh client was willing to [13:29] pay for then I got the job of [13:32] implementing the system now this from [13:36] the coroporation point of view safe [13:39] because if I sell a demo I cannot make [13:42] real um I I wouldn't be working for them [13:46] anymore uh on the other hand it is very [13:49] much in their interest and the client's [13:51] interest and my interest to get the [13:53] system as nice as possible and um I was [13:57] out talking to the clients I talking to [14:01] um them when they were installing it [14:04] seeing how it could stall see how to [14:07] train the people who's actually going to [14:09] use it um sit around chatting with the [14:12] client's children realizing that if I [14:15] screw up these children get hurt um so [14:19] it [14:20] it as I thought about it as I went along [14:24] I I did this many times see between six [14:29] or a dozen times over a few years and [14:32] then I thought about it later and I'd [14:35] actually seen the whole process of [14:38] software development from trying to [14:40] figure out what system might get built [14:42] to uh doing the the the clean up once [14:45] something broke and everything in [14:48] between and I I have a fairly strong um [14:54] opinion about systems being appropriate [14:57] and reliable and affordable which I [15:00] think partly came out of that it is not [15:03] something that is easily installed in a [15:07] in a classroom [15:08] setting right you kind of reinforced [15:11] those feelings you had had initially [15:12] that you wanted to go into a an applied [15:15] field but it really made it concrete [15:17] doing something practical and and and [15:19] sitting there in the sofa trying to [15:21] explain to a couple of kids what I'm [15:24] doing for their dad is is an interesting [15:27] exercise [15:29] yeah yeah um okay so at that point you [15:32] were you could have gone probably easily [15:37] started a you know some sort of a [15:38] software development career but instead [15:40] apparently you decided to go to graduate [15:42] school what led to [15:44] that [15:47] um yeah I actually got to England before [15:51] I got my masters because I was working [15:54] with some microprogram on hardware and [15:56] they had some really cool stuff in [15:58] England so I went over there for a while [16:01] and while over there I got the idea [16:05] that that actually was interesting and I [16:07] could do something more and uh getting a [16:12] PhD was my solution to the problem of [16:14] how to uh spend more time in England and [16:18] uh play with some more interesting [16:21] hardware and so I applied [16:25] to sort of the English universities i' [16:28] had heard of [16:29] off and actually managed to get accepted [16:33] in most of them and uh I was almost [16:37] going to Newcastle but my wife my then [16:40] girlfriend explained to me that if you [16:43] have an offer from Cambridge you take it [16:46] this is [16:47] non-negotiable uh if if you in England [16:51] and I I I haven't uh regretted that uh [16:55] it turned out to be right [16:57] it's probably still for practical [16:59] computer science the best place in [17:02] Europe yeah it certainly seems to have [17:05] turned out well for you and and your [17:07] adviser was was David wheeler who and [17:10] his adviser was Morris wils and these [17:12] were the people who got the first [17:14] practical computer running so it really [17:16] connected you to the to the origins and [17:19] it turned out that works was the guy [17:22] that uh invented [17:23] microprogramming I mean would you [17:25] believe it I sat in an interview with [17:28] ranum [17:29] and uh Morris wils at Cambridge and I [17:33] somehow hadn't dawned on me that wils [17:36] was the one that invented [17:38] microprogramming and so I was explaining [17:41] all the cool stuff about that uh without [17:43] knowing who I was doing it to but I must [17:46] have done a good job because I got [17:48] accepted but that was the toughest [17:50] interview I've ever sat through there [17:52] was these two guys I mean WS got the [17:55] second touring award he's no slouch and [17:59] a computer Museum history fellow by the [18:02] way I'm a third generation here because [18:05] later W wheeler got it and now I'm [18:07] getting it um and there was uh Roger [18:11] nidam who later became vice Chancellor [18:14] of the university and started the uh [18:16] Microsoft in Europe uh there and so they [18:20] were taking turns one of them ask a [18:23] question the other one listens and when [18:25] we run out of of that question the other [18:28] guy asked the question and I don't think [18:31] I've had as hard a 3/4 of an hour ever [18:35] as that [18:36] interview um halfway through they [18:39] explained to me that I was all wrong and [18:41] um could I was there anything else I [18:44] could do so I had to change horses in [18:48] the middle of that interview but that [18:50] that interesting I remember it fairly [18:53] well yeah that would that sounds pretty [18:57] pretty tense um [18:59] but then you probably got to know them a [19:01] lot better you know you have sort of [19:03] what you say two years later how did you [19:06] how did you look at them yeah [19:08] um [19:11] the sort of teaching style at Cambridge [19:14] was somewhat different than most people [19:17] uh think um I had a masters when I came [19:21] in so I didn't actually need to take any [19:23] courses I took courses when I needed [19:27] them and um [19:29] David Wheeler's tuition style was was [19:32] very simple um you came to him when you [19:36] uh thought it was a good idea and I [19:39] quickly found that turning up about once [19:41] a um once a week was a good frequency [19:45] and you come in you're a new gratitude [19:47] and you're full of great ideas right you [19:50] come in and you're explaining these [19:51] great ideas to to David wheeler and he [19:55] sits there and sits [19:57] thoughtfully yeah yeah yeah B that's not [20:01] a bad idea you know we almost did that [20:06] for theack [20:08] 2 which was the most dreaded words [20:11] because that means that in about [20:13] 56 uh about the time I entered primary [20:16] schools they've thought of it and then [20:19] he could go on for about an hour [20:21] explaining what they did instead and why [20:23] they did it instead and what the [20:25] tradeoffs were and uh why what they were [20:29] going to do instead didn't quite work [20:31] and how uh they they fixed it again and [20:34] so [20:36] basically the the tuition style was to [20:38] listen what I said then shoot it full of [20:41] holes ever so politely and then just [20:45] giving an uppr two um lecture for about [20:49] an hour uh on topics related to it and [20:53] then I was going away feeling about this [20:55] big and U then you come back next week [20:58] for the [20:59] same um I also talked a lot with uh [21:03] Roger [21:04] Needum [21:06] uh [21:08] who was one of the senior lecturers at [21:11] uh at uh Cambridge um wheeler and nidam [21:16] both got promoted Professor when WS [21:20] retired uh to go to the US to become a [21:22] consultant for a decade or so but anyway [21:26] um he sort of was was more sort of [21:30] chummy with the students we used to go [21:33] for to lunch with a group of students [21:36] where he amazingly was able to drink two [21:38] pints of Abbot which none of us would [21:41] have been able to do and still work in [21:42] the [21:43] afternoon and uh his style was different [21:46] you you want to talk to him talk about [21:48] something specific and he walks up and [21:51] down [21:53] talking and uh this is more two-way than [21:56] it was with with um wheeler but he walks [22:00] up and down so I develop a technique [22:03] standing roughly on a corner and seeing [22:05] him walk like that because otherwise I [22:09] would get really tired just to keep up [22:11] with him and um he he he had lots and [22:16] lots of good and interesting [22:18] ideas but most of what I learned and [22:22] came Bridge was was from talking to [22:24] these two guys that way I didn't see [22:26] much to Morris WLS [22:29] uh while I was at uh Cambridge he was [22:32] sort of the remote the professor sitting [22:35] in his office you had to book a time [22:37] with the secretary and uh if if you were [22:41] a lowly grad student he probably was [22:43] busy most of the time um I I got to know [22:46] him reasonably well uh later after I [22:49] graduated I hosted him at Bell labs and [22:53] things like that met him at conferences [22:55] really really great guy um he he managed [22:59] to outlive his own autobiography by [23:01] about 12 [23:03] years it's um but one of the things that [23:08] Cambridge could do and later bill laabs [23:11] can do is somehow raise people's [23:16] expectations of [23:17] themselves uh raise the level that is [23:20] considered [23:21] acceptable you walk in and you see what [23:24] people are doing you see how people are [23:25] doing you see how apparently easily they [23:29] do it and you see how nice they are [23:31] while doing it and you realize I better [23:33] sharpen up my game this is this is [23:36] something where you you have [23:39] to you just have to get better because [23:42] the what is acceptable has changed and [23:45] some organizations can do that and well [23:49] most can't to that extent and I've just [23:51] been very very lucky to be in a couple [23:53] of places that actually can uh increase [23:57] your uh level of ambition in some sense [24:00] level of what is a good [24:04] standard that's very interesting so so [24:08] this is the environment where you pick a [24:10] research topic and which is really [24:13] distributed computing it's not [24:14] programming languages but but you have [24:16] an experience carrying out that research [24:19] that seems to kind of plant a seed for [24:21] you yes [24:22] um one of the first things that happened [24:25] to me probably the first day at [24:29] Cambridge I was sitting down uh in [24:32] Wheeler's office and he asked me you [24:36] know what's the difference between a [24:37] masters and a [24:41] PhD um I said no says if I have to tell [24:45] you what to do it's a [24:47] master's in other words it was my job to [24:50] figure out what to do that that was the [24:53] first and most important uh job of a PhD [24:56] and it took me a year [24:59] uh the next thing was that he had [25:01] forgotten that I had a masters so uh he [25:04] explained that the the the the Fate [25:07] worth and death was to get a masters [25:09] from Cambridge and I was able to sit [25:11] there waiting till it finished and says [25:14] well I don't need a masters I've got one [25:17] uh so that that was good but uh yeah I [25:21] had to find the area um the distributed [25:24] systems came because of my work with [25:28] with machine architectures and [25:29] microprogramming I was trying to develop [25:32] a high level [25:33] architecture uh architectural support in [25:36] in uh [25:38] for um [25:40] basically uh modularity for for for [25:44] having Hardware [25:46] protected entities talk to each other in [25:49] Cambridge had the cap machine designed [25:52] by uh works and Wheeler need them which [25:54] had Hardware um Hardware protection [25:59] capabilities and I wanted to extend this [26:03] so that it could be on several processes [26:07] in a single machine [26:10] and even better if I could on several [26:13] computers or a [26:15] network and U the idea was to build [26:19] Hardware that could do that [26:21] efficiently and since I couldn't afford [26:23] a multicore I mean there was hardly any [26:27] of them on Earth at the time time and I [26:29] certainly couldn't afford a network uh [26:32] they built the first in uh in Cambridge [26:35] while I was there but when I started [26:37] there wasn't such a thing um so I [26:40] simulated it [26:42] instead and uh so I was still focused on [26:45] the systems issues on the hardware [26:47] issues system software [26:49] issues and uh I got into simulation I [26:53] picked up the knowledge I had of simula [26:57] I had learned simula in orus actually [27:00] mostly from talking to CH n uh many many [27:04] discussions with ch [27:06] n uh you don't actually have a [27:09] discussion with Christ n you say [27:12] something and he talks to you for a [27:13] while but great guy and I learned a lot [27:17] so I picked up simula and I wrote a [27:20] simulator and I brought the university [27:22] Mainframe to its [27:24] knees um before I could get any decent [27:26] data out of it the resource demands of [27:31] that simulator was just too much for for [27:34] the [27:35] Mainframe and um later I came to uh [27:40] realize that this is typical for [27:42] simulations you just run a simulation [27:46] with more data or with more [27:49] entities or for a longer time till you [27:52] run out of memory and [27:55] CPU uh available so so um this this is [28:00] fine but when you do this as a grad [28:03] student uh you only do it about once [28:06] before you're kicked off the machine [28:08] because the astrophysicists and the [28:10] chemists have much better uh funding [28:13] financing and political power so um I [28:16] had to do something else and and what I [28:19] did was I moved to actually the cap [28:22] which was this capability machine very [28:25] unusual machine strange architecture [28:29] beautiful um you could program it in [28:32] languages nobody's ever heard of uh and [28:37] uh that kept the chemists and the [28:39] astrophysicists and most of the computer [28:42] scientists [28:44] away but um I had a choice [28:47] between um algar [28:49] 68c which is alar 68 without garbage [28:52] collection and Bey pure and uh I I did a [28:57] few experiments I I picked up both of [28:59] those languages along the way and I was [29:02] actually pretty good at bcpl at the time [29:05] having implemented in [29:07] Hardware uh so I I rewrote my simulator [29:11] from simula into [29:13] bcpl and all the high level structure [29:16] disappeared all the nice organization [29:18] that had helped me debug and helped me [29:20] design [29:21] disappeared but the resulting [29:26] bcpl once I had debug it and lost half [29:29] of my hair in the process ran really [29:31] fast it could use all the resources of [29:34] the machine it could communicate with [29:36] anything on the machine and I got my [29:39] data and I got my PhD and I was I came [29:43] away with the opinion that I would never [29:46] again want [29:48] to attack a problem with tools that was [29:52] fundamentally [29:53] unsuitable and in particular I don't [29:57] want to make the choice choice between [29:59] elegant uh which simular was for this [30:02] problem and efficient which uh bcpl was [30:06] I want both and that has been sort of [30:09] one of my my my guiding lights uh if you [30:12] if if you if you give people the choice [30:15] of writing good code or fast code [30:18] there's something wrong good code should [30:19] be [30:20] fast and [30:23] um I I came away from Cambridge with [30:26] with that experience [30:28] uh still thinking I was going to build [30:30] operating systems and design [30:34] computers so after graduating did you [30:38] look at a lot of places you you weren't [30:40] interested in teaching is that still was [30:42] that [30:43] true if anything I was more convinced I [30:46] didn't want to teach uh I saw it as a as [30:49] a trap for bright kids and uh also I had [30:53] developed this idea that there's [30:55] something fundamentally wrong if the [30:57] teacher previous job is [30:59] student it's it's incestous uh there has [31:04] to be some real world in there somewhere [31:06] and often there isn't for teachers and [31:08] professors and that weakens what is [31:11] being taught and it weakens The [31:14] credibility of the teacher so the [31:16] effectiveness of transmission of data is [31:18] also uh worse so no I really didn't want [31:22] to do that I looked at at jobs in [31:26] Denmark um Denmark is one of the nicest [31:29] places on Earth and uh if I could have [31:32] found a good job there I would have [31:34] would have gone back [31:37] but I noticed that I had made some kind [31:39] of fundamental mistake because at the [31:42] time in Denmark the opinion was that if [31:46] it was right and good it was being done [31:48] in Denmark and since what I was doing [31:50] wasn't done it must be wrong [31:53] somehow uh furthermore for University [31:56] jobs theob jobs went to people who were [31:59] sitting around doing the the usual thing [32:02] for a couple of years till they could [32:03] get a job practicing teaching um doing [32:07] fashionable stuff and what I was doing [32:10] was not fashionable in Denmark and I got [32:14] an offer to write some cobal somewhere [32:18] that could have been a non-career very [32:20] easily didn't attract me um got an offer [32:24] to go and do something for for some [32:28] branch of the government which seems to [32:30] be counting submarines in the sun [32:32] outside Copenhagen uh didn't didn't [32:35] sound attractive at [32:37] all and um [32:40] then there was a connection between uh [32:43] the lab at Bill Labs uh and the Lab in [32:47] Cambridge uh and I uh somebody had been [32:51] around and in the eagle where you you [32:54] went for a pint [32:56] after uh a day work uh somebody either [33:00] Steve Bourne or Sandy Fraser said you [33:04] know if you need a job give us a [33:06] call and they worked in the computer [33:08] science research center at Bill Labs so [33:11] I [33:12] did and they said yeah you can come [33:16] around um we can't promise to pay your [33:19] fair but come around give a talk let's [33:23] talk so I uh flew over to the states [33:27] also arranged a couple of other [33:29] interviews uh but I came there and I was [33:32] met by Sandy Fraser uh said sit down I [33:36] said what do you mean said sit down so I [33:38] sat down and says you come at a bad time [33:40] we don't have any [33:42] jobs this is not how you want a job [33:45] interview to start after you just [33:47] crossed the Atlantic you're seriously [33:50] jetlag and your bank account is is [33:52] rather low um anyway so uh we didn't go [33:57] to the computer science research center [33:59] we went to uh one of the uh more [34:02] development oriented places and I gave [34:04] my talk and must have been a good talk [34:08] because they changed their minds and I [34:09] got uh put straight back on the car and [34:12] um did a full interview in the research [34:14] center [34:15] instead and a week later I got an offer [34:19] uh so after that I worked worked there [34:22] for for 16 years um as long as h&c still [34:27] had bill apps [34:29] uh right and and is it is it fair to say [34:34] that you started off doing work somewhat [34:36] similar to your actual PhD distributed [34:38] systems work oh yes and then that that [34:41] led to some some new things yes I was I [34:45] was still I thought now I'm in a [34:48] industrial research lab we have many [34:51] more people we have many more resources [34:54] now I can actually build the system I [34:56] was uh [34:58] was was thinking [34:59] about and since uh we had Unix and that [35:03] was in the early days all of Unix was [35:06] there Unix was there it was a reasonable [35:09] size uh and there's people who knew [35:12] everything about it like can Thompson [35:14] and um several others uh Dennis Richie [35:19] was there to to show how to use C Brian [35:22] Kernan uh doc [35:24] meloy [35:26] um uh [35:28] Greg chessen lots of good people so I [35:32] decided I was going to take and and [35:34] build a system based on Unix by taking [35:39] parts of the software and run them in [35:41] different sort of units modules [35:45] parts and [35:47] these let's call them modules should be [35:51] able to [35:52] run either on a Shar program computer or [35:55] over a network we could afford a sheared [35:59] uh um she a multiprocessor didn't have [36:03] one yet but we could in principle and uh [36:06] soon we're going to get a network we're [36:08] all sharing a PDP 1170 at the time but [36:11] there was more of these and it was [36:13] obvious that soon it'll be become [36:15] feasible so I set off trying to figure [36:18] out how to separate the various Services [36:22] of the kernel into separate modules and [36:26] to think about how you users could talk [36:30] to each other through this kind of [36:33] stuff and after a while I don't quite [36:36] remember how long probably a couple of [36:38] months I realized I was making the [36:40] mistake that I had been very determined [36:43] not to make [36:45] because C which was the language there [36:49] didn't have the facilities for saying [36:52] which parts are separate and didn't have [36:55] the ability to to say [36:58] what is shared and what isn't they all [37:00] Poke into memory and [37:02] such um and furthermore it's so low [37:06] level that it uh it's really hard to [37:10] work with at that conceptual [37:12] level uh so I looked out for something [37:15] better I knew that to build the kind of [37:18] distributed system I wanted I needed a [37:21] language that can deal with Hardware do [37:23] it well do it efficiently do it directly [37:27] see was a good example of that I might [37:30] have chosen uh alol 68 if that has been [37:33] available but I soon realized that [37:36] nobody was using that it might be [37:38] elegant it might be beautiful but this [37:40] is not what what there is and I have [37:43] Dennis Richie down the corridor and [37:45] Brian keryan so if I really want to know [37:48] how to do it for real in see I know [37:51] where to [37:52] go um but it couldn't do the high levels [37:55] didn't have the notion of a module or [37:57] entity well later we called them objects [38:00] right and I knew simula I knew simula [38:04] quite well I had used it I had been [38:07] taught it by uh by K nugar which is the [38:10] ultimate master of this game he uh [38:13] invented objectoriented programming he [38:15] invented inheritance all of this kind of [38:18] stuff so I decided there was languages [38:21] that could do that simula was probably [38:23] the best and there was languages that [38:26] could do the lowlevel stuff [38:28] and C was obviously among the best and [38:32] so I I I wanted to put them together and [38:36] you you couldn't put the lowlevel access [38:38] into simula that was just too [38:40] complicated and the compiler was too [38:42] expensive and too hard to port and too [38:45] hard to Target Hardware so I put the [38:47] abstraction mechanisms into C and and [38:51] that's the fundamental idea of uh what [38:54] was then C with classes and now C++ [38:57] there's these two parts to it the [39:00] ability to manipulate Hardware directly [39:03] and the ability to abstract from it so [39:05] that you don't have to work close to the [39:07] hardware all the [39:10] time it seems very simple now but but [39:13] yes it was a it was a really good idea [39:16] and you were so it was a tool for your [39:18] own project did did but but you sort of [39:22] talked about other people looked over [39:24] your shoulder so to speak um I talked to [39:27] a lot of people and I listened I think [39:31] reasonably well and so I my my my sort [39:38] of detailed ideas not the fundamental [39:41] but the details ideas were sort of [39:43] wrong and um I I learned from [39:48] people what they were trying to do how [39:50] they would like to do it and a lot of [39:53] stuff came into C++ from from those [39:56] applications uh um thinking back there [39:59] was a couple of decisions I made very [40:01] early on that was was really important I [40:05] put in what is now known as function [40:07] prototypes because I couldn't live [40:09] without uh the ability to have a proper [40:11] interface to check your function [40:13] arguments to uh get conversions the idea [40:17] of square root of two not being a valid [40:19] program was just no that that that can't [40:23] happen um I was uh complaining a bit [40:27] about that about C and Sandy phrases is [40:30] why don't you just fix it so I did um [40:33] the other thing from my notes my very [40:36] first [40:37] notes [40:39] um was that you needed a Constructor to [40:44] construct an object to acquire the [40:47] resources necessary to function to [40:49] establish an invariant to speak modern [40:53] and uh a Destructor to to clean up the [40:56] mess when you're finished [40:58] and this is very very early it's the [41:00] same kind of vintage as the function [41:03] declarations and there was one more [41:06] thing that came in very early it was [41:08] very easy in the context of C but it is [41:12] where C++ breaks with many other [41:14] languages uh I really didn't want to [41:16] have a distinction between the [41:18] userdefined types that are created with [41:21] new and live on the free store and the [41:24] building types that you just declare and [41:27] use and don't live on the free store so [41:32] you had in simulate the distinction [41:34] between what you what you uh what had [41:39] pointer semantics usually reference [41:41] semantics and what had value [41:44] semantics and I was quite willing to [41:47] believe those types um that should have [41:52] pointer semantics and types that should [41:54] have value semantics but I really wanted [41:56] both and I really really really wanted [41:58] the value semantic types I never could [42:00] understand why an [42:02] integer was something you could have a [42:05] variable of and a complex number because [42:07] I defined the complex number was [42:09] something you had to put on the free [42:11] store and allocate with new I mean these [42:13] are fundamentally the same thing um to [42:16] to to quote doc melroy from about that [42:19] time there nothing abstract about a [42:22] complex number it's as real as reals [42:27] um and um so uh from very early on uh [42:33] I'm the first weeks or month you got [42:37] functions with interface checking you [42:40] got classes with Constructors and D [42:43] structures and direct support for Value [42:46] semantics and that's sort of the Rock [42:48] Bottom where things came [42:51] from yeah as I Was preparing for this [42:54] this [42:55] interview I I was just thinking about [42:58] the fact that you had done that so early [43:00] and back in the early ' 70s there was a [43:03] lot of discussion research on extensible [43:07] programming languages and Abstract data [43:09] types and yet people seem to somehow [43:13] kind of get distracted by by inheritance [43:16] and the reference oriented um [43:18] implementation models and and it seems [43:20] that only you follow that other path and [43:24] and gave us the ability to define a type [43:27] like the ones that were built in yeah [43:31] um it was on my list of things of things [43:34] I didn't particularly like about [43:38] simula and I talked to Chon about it and [43:44] uh he he says well it's just the the way [43:48] it is we had to put the user defined [43:50] types over there and I said that's not [43:53] ideal similarly uh but he couldn't build [43:56] the garbage collector if he didn't have [43:58] that similarly I talked to yand DAL why [44:02] don't you have multiple inheritance well [44:04] he said I couldn't build an efficient [44:06] garbage collector if I had multiple [44:08] inheritance in fact by modern standards [44:10] he couldn't build a an efficient garbage [44:13] collector at [44:14] all um but so when I was dealing with [44:18] with things at the lowest levels of the [44:21] system I I wanted the efficiency so I [44:24] couldn't afford a garbage collector so [44:26] putting things or on the free store is [44:28] something that is potentially expensive [44:31] but destructors take care of that um [44:35] minimizing the cost but I also really [44:38] wanted uh the types I really think about [44:42] uh complex numbers points uh uh sockets [44:46] uh matrices to be on the stack because [44:50] that's where I have the best control the [44:52] most automatic uh management of of [44:55] resources uh [44:57] well the most efficient it's the easier [45:00] use and efficient coming together again [45:03] I wanted them there and that was [45:05] something I actually more or less Knew [45:07] by the time I left Cambridge um not in [45:10] the sense that I I was going to do it [45:13] but in the sense that it has bothered me [45:14] that I couldn't do [45:16] it and then C of course has the value [45:19] semantics um at at the base of itself [45:23] and and that helped yeah but in it sense [45:27] it's as if you've taken out all 60 which [45:30] was stack oriented and and then enriched [45:32] it with the ability to to use the off [45:36] stack the heat storage but but in this [45:38] controlled way so it's it's very very [45:40] nice I I could have done that I wanted [45:43] to do it to AO 68 but decided that would [45:45] be a really dumb idea uh because nobody [45:49] else liked uh um Alo 68 and if you [45:52] wanted to do something practical if you [45:55] wanted to have an impact in the world [45:56] which did you have to do something that [45:59] other people can [46:01] understand right right yeah you have to [46:04] sort of engage with with the currents [46:08] that are that are there yeah um so it [46:12] sounds like at well at this point you're [46:16] you're designing a language you're also [46:19] working on your original research [46:21] project but but but it's sometime kind [46:23] of the early 80s it sounds like your [46:25] focus really goes more to the language [46:27] side yes is that is that right yes uh I [46:32] had my first real user after six months [46:36] C classes was a pre-processor and it was [46:38] fairly easy to get started and it was [46:42] aimed at at writing some initial [46:44] simulations that I I needed to figure [46:46] out how to design my stuff and then [46:50] other people started using it and then [46:53] when you have users you have [46:55] responsibilities and you have to make [46:56] sure sure that their Pro projects [46:59] succeed and since I got more and more [47:02] users I spent more and more time making [47:04] sure that my users were happy and at [47:08] that point I was doing the documentation [47:11] the tutorial the fighting bush fires the [47:15] teaching the starting of projects all of [47:18] that and I never got to build this [47:21] system U otherwise we might have Unix [47:24] clusters and Unix multicores about [47:28] 85 but I I got totally distracted and [47:31] for the next 10 years I was doing this [47:33] combination of language design and [47:36] support of [47:37] users I mean I was the help desk for a [47:40] long [47:41] time yeah and I guess the level many of [47:45] the other systems there Unix and c and [47:48] so on had a lot of those same kinds of [47:50] documentation and so on but that was [47:52] typically spread over multiple people so [47:54] you were you were a Onan [47:57] yes [47:59] yes so [48:03] C++ sort of emerges as as a name and as [48:08] a as as a a new implementation and as as [48:12] a more sophisticated language around [48:15] this [48:16] time out [48:18] um first going to the outside world [48:22] around [48:24] 1885 um is that right we we [48:27] had uh educational releases and specific [48:31] releases to people who asked to to use [48:33] it for [48:35] educational uh purposes so those people [48:39] using it um certainly in 84 and uh into [48:47] 85 in uh October 85 we had a commercial [48:52] release which was known as the Brown Bag [48:55] release uh because it was so cheap um [48:59] and because it has been so economically [49:01] co building it I wrote 98% of everything [49:05] there documentation build procedures [49:07] testing language The Works uh so that [49:11] was cheap because I was doing research [49:14] and actually what I was really doing was [49:15] supporting users for doing interesting [49:18] projects and so in from a from a [49:20] corporate point of view it was [49:23] free and and the cost of the cost of [49:26] getting an implementation for a [49:28] university was 75 bucks which was the [49:31] cost of putting it on a Mac tape and [49:33] shipping it physically right right okay [49:37] so essentially that was free for [49:38] academic use for all practical purposes [49:41] yeah and how about commercially if if a [49:44] there there was a rather large fee I [49:46] think it was [49:48] $40,000 but then you got the then you [49:51] got a source then you got a source [49:53] license and you could do interesting [49:55] things with it and people did were [49:58] people running it only on the same um [50:02] instruction set that you were was that [50:04] pp1 still oh no oh [50:07] no oh oh no uh quite early on I decided [50:11] that running on a single machine was [50:14] well [50:15] suboptimal uh the people I dealt with uh [50:19] the people who were my users who would [50:21] like to be my users or myself didn't [50:24] just use one machine and so so my C++ [50:28] compiler CF front was an natural cross [50:32] compiler and um the way that tended to [50:36] work is I would generate C for the [50:39] Target machine so if you had a c [50:41] compiler we could hijack the C code [50:43] generation and Tool infrastructure and [50:45] deers and such by by generating C but [50:50] since C is not 100% portable you have to [50:53] figure out how to do this and the way I [50:55] did it I wrote a little prr program that [50:57] you run on your target [50:59] machine and it figures out what is [51:03] machine dependent on that system so if [51:06] you have a Unix uh and a c I can run [51:10] this program and it will tell me it'll [51:12] write a file that tells me what C is [51:15] like on that machine what is the size of [51:18] an integer what's the size of a pointer [51:21] uh do you have signed or unsigned uh [51:24] characters so I get a little file which [51:26] I mail back to the original and you just [51:29] plug it in it was a plot plot plus X [51:32] option that takes a file and this [51:35] changes the compiler's view of what it's [51:38] generating for from its own machine to [51:40] the Target machine and [51:43] so those really weird architectures like [51:46] The Craze where it took a whole month or [51:49] or the univa where it took a whole month [51:50] to Port seafront but most times we got [51:54] it down to about 3 hours [51:57] which before shipping and packaging and [52:00] uh large tools were actually pretty good [52:04] yeah did well did you when um this 1.0 [52:09] release came out did you actually [52:10] include the the binaries for bun of [52:12] those PS [52:14] or [52:18] uh I don't [52:20] remember um obvious obviously there was [52:23] a binary for at least one machine on [52:27] that tape otherwise it would never have [52:29] worked but I I don't remember I we we [52:34] did not generate um 50 binary versions [52:38] and put it on the tape um 50 is a random [52:42] number but I know customer I know the [52:44] number of Target architectures were more [52:46] than 20 and we didn't do that yeah okay [52:50] makes sense so perhaps without getting [52:54] into every detail it might makes sense [52:56] to talk a little bit about sort of the [52:59] how the language has evolved you know [53:01] when you describe the the SE with [53:04] classes it it um had inheritance but no [53:07] virtual functions it had this nice [53:09] support for Constructors and destructors [53:11] and treating a userdefined object as [53:14] essentially a first class Citizen and [53:17] now new things are happening in a [53:19] language yeah [53:21] um when we changed from C classes to C [53:26] Plus+ which was in the winter of 84 uh [53:31] 8384 um I'd been working with o operator [53:36] overloading I really needed to get the [53:38] value semantics I really needed [53:41] assignments and some of my friends [53:43] needed [53:44] operators uh they actually needed and [53:46] and or and exor for some um machine uh [53:51] simulation kind of stuff uh not not plus [53:54] and minus that came later actually was [53:57] thrown in the same thing but the demand [53:59] was not for those and the really [54:01] interesting things was subscript and [54:03] application from which we get the [54:05] current containers and the function [54:08] objects uh that came in then the other [54:11] thing that came in was virtual functions [54:13] which I knew from simula but I was [54:16] totally incapable of convincing people [54:18] they were useful uh the attitude was you [54:21] want to call a function and you don't [54:22] know which one it is haven't you [54:24] analyzed your problem [54:27] and if you really need an interaction [54:29] why don't you you just use a uh Point as [54:32] a [54:33] function and well I said you can't [54:36] manage that at scale and uh I can't [54:40] teach it and so we we got uh class [54:43] hierarchies Ella Ella uh simul but with [54:48] multiple inheritance because I thought I [54:50] needed it uh these days everybody uses [54:54] multiple inheritance uh they use [54:56] multiple inheritance of interfaces [54:58] everybody who has a language that can [55:00] specify an interface has multiple [55:02] inheritance of interfaces I he Java 8 [55:05] has finally gotten multiple inheritance [55:07] of data also um it's it's not as useful [55:12] as interfaces but it's sometimes it's [55:14] just the right thing and I guess the [55:17] main reason I'm mentioning it is that [55:19] I've had so many years being told it was [55:21] a design error uh so it's interesting to [55:24] see another major language adopting it [55:27] in some some form [55:30] um and uh there's something important [55:35] here [55:37] references um once we have [55:41] chipped uh release one and release 1.2 I [55:45] actually got some time to think I've [55:47] been very busy for a few years and uh uh [55:51] I was thinking about error handling and [55:54] I was thinking about generic types [55:57] the other thing that you can find in the [56:01] very first paper on SE classes is an [56:05] explanation of why you need to [56:07] parameterize things like vectors with [56:10] types because you don't really just want [56:12] a vector of doubles and a vector of in [56:14] you want a vector of [56:16] T and that was in there very early and I [56:19] explained merily why you need it and how [56:22] you could do it claiming that macros [56:24] would do the job so I got the right [56:27] problem and the wrong solution because [56:30] again macros is one of these solutions [56:32] that works for one or two [56:35] guys um working closely together and [56:38] knowing what they're doing it does not [56:40] scale uh if you have many [56:43] users relying on Macros uh creates hell [56:47] and so I needed something better I I [56:50] knew I wanted it and I didn't know what [56:51] it was so I uh designed templates [56:56] and templates came with basically [57:00] three fundamental design uh aims I [57:05] wanted it to be General I had learned [57:09] that I cannot imagine what people want [57:11] to do and I'd suffered from languages [57:14] that were designed to make sure that you [57:16] could only do what the designer thought [57:18] proper uh I didn't want to design one of [57:20] those languages so generality was very [57:23] important uh the second thing was [57:25] performance [57:26] I still would like to maintain what I [57:31] had named as the zero PRP zero overhead [57:34] principle that is once you use an [57:36] abstraction mechanism you run as fast as [57:40] the best hand coded uh uh alternative in [57:44] the basic language and in particular I [57:48] really dislike the [57:50] crra the crra is the ideal abstraction [57:54] of Hardware's memory [57:57] you can't do better than that it's a [57:59] fixed SE fixed size sequence of objects [58:03] that's all it is it doesn't know how [58:05] many uh elements there are in that [58:08] sequence uh it converts to a pointer [58:10] with the slightest excuse and the [58:12] pointers convert to other kind of [58:14] pointers with the slightest excuse and [58:16] you get bugs it's one of the major [58:18] sources of bugs so I'd like to put a [58:20] raise out of [58:21] business um and I would knew I would [58:25] never be able to do that that unless I [58:27] could make an [58:28] abstraction that could do a sequence of [58:30] elements better than arrays but at the [58:33] same courses arrays and we're close to [58:37] that with the current [58:38] Vector uh so I I needed something like [58:42] that those are two things uh [58:45] generality [58:47] and uh low cost abstraction zero [58:50] overhead abstraction and finally of [58:52] course I wanted interfaces good [58:54] interfaces like [58:56] so I can get [58:57] modularity and I had to give up nobody [59:01] knew how to get all three and I thought [59:03] I had no choice but to meet the two [59:06] first criteria but the third criteria [59:08] decent [59:09] interfaces I and I think everybody else [59:13] knew only how to do that if you either [59:16] had macros which are unmanageable or [59:19] have [59:22] um something that's less [59:24] General h and is particular have [59:28] something that has a vector of uh [59:31] functions a jump table somewhere which I [59:34] couldn't afford if I wanted the [59:36] performance of arrays for a vector [59:40] abstraction so that was a design problem [59:42] that sort of defeated me at the time and [59:45] uh we've been working on it ever since [59:47] as you know and uh last week they voted [59:51] Concepts out to National body [59:54] vote and so so we should have a [59:56] technical specification of Concepts that [59:59] solve that problem um later this year it [60:03] should have been 14 it will be in 15 uh [60:06] the C++ standards committee has never [60:08] lost a national body vote as a matter of [60:12] fact we' have never had a negative vote [60:14] in a national body vote we work very [60:16] hard for consensus so we should get it [60:19] today and you can download it and use it [60:21] today in a branch of GCC uh Andrew um [60:26] sorten uh built that one he used to be [60:28] my um my post do he's now a professor in [60:31] acran and this is a design that many [60:34] people took part in including you Paul [60:37] and a lot of inspiration came from Alex [60:40] stefanov and uh some of the stuff came [60:44] from me in trying to simplify the way [60:46] it's expressed in a language as opposed [60:49] to what should be expressed and how you [60:51] could express it which to a large extent [60:54] came mostly came from [60:56] Alex oh well that's really good good [60:59] news to hear so this is a a feature [61:01] that's been 30 plus years [61:05] inition in gestation yeah I blew it I [61:09] blew it in um in 80 one or thereabouts [61:13] knowing I wanted it but couldn't do it [61:15] right I came a lot of the way in 88 when [61:21] we got templates templates has been a [61:23] huge success but it it has the weakness [61:27] in how to specify interfaces which gives [61:29] really bad error messages complex code [61:32] and such it's unnecessary we tried again [61:35] 2002 but got distracted by people who [61:39] wanted something that was truly object [61:41] oriented or just like hasell in both [61:45] cases you get these jump tables these V [61:48] tables in place and then you need heroic [61:50] efforts to optimize them away and these [61:55] heroic efforts don't tend to scale that [61:58] is you can get really good performance [62:00] of a sort of a pobble sized program uh [62:04] fits in a in one column in a pble paper [62:08] but if you um if if if you're doing it [62:11] in industrial scale software uh the [62:14] optimizations don't get good enough and [62:16] you get costs as if you going through a [62:19] uh interface to a abstract class or [62:22] something which we can't afford not if [62:24] you want to compete with AR [62:27] raay right yeah I was thinking as you [62:29] were mentioning that principle of of the [62:32] you know the no overhead performance [62:35] that that really you could trace that [62:37] back to the original for project [62:39] John vakas had a goal that he Le a [62:42] language that scientists and [62:43] Engineers could express their problems [62:46] in but that the professional Assembly [62:49] Language programmers of the time could [62:51] could not do better hand optimization [62:53] and he was actually able to achieve that [62:55] so so by a balance of not overly complex [62:58] language structures and then a very good [63:01] compiler yeah I mean this this this idea [63:05] that things has to be affordable is is [63:07] really really important uh there are [63:10] lots of areas where you can waste a lot [63:13] of computing power I mean um our cell [63:17] phones has a thousand times the [63:19] performance on the PDP 11 that I started [63:22] the CU classes on similarly with the [63:26] little VX machines that I completed the [63:29] job on for the commercial thing it's a [63:31] thousand times and more memory than that [63:34] and and people can afford to throw away [63:37] 95% of that or 99% of that and do a lot [63:40] of things that they want so please don't [63:43] get me wrong I'm not saying everything [63:45] should be efficient but some things have [63:49] to uh for and lives because there are [63:52] applications that takes the biggest [63:54] computers on the Earth uh months do and [63:58] C++ uh survives for this kind of stuff [64:01] because there are things like the the [64:05] the video cards and the uh uh Graphics [64:09] the networking software the [64:14] um the the signal processing and such [64:18] all of this kind of stuff that's at the [64:20] bottom of every system has to be [64:22] efficient and if you can run twice as [64:24] fast in those [64:26] areas well you need half the number of [64:29] computers um if you look at Google or [64:32] Facebook and their server Farms if you [64:35] use a language that's half the per raw [64:38] performance you need twice as many [64:40] server Farms this this can be measured [64:43] very easily you just count [64:46] two cooling twice the maintenance twice [64:50] the monitoring twice everything um I've [64:54] talked to people [64:56] concrete about what they can do on a [64:57] machine and they really really want the [65:00] latest optimizations and C++ because [65:04] they they really need that extra factor [65:07] of two or four or 10 that you get [65:09] compared to some other languages or 50 [65:12] for that [65:13] matter right we sort of in some sense [65:16] here this has been very interesting [65:17] we've kind of jumped ahead of that that [65:21] um the story that that you were telling [65:23] us early these features were some of the [65:26] last things the templates and exceptions [65:28] that you had been thinking of but that [65:31] around that time you were also starting [65:33] to think that you needed to standardize [65:34] the language could you tell us a little [65:36] bit about that sure yeah this is typical [65:39] we we drifted away from from sort of the [65:42] history and into the design [65:44] issues um that's fine but yeah no no no [65:47] I'm I'm just uh just thinking back about [65:51] what we were saying um no I did not [65:54] decide that we needed to [65:56] standardize uh a couple of guys Dimitri [66:00] linkov from HP and somebody from IBM I [66:03] don't recall the name right now came to [66:06] my office one day and said that I wanted [66:08] to have anti standardization of [66:11] C++ and um I sort [66:15] of tried to explain that this was a dumb [66:18] idea and that the language wasn't [66:21] finished and uh I needed more time [66:26] and they explained to me that you [66:28] couldn't have a language in major [66:32] industrial use where you could lose the [66:35] design implementation team to uh because [66:39] you got run over by a [66:41] bus very nice polite [66:44] explanation but um so I still talked [66:48] about how I needed more time and they [66:49] sort of they twisted my arm a bit more [66:51] and in the end I went ow ow ow yes I'll [66:54] do it I'll do it we'll do it next year [66:56] uh and we agreed on on next year and so [67:00] the first meeting happened uh in [67:03] December [67:04] because well that wasn't next year but [67:07] uh it was close enough for and and [67:10] anyway so that's how we started no I did [67:13] not have the very correct idea that we [67:16] need a standardization I was too busy [67:19] doing my own stuff now NC and later ISO [67:24] standardization [67:25] is a huge pain in the neck with lots and [67:28] lots of people involved lots of lots of [67:32] people working very hard very often with [67:35] no clear idea of where the language [67:37] should be going in the future very often [67:40] with the idea that if we can slow [67:43] down progress and change we can get [67:46] something that's good and stable and um [67:50] let let somebody else do the Innovative [67:52] stuff and others who wants to turn it [67:55] into into the latest fashion I mean for [67:58] all of the '90s people wanted to turn [68:01] C++ into a truly objectoriented Language [68:04] by jettison the sea idea except for the [68:07] part of the committee that really [68:09] couldn't uh care too much about the [68:12] objectoriented stuff and what rather it [68:14] was closer to see so having Direction in [68:17] a standards committee is really hard on [68:20] the other hand the guys were [68:22] fundamentally right you needed some more [68:25] organization that keeps the language [68:28] stable and evolving and that's very hard [68:31] to to to do I think things would have [68:34] worked much better if we had had some [68:36] resources so that there could be a a [68:39] design or Evolution group that worked [68:41] full-time on where the language should [68:43] be going and then the uh committee as [68:48] large would would deal with with with [68:50] polishing and checking and compatibility [68:53] issues but that's not the way it is [68:55] there there is a group in the committee [68:58] that deals mostly with future stuff and [69:00] there's others that deal future with [69:03] deals more with sort of everyday [69:05] problems and there's a tension there but [69:08] there's no resources for doing a serious [69:11] experiment for [69:12] instance uh we we we try and improve the [69:15] process we now have study groups that [69:17] run in parallel and we have more [69:19] internal groups but now we have [69:22] communication problems between the [69:23] different groups and such it's it's very [69:25] very hard so you need a central [69:27] organization you need more than one guy [69:31] or a couple of guys to run something [69:33] this big but organizing that is really [69:38] difficult well you've stayed all through [69:41] that process um as the principal [69:45] designer of the language and yet other [69:49] people have have been contributing ideas [69:51] and features what what does that sort of [69:53] feel like just you know from your your [69:56] point of view was it sort of having your [69:59] daughter get up and get married [70:01] or no no no it's [70:05] um it it's nice when [70:08] people improve things it's it's really [70:12] painful when people try and take the [70:14] language into a direction I really [70:17] disagree with and then then you have to [70:20] stop and it's really painful when I am [70:25] really certain about which way we should [70:28] go uh and people say oh we can't do that [70:31] or we should uh make it more elaborate [70:34] and more complicated and we really must [70:37] follow this fashion not not not uh not [70:40] what you're saying so it's hard to get [70:42] things through of course sometimes they [70:45] were right and I shouldn't go the [70:46] direction I would have gone I hope I [70:49] would have discovered in time and it [70:51] would not have been set in concrete uh [70:54] but certainly [70:55] the breaks have worked at times and [71:00] sometimes we've gotten things that that [71:02] probably shouldn't have happened because [71:03] as a comedian you can't be [71:06] everywhere but it it's very difficult uh [71:09] it's something that's underestimated I [71:12] really understand why most language [71:14] designers don't do this or why no [71:17] language designers do this other [71:19] languages have committees that are [71:21] disjoint from the original designer or [71:23] designers other languages have dictators [71:27] for life or something like that uh going [71:30] through the standard Pro process has its [71:33] strength and weaknesses and it's [71:35] certainly very painful if you're the [71:37] language [71:38] designer but possibly necessary from [71:41] what you've said in the latest version [71:42] of your language book you seem to be [71:46] pleased about where the language has C+ [71:49] C++ 11 and C++ 14 is just a much better [71:53] tool and one of the the reasons actually [71:56] is that I succeeded to some extent with [71:58] my sort of the current push is to make [72:01] simple things [72:02] simple um I was part of the people who [72:06] did the the the for Loop the range for [72:08] Loop like in many other languages Auto [72:12] which is like V or let in some other [72:14] languages uh something I implemented in [72:18] 83 884 and was forced to take out again [72:22] uh partly for C compatibility reasons [72:24] and partly because nobody could [72:25] understand what it was [72:27] for uh similarly we might get [72:29] co-routines now finally uh which again [72:32] was something I was doing in the very [72:34] early days but haven't been able to to [72:36] to get through um that's that's future [72:39] but uh some of the things people are [72:41] most excited about C++ 11 actually is [72:45] not the advanced features it's some of [72:48] the simplifying features so that they [72:51] can write less code or repeat themselves [72:54] less often [72:55] um less fewer opportunities to make [72:58] mistakes I'm not a fan of the current [73:01] trend of trying to [73:03] absolutely minimize the amount of typing [73:05] you have to [73:06] do um partly because then you have to [73:09] know some much and there there has no [73:12] clue left in the code about what it [73:14] means and partly because we read code [73:16] much more than we write it but certainly [73:19] C++ has become two veros uh one of the [73:22] things about Concepts is that it [73:25] actually simplifies the syntax of [73:27] writing uh simple templates so instead [73:31] of [73:32] writing um template type [73:36] name [73:38] I uh void of [73:41] sort uh I of I one comma I of I2 and all [73:47] of this you write V void sortable ref C [73:52] it looks just like the function [73:55] declarations we were used to uh in in 0 [74:01] uh in 82 were thereabouts and basically [74:05] Concepts can handle the old view of a a [74:09] concept being the type of a type and it [74:12] generalizes to saying that there should [74:15] be a set of types and values that should [74:18] meet a set of criteria so you can say [74:21] that merge takes three types that should [74:24] be merged ible meaning that um there [74:28] should be an input two input streams [74:31] there should be an output streams and [74:33] the relationships between the input and [74:35] output streams has to be just right we [74:38] can express that with simply saying [74:40] mergeable I comma o or something like [74:43] that oh and the [74:46] criteria so again yeah I have this [74:49] design idea that simple things should be [74:51] simple and complicated things well [74:54] they'll have to be a little a little bit [74:55] more complicated and I hate making [74:57] anything [74:59] impossible right but in those examples [75:02] with C++ 11 and 14 it's it's as if [75:05] there's a sort of almost a scripting [75:06] language style of programming has become [75:10] possible so it's a new paradigm in a [75:12] sense could be the the it it's still uh [75:16] strongly typed as a matter of fact the [75:18] code I write today are more strongly [75:20] typed than it used to furthermore it's [75:22] statically strongly typed not descript [75:25] interpretation and one of the things we [75:28] do one of the things we are doing with [75:31] Concepts is we are going away from the [75:34] dock typing model of templates which is [75:36] what most of the scripting languages are [75:38] doing into an interface-based uh model [75:42] of computation which is what the rest of [75:44] C++ is and scripting languages by and [75:47] large is not are not scripting is not [75:49] the best word maybe say casual program [75:52] it's this compactness yeah um that's [75:55] very nice by the way speaking of of of [75:59] um [76:01] Concepts you you alluded to Alex stenov [76:04] and STL earlier in the talk but it might [76:07] be a good time for you to just say a [76:09] little bit about you know how you got to [76:11] know him and and and what what that has [76:14] led to Yes [76:17] um [76:19] Alex um worked at some part of AT&T for [76:24] a while [76:25] and before that he had been a GE and [76:28] he's moved around a [76:30] lot and I remember discussing things [76:34] with him uh pre STL when he was at [76:38] AT&T and he was trying to convinc me to [76:41] do things the way they had done in aah [76:43] because that was the language he was [76:45] using at the time to express his ideas [76:47] in and I learned a lot from him but I [76:50] was not going to go that way in [76:53] particular I was not going to have any [76:55] statements for [76:56] instantiating uh generic types and I was [77:00] not going to put in uh the restrictions [77:03] for um so that you couldn't have [77:06] conversions I mean to this day Alex and [77:09] I disagree with what you do with mixed [77:11] mode arithmetic I I I really like to be [77:14] able to to multiply a um a double with [77:18] an integer and in generic context that [77:22] create some complexity but I also [77:25] learned something about what could be [77:27] done from Alex and the importance of [77:31] being able to inline everything type [77:33] information mustn't get lost this [77:36] completely plays into my zero Warhead um [77:40] bias in in design and then Alex went [77:44] away and I implemented the the first [77:47] version of [77:49] templates um and then something came [77:52] back via um um Andrew kernick which was [77:57] U the [77:59] STL and to be honest I thought it looked [78:02] really ugly and it certainly looked [78:05] completely wrong uh like everybody else [78:08] at the time I had gotten this idea that [78:12] that things had to be object oriented in [78:15] the container world and you had to have [78:17] a hierarchy of [78:19] containers and you had to have a [78:21] hierarchy of iterators and those was [78:24] working like that and of course STL is [78:26] totally different um I mean the STL is [78:30] based on the notion of Concepts that [78:32] just wasn't any language support for it [78:34] and it's it's based on generic [78:36] programming uh and it meets the Ser oead [78:40] principle because the code generated [78:41] from it is really uh really beautiful [78:44] from a machine point of [78:47] view furthermore it was not just a [78:50] container Library it was a container and [78:52] algorithms library or I guess from [78:55] Alex's point of view it was a um [78:58] algorithm library that also had some [79:01] containers and I looked at that for a [79:04] couple of days [79:07] um not being very enamored by it and [79:10] Andy was pushing that this really works [79:14] and it turns out that I had over the [79:17] years built up a set of [79:19] criteria for what a good container [79:21] Library should look like I actually had [79:24] a list sitting somewhere with I think 11 [79:27] points you can find it in my third [79:29] edition of the C++ programming [79:31] language and uh checking Alex's [79:37] design uh against my list I realized [79:40] that about uh apart from everything else [79:43] about uh the STL it Met 10 out of 11 of [79:47] my criteria I may get the number [79:50] slightly wrong maybe it was 12 out of 13 [79:52] something like that but certainly the [79:54] was only one thing left and the one [79:56] thing was uh having [79:59] facilities uh common to all uh um [80:04] containers things in common for all [80:07] iterators that way you could get [80:09] debugging or serialization or something [80:13] uh anything but that it did and it did [80:15] very well and so I think well yeah it [80:18] looks odd but you know it meets all the [80:21] criteria and nothing else does actually [80:23] all but one of the crit area has nothing [80:25] else done I've been looking for years I [80:27] haven't found something like this and [80:29] then it does all this neat stuff with [80:33] algorithms and so yeah this is good um [80:37] the chances of the standard committee [80:40] accepting it is of course very low but [80:43] you know it's so good it's worth [80:45] trying so we did a few things with the [80:48] standards committee including bringing [80:50] Alex in and Alex is a absolutely First [80:53] Rate rber browser and he got those guys [80:57] excited in the way I've seen nobody else [81:00] being able to do and I kept plugging [81:03] Andy kept plugging and after a couple of [81:06] years we finally got it [81:08] in um and and that was very very [81:11] difficult you had to convince a lot of [81:14] people with different [81:15] backgrounds uh there was a couple of [81:17] critical things like beand dors who is [81:20] one of the uh founders of boost um in [81:25] the middle of I think the the meeting [81:26] after the one where Alex had explained [81:28] things when people were being somewhat [81:31] rude about the STL and this complexity [81:34] and this difficulty and it [81:36] ugliness he spoke up and says you know I [81:39] thought that too but since the last [81:42] meeting I just thought I would try and [81:43] see what it was and I implemented about [81:45] a tenth of it and you know you're wrong [81:48] it's not that complicated it's [81:50] relatively easy to do and it's cleaner [81:52] than what we're doing that was very [81:56] important um again this thing about the [81:59] standards committee there's lots of [82:00] people sometimes they really help [82:04] sometimes they get in the way but in [82:05] this particular case Ban's contribution [82:08] was [82:09] essential um another reason why it was [82:12] very difficult to get a library like the [82:16] stln was that everybody by then had [82:19] their own object oriented container [82:21] hierarchy and at one point [82:25] Texas instrument was going to [82:28] propose uh their very nice [82:31] objectoriented container Library um and [82:35] they were going to do it right after [82:36] lunch and the [82:38] Rumor spread in the committee or lunch [82:41] that they were going to do this and [82:44] after lunch I think we had five more [82:47] organizations saying that if we are even [82:50] going to discuss this proposal you're [82:53] going to discuss [82:55] our corporate uh hierarchy also and [82:59] these also guys are people like new and [83:02] IBM and Microsoft and forland so uh the [83:07] the these are not lightweights and it [83:09] was obvious that it would run into um [83:14] impossible [83:15] opposition and the fact that the STL was [83:19] so different and the fact that it had [83:20] the algorithms were probably crucial to [83:23] get even to get people to look at [83:26] it uh it was a beautiful piece of work [83:29] still [83:32] is and [83:34] so things kind of fell into place with [83:37] with STL event I mean after this these [83:40] things you described but from that point [83:41] on it kind of became accepted but but [83:44] the concepts issue was something that it [83:47] sort of in some sense it really created [83:51] a new um demand for for solving that [83:55] problem because now you have this Rich [83:57] set of algorithms that you'd like to [83:58] describe yes there's a huge pressure for [84:02] concept that was building up from two [84:04] sources one was simply the bad error [84:08] messages and two from my perspective was [84:11] that people got really enamored with the [84:13] doc typing templates [84:15] provides um compile time doc typing and [84:20] so we get a lot of compile time work and [84:22] a lot of Doc typ in where we don't quite [84:25] know what's going on and where the [84:28] implementations of the templates sort of [84:31] shines through because there's no [84:33] interface and you have to know it and so [84:35] we got some horrendously complicated [84:37] code that that does amazing things but [84:41] people have trouble understanding it and [84:43] where the limits are and so my view is [84:46] we need concepts for the traditional [84:48] generic programming and for some of the [84:51] template meta programming to to [84:52] introduce proper interface [84:55] and then we'll see what's what's left [84:57] after that um expression templates [85:01] cannot be um done well with Concepts [85:05] because you're simply manipulating [85:07] syntactic structures they don't have [85:09] semantic meaning till later so that's a [85:12] problem that's left the other thing that [85:15] happens with templates was that people [85:16] realized that templates couldn't just be [85:19] used to generate new types they could be [85:22] used to generate values [85:25] and a lot of template meta programming [85:27] is programming that generates values [85:29] like two or 32 or 99 or something like [85:34] that and some of the weirdest uh and [85:38] code is like that and essentially all of [85:41] that can now be done with what's known [85:44] as conspect or functions that is [85:46] functions that can be computed at [85:50] compile time which is a a complimentary [85:53] approach [85:55] that um Gabby do R and I did realizing [85:59] that there was a major need for compile [86:02] time computation uh both from the [86:05] embedded systems programming and also [86:07] some of the stuff that we saw done with [86:10] templates and Computing a value you just [86:13] use a function I mean we know how to do [86:15] that that should be just that um and [86:19] people in the embedded systems [86:21] programing World tended to use macros [86:24] and now you get to typeless programming [86:27] and people in the template world uh use [86:30] templates so now they get duct typing [86:33] and we really wanted ordinary functions [86:36] where you give arguments of a given set [86:40] of possible types and you generate [86:43] results in the appropriate thing and [86:46] that's that's all it should be like [86:48] we're back learning our first function [86:51] and we're getting there uh conster is in [86:54] C++ 11 is heavily used 14 uh does it a [86:59] little bit more General that is you can [87:01] now have a loop inside [87:03] a uh conexa function that means the [87:08] fundamental rule of a conexa function is [87:11] that it can be done at compile time it [87:12] means it cannot have any side effects [87:15] because the rest of the um world hasn't [87:19] been created yet uh so obviously they [87:22] must be side effect free that means they [87:24] pure functions it also means that any [87:27] state that exist exists only uh during [87:30] the execution and and you get some some [87:33] really nice stuff out of that so there's [87:37] actually two [87:39] attempts [87:40] to uh limit the the weird forms of [87:44] template meta programming limited [87:46] template meta programming to where it's [87:48] actually you want meta programming and [87:50] the one is to take the generic code out [87:53] with Concepts and the other one is to [87:56] get the um the compile time computation [87:59] done with functions and of course con [88:02] exper functions can be templates that [88:04] can take Concepts as as argument types [88:07] so it it it all fits together similarly [88:10] the function objects that we've been [88:12] using for years [88:14] with with with templates and with the [88:17] STL uh I mean function objects go back [88:20] to to [88:22] 83 uh when when I allowed the [88:24] overloading of the application operator [88:27] and we've been using them ever since [88:29] there's versions of them that early they [88:31] become essential with the STL which is [88:34] the efficient way of parameterizing with [88:36] an operation and then people come with [88:40] lambdas and you can define a function [88:44] object right in the place so a function [88:46] object in [88:48] C++ is is is something with an [88:51] application operator H Lambda is [88:54] something that generates a function [88:57] object in place and evokes it invokes it [89:01] when necessary so it's a it's it's a [89:04] shorthand notation for function objects [89:07] that we' had all the time and they run [89:09] as fast as uh function objects possibly [89:12] even faster if you do trickery with with [89:15] stack [89:18] frames so right C++ now is it it [89:22] supports pretty rich functional [89:24] programming and Abstract data types [89:28] objector programming it's all those [89:31] languages that you study to the 70s are [89:34] are here and More in one framework in [89:38] one framework that's important um I mean [89:41] that was why I emphasized that Lambda is [89:43] really a function object and function [89:45] objects have been there um since before [89:48] day one for [89:49] C++ uh so so it it does fit together [89:52] there's a lot of bacle there which sort [89:55] of is complicating writing code um but [90:00] but there is an in in in inherent logic [90:04] uh [90:05] there and uh I was not deeply into [90:08] functional programming in the ATS so [90:10] this this this is relatively new I knew [90:13] the abstract data types I knew the class [90:16] hierarchies uh and I knew the the close [90:19] to the machine programming functional [90:22] programming uh is a set ideas that has [90:24] grown over the years uh some of them [90:27] coming out of the lisp [90:28] World um and now we have some of the [90:32] aspects in in C++ but it ties together [90:35] with what's been there for a long [90:38] time right um well there's that reminds [90:42] me of one of my other questions in your [90:45] um hole paper the second ho well the [90:47] third H conference um you mentioned s of [90:51] three Key properties of C++ and and you [90:55] sort of sketch how you might be able to [90:57] build a kind of a simpler language that [91:00] that would have the spirit of C++ have [91:02] you have you done any more thinking yeah [91:05] I've done a lot of thinking about this I [91:07] I think the key statement [91:09] in in that conclusion section of the the [91:13] Hubble 3 paper is I [91:16] think we can build a language with the [91:19] expressive power of C++ and the ability [91:22] to deal with with Hardware the way C++ [91:27] does um that's a tenth of the size [91:30] measured any way you like for size and [91:33] without loss of [91:34] performance and I think that can be done [91:38] um I have worked more on on on these [91:42] ideas um if you look at the move [91:44] semantics uh coming mostly from Howard [91:47] hinnen but the following trends of and [91:50] and and dirty triggery that we used for [91:52] years to get effects like uh that but [91:55] they didn't scale till Howard's [91:57] contribution we can now build basically [92:00] a a close system where we where we do [92:03] not leak resources so I talk about [92:06] resource safety people talk about memory [92:08] safety that is a [92:11] relatively uninteresting thing uh you [92:15] can you can a system much faster [92:18] by leaking um leaking file handles than [92:22] any other leak I can think of [92:24] including memory so I I want when when I [92:27] talk about resource safety which is [92:29] something I want um I'm thinking about [92:32] file handles thread handles locks [92:35] sockets the works and I think we can do [92:37] that now uh garbage collection gives us [92:40] one thing which is a problem for the [92:43] kind of world I have and that is if you [92:45] take a pointer to something that's local [92:48] and then store it store it and wait for [92:50] the stack frame to go away you have a [92:52] major problem and and how to avoid that [92:55] I'm not quite sure of uh there is [92:58] several ways um but I am decided which [93:03] is simple elegant efficient teachable [93:07] enough but yes I I still think you can [93:09] build a um [93:12] C++ like language that's much smaller [93:16] than uh than than than what we're [93:18] dealing with [93:19] now um I would not throw away C but I [93:23] might throw away some of the syntax of c [93:25] c is a model of how to deal with things [93:28] it has objects it has pointers and [93:31] that's very important it maps to the [93:33] memory and you need that for a C++ like [93:39] language well let's see there was some [93:41] other things that I wanted hope we'd [93:43] have time to talk to it looks like we do [93:46] have a little bit more time if you do um [93:49] we sort of left in some sense your your [93:53] own person career and and we focused [93:55] more on the language maybe we could kind [93:57] of loop back and say that a dozen or so [94:00] years [94:02] ago [94:03] AT&T ceased to be the right place to be [94:06] and and you actually made an interesting [94:09] career transition there yes [94:12] so Bell Labs AT&T Bell Labs at the [94:16] height of its powers and I think the 80s [94:19] and '90s was was just a unique place in [94:22] the world there there was no place like [94:25] it um in the computer science research [94:28] center we had between sort of 30 and uh [94:32] 60 people during that period and many of [94:35] them are still my friends um I mean [94:39] extraordinary number uh have became [94:42] famous in one way or [94:43] other it fellows ACM fellows member of [94:47] the National Academy and things like [94:49] that um and we're just doing sort of [94:52] interesting work at the time and the [94:55] environment that made that possible uh [94:58] Bell Labs the philosophy that you could [95:00] let smart people work [95:03] on things they thought interesting [95:06] rather than having a command economy and [95:08] that you had a management structure that [95:12] kept that from going out of control it [95:14] puts a lot of emphasis on really good [95:17] department heads really good directors [95:19] so that uh you actually get something [95:21] out of a system like this and the idea [95:25] that you have a mixed portfolio of [95:29] um of of research so that something [95:31] comes along every year or so but that [95:34] doesn't mean that you can only work on [95:35] things that will come uh to fruition [95:38] next year um a lot of us were working on [95:41] things that that takes five or 10 years [95:43] to come out but every year every [95:46] Department delivered something of [95:48] interest and and managing that was was [95:51] difficult the environment was was really [95:53] really nice a lot of the people were [95:56] nice people a lot of the people are [95:57] still my friends uh there are of course [96:01] there was people with with enormous egos [96:04] they're not there's no shortage of [96:06] enormous egos in the uh computer [96:09] industry uh but many many people had no [96:13] need to have a huge ego or be U be rude [96:17] uh and they were some of the nicest [96:19] people I've [96:20] met um [96:23] that that was a good time and that was a [96:27] good time I brought up my children in uh [96:30] near near Murray Hill in in New Jersey [96:33] uh people have the strangest views of [96:35] New Jersey if you try and land there in [96:37] a plane you can't find it for the trees [96:40] uh that is not the image that people [96:42] usually have but it's a good place to to [96:44] bring up children it was a good place to [96:47] work uh then um Wall Street got an idea [96:51] that uh [96:54] vertically integrated companies couldn't [96:56] possibly work and so you need to chop [96:59] all the pieces and they also had the [97:01] idea that everything that can be [97:04] invented has been invented so you don't [97:06] need research or Advanced development [97:08] organization so you have to cut that um [97:12] both theories are wrong uh but it it [97:16] hurt uh B Labs enormously and it became [97:19] a far less interesting place to work um [97:23] first the belt system was broken up and [97:27] then AT&T and loosen split ways uh the [97:31] idea being that some people built the [97:33] switches and the other people uh built [97:36] the software for the switches and how [97:40] that makes sense to separate there I [97:41] don't understand especially since my [97:44] background is to working in exactly that [97:47] interface um anyway then we had some [97:50] good years at h&t Labs was in Park uh [97:55] just on the other side of the Great [97:57] Swamp from from Murray Hill and then we [98:01] got hit by another set of cutback for [98:03] forced by Wall Street that uh didn't [98:06] have much foresight about technology and [98:09] uh no tolerance to delays from from [98:12] research and was um was misguided by [98:17] false information given by World comp [98:20] they got fined later for for giving back [98:23] information but it hurt the labs badly [98:26] we lost 40% of our [98:29] um of our [98:31] phds uh in one uh Massacre I was an [98:36] apartment head at the time and they laid [98:38] off two of my people without telling me [98:42] um possibly because they knew that I [98:45] would have hit the ceiling very fast if [98:46] they told me so after that I was open to [98:51] to New [98:52] Challenges uh um I mean I wasn't laid [98:56] off and I had a nice corner office and [98:58] all of that but the oxygen has been [99:00] sucked out of the air I noticed that the [99:03] people left behind was on average less [99:05] interested that interesting than the [99:07] people that [99:09] left the people that left were the [99:12] troublemakers the people that would pin [99:15] down an executive in the corridor and [99:16] tell him he was all wrong um those guys [99:19] left and those were the interesting [99:21] people to talk to [99:23] um and then it so happened [99:26] that our youngest son had just gone to [99:29] University and was settled in there and [99:32] so the kids have gone to to University [99:34] and had a lot of fun so why shouldn't I [99:38] so when some of my friends suggested I [99:40] should go and become a professor sure [99:43] I'll try that I mean now I've been in [99:46] industry for 24 years I actually have [99:49] something to tell the students as [99:51] opposed to when I just came out from [99:53] school [99:54] and so it happens they were working on [99:56] some interesting problem at Texas A&M [99:59] University and this was a department [100:02] that really wanted to improve and we [100:04] have gone sort of 20 spots up in the [100:07] rankings since I joined so um we did do [100:11] something good and we reject the whole [100:14] uh curriculum and I tried to do academic [100:18] research I tried to teach freshmen I [100:20] tried to teach graduates I tried to [100:22] superv wi phds all of this good stuff [100:26] this was this was [100:28] interesting but uh [100:31] after [100:33] after 10 11 years it was beginning to go [100:37] a bit stale and also I have some [100:41] problems with academic research it it [100:44] has a tendency of drifting away from [100:45] real problems you abstract from a real [100:49] problem then you abstract from the [100:50] abstraction then you solve the abst [100:53] action of the abstraction of the [100:54] abstraction which may or may not relate [100:56] to the original problem and so I had [100:59] some problems there um some of the stuff [101:02] I thought was really interesting to to [101:04] work on was [101:06] unpopular um I once wrote a paper on how [101:09] to do abstract syntax trees uh 30 times [101:14] better than [101:15] GCC and the paper was rejected on two [101:19] reasons uh one three reasons two the [101:23] first was that we had misunderstood C++ [101:26] this was me and Gabby do R Who was the [101:29] French representative on the standards [101:30] committee and one of the the best uh [101:34] people on the standard um also he was a [101:37] shipping manager for [101:39] GCC um they also claimed it have been [101:42] done in GCC I mean this is total [101:44] bogus and then when we complained the [101:48] thing came back and says oh that's [101:49] engineering we're computer [101:51] scientists if we had been in engineering [101:55] for cars and come up with a 32 times [101:58] Improvement of one of the key components [102:00] of the gadget would have been Heroes [102:03] here it [102:05] took several more attempts to get the [102:08] stuff published and by the way it's now [102:10] in use in various of these compilers but [102:13] the these kinds of things were grating [102:16] these things are discouraging and in [102:19] particular it makes it hard to bring up [102:22] students well because if you want to [102:24] graduate as a PhD you need to have [102:27] Publications and de facto you that means [102:30] you have to follow [102:31] fashion and well following fashion is [102:35] not that fun um then so I was beginning [102:39] to think it's time to get back to um [102:42] back to Industry uh back to the kind of [102:45] problems that that that I know and like [102:48] and get them in the real form rather [102:51] than the distilled form form and cleaned [102:53] up form you get an Academia so again I [102:56] was sort of open to [102:58] suggestions and it so happens that every [103:03] year since the ages I've been going [103:07] around giving [103:08] talks in industry and Academia and such [103:12] uh basically I exchange a talk about [103:14] what I'm doing for uh an explanation of [103:17] what their problems are and uh that's [103:20] one way of making sure that when you [103:23] work on a design when you work on the [103:25] evolution of something it actually has a [103:28] direction and so I went and gave a talk [103:31] at Morgan Stanley in New York City and [103:35] after my talk um the sort of Not Unusual [103:39] suggestions started coming that maybe [103:42] I'd like to go and work there and my [103:44] answer was of course not I mean you're a [103:46] bank kind of stuff I'm doing is is not [103:49] what interest you and yeah yeah yeah [103:53] this is fine we we like this kind of [103:55] stuff and they point out some of the [103:57] things I'm doing that they're interested [103:59] in and I said oh my time Horizon is all [104:02] wrong for a a bank I mean some of the [104:04] things I really would like to do takes [104:06] at least 5 years oh no problem so um we [104:09] went through the song and dance and [104:11] eventually they uh they wore down my [104:13] usual defenses and then they had one [104:16] secret weapon that they didn't even know [104:19] they [104:20] had of all the organiz izations that had [104:24] the properties that that I could work [104:27] for they were the only one who lived [104:29] within 20 minutes of my [104:33] grandchildren and so um I'm semi logical [104:36] about this kind of stuff uh I have a set [104:39] of criteria they met them other people [104:42] meet those criteria but they were in the [104:44] right [104:45] place so I'm now sitting in my apartment [104:48] which is halfway between my [104:49] grandchildren and um and my work [104:54] well that's a pretty nice place to be [104:58] yes um well that's a very interesting [105:00] story so at well at Morgan Stanley you [105:04] are designing future versions of C++ [105:08] thinking about other programming [105:09] languages and what else um I I spent a [105:13] lot of time looking at uh at at problems [105:18] in the bank a lot of them to do with [105:20] with networking a lot of them to do how [105:23] to express [105:25] interesting um coding [105:29] problems um a lot of them has to do with [105:32] with performance a lot of what I'm doing [105:34] is fairly close to the hardware but not [105:37] everything so in some sense from that [105:40] perspective it's it's the same as ever [105:45] um they have different kinds of [105:47] reliability problems I'm always [105:48] interested in reliability of [105:51] dependency um and they do have the [105:53] interesting thing that you can't lose a [105:56] penny uh the the the answers has to be [106:00] correct to to the last penny um if if [106:04] you're doing a nice video system if you [106:06] lose a frame doesn't matter too much [106:09] even if you're doing a fuel injection [106:11] you can't uh lose a um a cycle but if [106:15] you're ever so slightly off for a single [106:18] squirt uh the engine will still keep [106:20] running and you can correct it and for [106:22] the for the next circle with with with [106:24] money you can't do that it's against the [106:26] law uh you have to get it right every [106:29] time not just on average so there there [106:31] are interesting constraints on the [106:33] problem but basically performance [106:36] reliability correctness same kind of [106:39] stuff and so I'm now closer to to [106:44] reality and I can do better language [106:46] design still part of the standards [106:48] committee and um I'm also a professor at [106:53] Colombia now so tomorrow I'll go and [106:55] give my lecture and uh so [106:58] I'm leaving Academia means I'm actually [107:01] a professor twice over because they [107:03] wouldn't let me leave Texas A&M either [107:06] but but most of my work is is in the [107:09] bank and uh uh working with the code [107:13] bases that that we have there and that [107:16] informs my work on the evolution of C++ [107:20] and my thoughts about [107:23] uh what can be done [107:25] better well you mentioned the challenges [107:28] of of being in Academia but do you have [107:33] some advice for you know a future grad [107:35] student who would like to impact the [107:37] role the programming language [107:39] design oh dear [107:43] um there is a lot of people who come [107:47] with the firm idea they want to build a [107:49] new language or they want to build a new [107:51] game or they want to build a new [107:53] operating [107:54] system [107:56] and what is lacking in most cases is an [108:00] understanding of what's the [108:02] problem that that is C++ succeeded uh [108:07] not so much because I made a beautiful [108:10] design but because I was really lucky of [108:14] having [108:15] identified a [108:17] problem that a lot of people were about [108:20] to get namely handling complexity [108:23] uh with [108:25] higher uh with larger memories and [108:28] faster uh processes we were writing we [108:32] then starting to write more complex uh [108:34] problems and I was trying to deal with [108:37] complexity but complexity under the [108:39] constraint of [108:40] performance which was what people didn't [108:43] get so that's the fundamental problem [108:45] that I uh that I decided to attack and I [108:48] was lucky I wasn't alone and my design [108:51] was was good enough for a lot of [108:53] people um so when people want [108:59] to look for a problem I think first of [109:03] all they they [109:05] shouldn't look for a project just to [109:09] change the world right [109:11] away uh they should try and understand [109:14] the set of problems and then come up [109:16] with [109:17] Solutions and you can do very particular [109:20] Solutions trying to to meet the deadline [109:22] for the next quarter and that's probably [109:25] the best way of getting [109:26] promoted and soon you'll become a [109:29] manager and you'll never do something [109:30] really useful [109:32] again uh or you can start learning from [109:35] The Experience generalizing the problem [109:38] and seeing is there a solution that can [109:40] help a broader Spectrum or or a larger [109:44] uh group of people larger setup problems [109:47] larger uh time scale and so focus on the [109:51] problem and and use the initial projects [109:54] and your uh Knowledge from [109:57] University uh to to come up with a [110:01] solution there I think all of our Theory [110:05] and all of our courses helps us solve a [110:08] problem um but we have to find the [110:11] problem first that's worth solving and [110:13] find the constraints on the solution to [110:16] the problem after that we have pretty [110:19] good ways of of of engineering a [110:22] solution [110:25] okay thank you that's that's very [110:26] interesting one one sort of final area [110:30] I'd like to just touch basis with this [110:33] um the compu History Museum was you [110:36] donated or you orchestrated maybe the is [110:38] the perhaps the best word the donation [110:40] of the seafront source code um to the [110:43] Computer History Museum we're really [110:44] grateful for that um just have [110:47] you what what are your ideas for how the [110:50] computer Museum can help both research [110:52] Searchers and and students or Educators [110:56] um on that you f first of all I should [110:59] point out that uh getting seafront into [111:03] the archives was your idea and I thought [111:06] it was a splendid idea and thank you um [111:09] I just collected some of the pictures [111:11] and the source code and the manuals and [111:14] such um so so this was good um I think [111:20] that students are [111:23] by and large [111:25] ahistorical they have not been taught [111:28] history they don't understand history [111:30] and they think that history has nothing [111:32] to teach them uh everything was invented [111:36] yesterday and uh everything is the [111:39] latest [111:40] fat and I think that that is most [111:44] unfortunate and I think the schools are [111:47] encouraging this [111:50] um there's a lot of schools that look [111:52] only at if they want to be Engineers [111:55] they look only at their science and [111:57] engineering scores Focus forcing them to [112:00] not take say history in high school uh [112:03] not to take a liberal arts uh education [112:07] in um in University uh but just just do [112:12] the the thing that's required and there [112:15] is a lot of emphasis in the press and [112:18] elsewhere about the best career being [112:22] the one that gives you the greatest [112:24] amount of money [112:25] soonest [112:27] and that is not a long-term motivator [112:30] the people that come through this [112:33] successfully are often not very nice [112:37] people uh they have spent all of their [112:40] childhood youth early [112:43] adulthood uh in a very [112:45] narrow area [112:48] and uh focused on on the careers to the [112:53] um exclusion of everything else that's [112:56] not good and I think people should know [112:59] more General history they should be [113:01] better at communicating which probably [113:04] the best way of getting to be a better [113:07] at communicating is to read a lot and to [113:09] listen a lot to other people and I think [113:12] the Computer History Museum can help [113:15] motivate by actually showing some of the [113:18] things that were done in the past and [113:20] especially if they focus a bit more [113:24] about why things were done um I went [113:28] through the Computer History Museum some [113:30] time ago and I went through some rooms [113:33] and here is model X of computer from [113:35] Factory y here's Model Z of a computer [113:39] from there and sort of it it looks like [113:42] one washing machine after another and [113:45] that very soon get stale yes I was [113:47] excited I realized I programmed this one [113:50] oh that was a fun one oh oh that I [113:52] couldn't get that one to work so if you [113:55] can go through that there is something [113:56] there but for for most [113:59] people it it's [114:02] just there's not something that [114:05] motivates them it doesn't tell what why [114:07] that thing was being [114:08] built um what are the kind of problems [114:11] it was used for uh showing just Hardware [114:15] I think is is on interesting and there's [114:17] a tendency of focusing on Hardware [114:19] because you can see it you can knock on [114:21] it it's pretty pictures but a computer [114:25] without software is sort of kind of a [114:29] boat anger right and um so more emphasis [114:34] on software not just languages [114:37] but what did that computer do for a [114:40] living how did people interact with that [114:44] computer what kind of problems was it [114:46] used to solve what kind of tools did [114:49] people use in addition to the hardware [114:52] to to provide those Solutions I think a [114:56] greater emphasis on that would be [114:57] helpful I may simply be behind the times [115:01] and the Computer History Museum may be [115:03] looking far more like what I'm [115:05] describing than it did when I went [115:07] through a couple of years ago but I [115:11] can't I don't want to see another uh [115:13] dishwasher like uh piece of Hardware out [115:16] of [115:17] context and I think as a museum you have [115:21] to collect art artifacts and compilers [115:26] databases uh application programs should [115:30] be part of those artifacts since there [115:32] are many many many pieces of software [115:35] for each piece of Hardware there should [115:37] be more software in the museum than [115:39] Hardware uh if you want to reflect [115:42] reality but once you present it uh you [115:45] have a challenge because software you [115:47] can't see you can't feel you can't knock [115:49] on it and so I think the context of the [115:52] computer the use of the computer uh the [115:55] problems that was to be solved by the [115:57] computer is is is probably one way of [115:59] addressing [116:01] that oh that's that's very interesting I [116:04] think you'll be pleased but um the [116:07] revolution exhibit is certainly better [116:10] at giving context than the original [116:12] visible storage area I'm not sure which [116:13] one you saw but they're working on a [116:16] major software exhibit they still need [116:19] some more funding for that and it's [116:20] trying to show maybe a doz [116:22] applications and systems in context you [116:25] know here's the problem to be solved so [116:27] when that's available hopefully you'll [116:29] get a chance to to come out and and see [116:32] sure I I just need to correct the record [116:35] it was really Alex stenov who inspired [116:38] me to collect not only C++ but a lot of [116:41] the other s Alex Alex is at the root of [116:44] many interesting things I didn't know he [116:47] had proded you in that [116:49] direction but I I certainly know it was [116:52] you who proed me so that I delivered the [116:55] stuff right and I greatly appreciate it [116:59] um well I think that kind of wraps up [117:01] most of the things that I was hoping [117:03] that we about today anything you'd like [117:06] to there's something behind you Paul can [117:08] you hear me yes okay I'm going to ask [117:11] one question um which you already [117:12] covered um it's fascinating that uh [117:16] David wheeler morce Morris wils and you [117:18] are all fellows and could you just talk [117:21] and give us a quick statement about how [117:23] it sounds like you thought that was [117:25] pretty cool can you just tell us you [117:26] know a little bit um think about [117:28] speaking to the audience at the fellows [117:30] and how how cool you think it is that [117:32] you are are part of a family line at [117:35] this point um [117:38] I mentioned earlier history and the [117:41] importance of history and I don't think [117:44] history is something dead it's part of [117:46] our world it's part of the way we [117:49] understand the world and so for that [117:52] reason I have known about the Computer [117:56] History Museum and its fellows for many [117:58] years because it's one of the things [118:00] I've been looking at I've been there [118:02] physically I've been there on the uh web [118:06] and I find it's it's really cool I mean [118:08] not only being a fellow there so having [118:11] been part of all of this and being [118:13] recognized to be part of all of this is [118:15] is is is very very exciting for me and [118:17] I'm very honored but I'm probably the [118:20] first third generation fellow [118:22] that is my advisor was a fellow and his [118:26] advisor was a fellow we're still a young [118:28] field uh so hopefully there will be many [118:31] more third Generations eventually but [118:34] but but that that that struck me as uh [118:37] as interesting and I actually went and I [118:40] read um a fair number of these short [118:44] stories that uh goes with the fellows [118:48] and in many cases I was sort of [118:49] wondering what else is there um I'm very [118:53] slow at um watching uh to watch movies [118:58] because they they they move fairly [119:00] slowly and I'm busy or I'm tired or [119:04] something so if there had been some [119:06] transcripts of uh their um presentations [119:11] that was linked from the the BIOS that [119:13] would have been really useful for me and [119:16] not everybody can do what I do is for [119:20] some of them I can sort of remember them [119:23] and uh they're real and the uh biography [119:27] is is something that prods memory and [119:30] that's nice but for others a little bit [119:34] more information the the the videos of [119:37] things like this will will help [119:39] transcripts if available will help [119:43] people that are [119:46] busy that's great that's all I have Paul [119:48] how about you and and of course I'm very [119:50] honored I think I said that but just [119:53] make sure why don't you start again just [119:55] give us that one last little quote very [119:58] honored yeah and and and of course if I [120:02] didn't say it already I am very honored [120:04] and uh this this is very important to me [120:07] thank you