Kernighan Credits Unix Rise to Thompson Genius, University Licensing
Lex Fridman
Unix conquered modern computing through Ken Thompson's singular programming ability and low-cost university source licenses rather than predictable market evolution or open-source planning.
AI-assisted summary of Brian Kernighan: UNIX, C, AWK, AMPL, and Go Programming | Lex Fridman Podcast #109 — original source. Check the original for full context.
Source published:
Key ideas
- Ken Thompson implemented the core components of UNIX—including a custom assembler, interactive text editor, hierarchical file system, and process manager—in bare-metal assembly on an abandoned DEC PDP-7 in just three weeks during the summer of 1969. (14:07)
- Although AT&T Unix was proprietary and patented, low-cost source-code licensing for universities seeded global adoption, directly paving the way for Berkeley Unix (BSD), the free software movement, and the modern Linux kernel. (25:56)
- Brian Kernighan warns that modern package ecosystems like npm and pip create massive security and reliability liabilities by encouraging developers to pull in opaque, sprawling dependency trees. (66:28)
- Kernighan argues that society does not need every individual to become a coder, but non-programmers must develop an intuitive understanding of basic computing abstractions to evaluate technology and automated decision-making critically. (92:54)
Detailed notes
## Background This interview was published on YouTube by Lex Fridman on July 18, 2020, as episode #109 of the Lex Fridman Podcast. The episode features Brian Kernighan, computer science professor at Princeton University, co-author of 'The C Programming Language' with Dennis Ritchie, co-creator of AWK, and co-designer of AMPL, discussing the history of UNIX, programming languages, and computing.
## TL;DR Brian Kernighan reflects on the genesis of UNIX and C at Bell Labs, crediting Ken Thompson's singular programming ability and the tight collaborative culture that enabled rapid innovation. He explores the trade-offs of language design across decades—from assembly and Fortran to AWK, C++, Rust, and Go—emphasizing why no single language can satisfy every computing need. Kernighan also shares insights from his work on AMPL, graph partitioning, and text editors, while weighing the evolution of Moore's law and the double-edged societal impacts of ubiquitous computing, data privacy, and AI.
## Atmosphere & style The conversation carries a warm, understated reverence, anchored by Kernighan's self-effacing humility and encyclopedic grasp of computing history. Fridman approaches the exchange with earnest fascination, prompting Kernighan to demystify legendary eras into relatable stories of physical terminal rooms, rapid prototyping, and pragmatic design choices. Listening feels like sitting in an intimate, master-level office hour where foundational milestones of computer science are treated not as grand inevitabilities, but as the joyful result of tight feedback loops, sharp constraints, and good fortune.
## Bulletin - [14:07](https://www.youtube.com/watch?v=O9upVbGSBFo&t=847s) Ken Thompson implemented the core components of UNIX—including a custom assembler, interactive text editor, hierarchical file system, and process manager—in bare-metal assembly on an abandoned DEC PDP-7 in just three weeks during the summer of 1969. - [25:56](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1556s) Although AT&T Unix was proprietary and patented, low-cost source-code licensing for universities seeded global adoption, directly paving the way for Berkeley Unix (BSD), the free software movement, and the modern Linux kernel. - [01:06:28](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3988s) Brian Kernighan warns that modern package ecosystems like npm and pip create massive security and reliability liabilities by encouraging developers to pull in opaque, sprawling dependency trees. - [01:32:54](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5574s) Kernighan argues that society does not need every individual to become a coder, but non-programmers must develop an intuitive understanding of basic computing abstractions to evaluate technology and automated decision-making critically.
## Key takeaways - [04:24](https://www.youtube.com/watch?v=O9upVbGSBFo&t=264s) The transition from batch processing with punch cards to interactive time-sharing radically compressed feedback loops and fundamentally altered how programmers worked. - [14:07](https://www.youtube.com/watch?v=O9upVbGSBFo&t=847s) Bell Labs withdrew from the overly complex Multics project in 1969, prompting Ken Thompson and Dennis Ritchie to pursue a lightweight, bottom-up computing environment. - [18:21](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1101s) Kernighan describes Ken Thompson as a programming 'singularity', attributing the foundational breakthroughs of UNIX largely to Thompson's extraordinary individual capability. - [21:26](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1286s) UNIX prioritized creating a productive community environment for programmers rather than solving a specialized corporate or laboratory computing task. - [29:46](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1786s) Severe hardware constraints on early minicomputers forced Unix developers to pursue elegant, unified abstractions, such as treating files and peripheral devices under a single read/write interface. - [35:18](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2118s) AWK was designed to automate common text processing patterns, implicitly handling file reading, record splitting, and pattern matching without boilerplate loops. - [42:35](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2555s) The evolution of text editors from paper-based line editors like ed to screen-oriented tools like vi was directly driven by the shift from mechanical teletypes to CRT terminals. - [51:04](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3064s) C succeeded as the premier systems programming language because it balanced hardware-level control and efficiency with structured programming abstractions. - [53:18](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3198s) The tight symbiotic relationship between C and UNIX generated a self-reinforcing adoption cycle, making utilities and operating systems mutually portable. - [56:28](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3388s) Kernighan emphasizes that instructional programming literature should teach using realistic, functional utilities rather than artificial, toy puzzles. - [58:44](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3524s) Go introduced language-level concurrency via goroutines and channels based on Tony Hoare's Communicating Sequential Processes (CSP), reflecting modern multicore realities. - [01:01:57](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3717s) Kernighan's benchmark of a 60-character line-wrapping text formatter revealed dramatic differences in implementation friction, ranging from under an hour in Lua to weeks in Haskell. - [01:08:16](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4096s) Functional programming concepts like first-class functions, recursion, and lambdas have steadily been absorbed into mainstream imperative languages. - [01:10:30](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4230s) AMPL decoupled mathematical optimization modeling from input data formats and underlying numerical solvers, enabling algebraic formulation of complex linear and non-linear problems. - [01:18:01](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4681s) The Kernighan–Lin heuristic was developed to tackle graph partitioning because enforcing equal-sized subset divisions transforms polynomial-time min-cut problems into NP-complete challenges. - [01:24:41](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5081s) Machine learning systems trained on historical data risk scaling and codifying past societal biases unless explicitly addressed. - [01:29:45](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5385s) Exponential hardware scaling faces immutable physical constraints at atomic dimensions, driving software paradigms toward multithreading and code generation. - [01:36:35](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5795s) Ubiquitous computing and digital networks have simultaneously lowered communication barriers and accelerated political polarization, tribalism, and misinformation.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=O9upVbGSBFo&t=0s) Introduction and Sponsor Announcements
Lex Fridman introduces Brian Kernighan, a professor of computer science at Princeton University and a foundational figure in the computing community. Alongside UNIX creators Ken Thompson and Dennis Ritchie at Bell Labs, Kernighan played an integral role in early UNIX culture and history. Beyond co-authoring the seminal book *The C Programming Language* with Ritchie, Kernighan has authored numerous texts including *The Practice of Programming*, *The Go Programming Language*, and his memoir *UNIX: A History and a Memoir*. He also co-created the AWK pattern-scanning language and co-designed the AMPL algebraic modeling language, a tool Fridman notes he has personally used extensively for large-scale optimization. Fridman reflects that despite such extensive accomplishments, Kernighan remains remarkably humble and gracious: “I think I can keep going for a long time with his creations and accomplishments which is funny because given all that he's one of the most humble and kind people I've spoken to on this podcast.”
Fridman then covers the episode's sponsors, Eight Sleep and Raycon. He discusses the Eight Sleep Pod Pro mattress, highlighting its ability to cool down to 65 degrees, its dual-zone temperature regulation, and its biometric sensors tracking resting heart rate, heart rate variability, and respiratory rate. Fridman jokes about the independent side-temperature controls: “I don't happen to have one but the Eight Sleep app reminds me that I should probably get on that so ladies if a temperature controlled mattress isn't a good reason to apply I don't know what is.” He also highlights Raycon earbuds, describing how he wears them while running, exercising, and playing brown noise to concentrate during deep work, while listening to Santana’s guitar track "Europa" during the recording.
- Eight Sleep Pod Pro offers biometric tracking (HR, HRV, respiratory rate) and app-controlled cooling down to 65°F. - Raycon wireless earbuds feature six hours of battery life and easy Bluetooth pairing. - Fridman jokes that if Richard Feynman were alive today, he would be listening to *The Joe Rogan Experience* on Raycons.
---
[04:24](https://www.youtube.com/watch?v=O9upVbGSBFo&t=264s) The Shift from Batch Processing to Time-Sharing
Fridman opens the discussion by asking about the birth of UNIX roughly fifty years earlier in 1969. Kernighan points out that understanding UNIX requires tracing back an almost infinite regress into previous computing paradigms, beginning with the transition from batch systems to time-sharing. In the 1950s and early 1960s, computers were physically colossal machines housed in large dedicated rooms, yet possessed minuscule processing power compared to modern standards. Users interacted with them asynchronously through punch card decks. A programmer would punch out their code, hand the deck over a physical counter to a machine operator, and wait hours only to receive a printout indicating a syntax mistake, demanding another tedious cycle.
Time-sharing revolutionized this workflow by connecting multiple users simultaneously to the central computer via terminals resembling electric typewriters. Instead of monopolizing the central processor for one batch job at a time, the operating system rapidly cycled through all active terminals, allocating each user a tiny quantum of CPU time. Whenever a user typed a character, the system woke up, registered the keystroke into a buffer, and promptly returned to servicing other tasks. As Kernighan summarizes the core user experience: “And hence time sharing that is sharing the computing time resource of the computer among a number of people who are doing it without the individual people being aware that there's others.”
```mermaid flowchart TD accTitle: Evolution of Computing Paradigms accDescr: Flow diagram contrasting 1950s batch processing with 1960s interactive time-sharing.
subgraph Batch["Batch Processing (1950s-1960s)"] A["Programmer Punches Cards"] --> B["Operator at Counter"] B --> C["Mainframe Batch Run"] C --> D["Printed Error Report (Hours Later)"] end
subgraph TimeSharing["Time-Sharing (CTSS / Multics / UNIX)"] E["Teletype / Electric Typewriter"] -->|"Keystroke"| F["OS Round-Robin Scheduler"] F --> G["Dedicated Slice of Central CPU"] G -->|"Interactive Illusion"| E end ```
---
[07:18](https://www.youtube.com/watch?v=O9upVbGSBFo&t=438s) CTSS and the Multics Vision of a Computing Utility
Kernighan describes the Compatible Time-Sharing System (CTSS), developed at MIT under the leadership of Fernando Corbató ("Corby"), as arguably the first true realization of this model. Kernighan experienced CTSS firsthand during a formative summer in Cambridge in 1966. The system ran on a modified IBM 7094 mainframe equipped with two 32,768-word banks of 36-bit core memory—roughly 300 kilobytes total, which was considered an enormous and expensive amount of memory for its era. When Fridman inquires about the algorithmic complexity of early schedulers, Kernighan explains that the baseline approach relied on straightforward round-robin queueing, adapting dynamically depending on whether a task was an interactive text edit or a heavy compiler job.
CTSS directly inspired Multics (Multiplexed Information and Computing Service), a collaborative project among Bell Labs, MIT, and General Electric intended to scale time-sharing into a general-purpose, commercial-grade infrastructure. Multics envisioned computing as a public utility analogous to the electrical grid, anticipating the core concepts of modern cloud infrastructure fifty years ahead of its time. When Fridman asks whether researchers back then foresaw the ubiquity of contemporary computing, Kernighan clarifies the scope of their imagination: “I'm betting that they didn't have the same view of computing for the masses let's call it the idea that you know your grandmother would be shopping on Amazon I don't think that was part of it but if your grandmother were a programmer it might be very easy for her to go and use this kind of utility.”
- **CTSS Architecture**: Hosted on an IBM 7094 with two banks of 32K 36-bit words (approximately 150 KB per bank, ~300 KB combined). - **Key Figures**: Fernando Corbató ("Corby") at MIT pioneered CTSS and Multics time-sharing concepts. - **The Utility Model**: Multics conceived computing as an "information utility"—a shared resource accessed from remote wall jacks, laying the conceptual groundwork for cloud computing.
[10:51](https://www.youtube.com/watch?v=O9upVbGSBFo&t=651s) Early Computing Dreams and Arriving at Bell Labs
When asked whether he foresaw the future of modern computing during his early days in Cambridge, Brian Kernighan offers a blunt, amused assessment: “Short answer: absolutely not. I had no clue.” Rather than harboring a grand prophetic vision, he viewed his summer internship as simply a dream job where he relished the work, the fine summer weather, and the stimulating company of brilliant colleagues. That formative experience set off a chain reaction of good fortune, directly helping him secure a summer internship in 1966 at AT&T Bell Laboratories.
Bell Labs was a legendary research powerhouse physically distributed across New Jersey. Its flagship location sat in Murray Hill, straddling the border between the small suburban towns of New Providence and Berkeley Heights, about 15 to 20 miles west of New York City. The Murray Hill campus housed roughly 3,000 to 4,000 employees, an extraordinary proportion of whom held PhDs. While historically centered on the physical sciences—advancing chemistry, materials science, and physics—the institution possessed world-class mathematical talent and an accelerating appetite for computation. Researchers increasingly realized they could model experiments digitally instead of building physical laboratories.
- **Primary location**: Murray Hill, New Jersey (spanning Berkeley Heights and New Providence). - **Staffing profile**: 3,000 to 4,000 people, heavily weighted toward PhDs in physics, chemistry, materials, and mathematics. - **Corporate parentage**: Bell Labs operated as the research and development engine for AT&T, which held a regulated monopoly over American telephone service. - **Mission mandate**: While AT&T was tasked with providing universal phone service across the nation, Bell Labs was funded to relentlessly improve that service through foundational research, yielding breakthroughs such as the transistor, fiber-optic cables, and microwave transmission systems.
---
[14:07](https://www.youtube.com/watch?v=O9upVbGSBFo&t=847s) The Collapse of Multics and the Genesis of UNIX
During the late 1960s, Bell Labs participated in a joint project alongside MIT and General Electric to create Multics (Multiplexed Information and Computing Service). Conceived as an ambitious, centralized "information utility," Multics was laden with brilliant conceptual ideas, but it suffered from staggering complexity, runaway development costs, and severe delivery delays. By early 1969, management at Bell Labs concluded the platform would not deliver on a reasonable timescale and pulled out of the consortium.
The sudden cancellation stranded researchers who had developed a taste for sophisticated interactive computing. Deprived of a comfortable time-sharing system, team members began designing a replacement on paper, striving to merge the fluidity of the earlier Compatible Time-Sharing System (CTSS) with the architectural lessons learned from Multics. Concurrently, Ken Thompson located a largely neglected Digital Equipment Corporation (DEC) PDP-7 minicomputer and used it to test experimental file-system designs.
```mermaid flowchart TD accTitle: The Path from Multics to UNIX accDescr: Diagram illustrating how the withdrawal from Multics led directly to Ken Thompson's three-week sprint to build UNIX on a PDP-7.
subgraph MulticsEra["Multics Project (Late 1960s)"] M1["MIT + Bell Labs + General Electric"] M2["Ambitious 'Information Utility'"] M1 --- M2 end
subgraph TheBreak["1969 Bell Labs Withdrawal"] B1["High Costs & Delivery Delays"] B2["Researchers Left Without an Interactive OS"] MulticsEra --> B1 B1 --> B2 end
subgraph UnixGenesis["Birth of UNIX (Summer 1969)"] U1["Paper System Architecture Designs"] U2["Ken Thompson Explores File Systems on a PDP-7"] U3["Thompson's 3-Week Coding Sprint"] B2 --> U1 B2 --> U2 U1 --> U3 U2 --> U3 U3 --> OS["First UNIX Operating System"] end ```
The pivotal moment arrived during the summer of 1969 when Ken Thompson’s wife traveled to California for three weeks with their one-year-old son. Working alone during that brief window, Thompson wrote the core components of what would become the UNIX operating system. As Kernighan wryly notes about that burst of raw output, “Software productivity was good in those days.”
---
[15:49](https://www.youtube.com/watch?v=O9upVbGSBFo&t=949s) Building an Operating System on a DEC PDP-7 in Assembly
The hardware hosting this milestone was a DEC PDP-7, a minicomputer introduced in 1964 that was already verging on obsolescence by 1969. Minicomputers of that era were modest compared to room-sized mainframes: the PDP-7 typically possessed around 16 kilowords of memory and operated at relatively low clock speeds. While out of reach for a private individual at a price tag hovering near $100,000, it was inexpensive enough for small institutional teams to commandeer without upper-management oversight.
Kernighan clarifies that he had no role in writing this foundational kernel code, emphasizing that he has never written operating system code himself. Operating systems, he explains, fundamentally consist of routines to run processes, persist data reliably across reboots, and manage memory. Because there was no existing software ecosystem for the abandoned PDP-7, Thompson had to build every essential piece from bare metal up:
```mermaid flowchart LR accTitle: PDP-7 Bare Metal UNIX Architecture accDescr: Flowchart showing the components Ken Thompson implemented in assembly language on the PDP-7 to establish UNIX.
subgraph CoreOS["UNIX Kernel Essentials"] FS["File System Management"] Exec["Process Loader & Execution Dispatcher"] end
subgraph Toolchain["Userland Assembly Toolchain"] ASM["Custom PDP-7 Assembler"] ED["Text Editor"] end
ASM --> ED ED --> FS FS --> Exec ```
- **Assembly language origin**: The original 1969 UNIX implementation was written entirely in native PDP-7 assembly language; UNIX and its tools remained in assembly until rewritten in C around 1973–1974. - **Absence of tooling**: Early assembly development provided zero guard rails, run-time checks, or modern symbolic debuggers. When machine code failed, diagnosis required meticulous manual inspection. - **Essential components implemented by Thompson**: - A custom PDP-7 assembler to assemble code directly on the machine. - An interactive text editor to write and alter source files. - A hierarchical file system storing persistent directories and byte sequences. - A process manager to load executables from disk into memory, transfer CPU control to them, and cleanly recover control upon exit.
---
[18:21](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1101s) Ken Thompson as a Programming Singularity
Reflecting on the psychological and technical strain of writing an entire OS in assembly language, Kernighan acknowledges that the task would appear insurmountable to modern engineers. The smaller overall scale of computing in 1969 kept the big picture manageable, but overcoming the lack of tooling demanded an extraordinary mind. Kernighan highlights the immense gulf in individual programming talent, describing Thompson in singular terms: “Realistically, there's an enormous variation in the capabilities of programmers, and Ken Thompson, who did that first one, is kind of the singularity in my experience of programmers.” He adds that compared to Thompson, other skilled programmers are “several leagues removed.”
Lex Fridman remarks on the serendipity of history—how the alignment of a unique talent, a specific point in computer evolution, and a quiet three-week window when a family traveled out of town combined to create a system whose descendants now dominate the world's infrastructure. When Fridman asks what it feels like to look back on this tiny seed overtaking the digital globe, Kernighan admits that the modern footprint of UNIX-like architectures could never have been anticipated.
> “And you asked earlier about predictions—the answer is no, there's no way you could predict that kind of evolution, and I don't know whether it was inevitable or just a whole sequence of blind luck; I suspect more the latter.” > — *Brian Kernighan*
Kernighan insists that while Dennis Ritchie and a host of brilliant colleagues at Bell Labs made monumental contributions to refine and transform the system, the foundational credit belongs to Ken Thompson: “If you had to pick a single person, that would be Ken.” He concludes that the sustained creativity that followed was made possible by the rare, collaborative culture fostered within Bell Labs during that era.
[21:26](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1286s) The Culture and Philosophy of Bell Labs Unix
Brian Kernighan describes Bell Labs as an extraordinary workplace defined by brilliant colleagues and an open, cooperative culture. Researchers could walk into anyone's office to hash out complex technical problems. It was also an environment full of playful mischief, where researchers took delight in “tweaking the bureaucracy” whenever possible. Asked by Lex Fridman about the core philosophy that governed Unix from its beginnings and across the decades, Kernighan emphasizes that it was engineered strictly to serve developers rather than to solve a single specialized task. Although Unix ended up being used heavily for word processing, laboratory apparatus control, and serving as a front end for massive legacy mainframes, none of those were its explicit design target.
Kernighan points out that the real objective, as Dennis Ritchie observed at the conclusion of Kernighan's memoir, was the formation of a programmer community. Because writing software on Unix was unusually painless and productive, programmers built useful tools, which other developers adopted and improved upon, fostering a reinforcing community dynamic. Kernighan highlights Ritchie's insight:
> “From his standpoint the real goal was to create a community where people could work as programmers on a system.”
- Unix was widely adopted for tasks it was never explicitly built for, including lab device control, front-end interfacing for large mainframes, and text/word processing. - The overarching technical priority was reducing friction for software developers, creating a virtuous feedback loop of tool building.
```mermaid flowchart LR accTitle: The Unix Virtuous Circle accDescr: Diagram showing how a friction-free environment fueled developer tools and community growth. subgraph Environment ["Bell Labs Core"] A["Low-Friction System"] --> B["Fast Development"] end subgraph Community ["Ecosystem"] B --> C["Useful Programmer Tools"] C --> D["Adopted by Colleagues"] D -->|"Feedback & ideas"| A end ```
---
[23:40](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1420s) Rapid Feedback Loops and Physical Collaboration
Writing code in the early Unix period was, in Kernighan's words, “a blast.” He self-deprecatingly claims he is “not a terribly good programmer,” but stresses that the computing frontier back then was packed with low-hanging fruit—problems nobody had ever addressed on interactive computers. With responsive machines, sharp utilities, and outstanding colleagues, development cycles moved at breakneck speed. A developer could conceive a feature in the morning, hack together a prototype that evening, and receive candid evaluations the following morning: users would praise the concept while bluntly pointing out every flaw. That rapid, unvarnished feedback loop was immensely rewarding because programming is fundamentally about puzzle-solving, and having real people use what you built—even when they complained—made the work exciting.
Lex Fridman asks how that feedback was mediated before the internet existed. Kernighan clarifies that Bell Labs was largely housed under one enormous roof. The Unix team was concentrated across just two or three hallways, anchored by a shared room measuring roughly 50 feet by 50 feet. That communal hub housed terminals and a coffee machine where staff regularly hung out. Although internal electronic mail existed, all users shared a single central machine, eliminating any requirement for external computer networks to maintain instantaneous, tight communication.
Kernighan reflects on the role of physical co-location:
> “Programming itself is fun it's puzzle solving in a variety of ways but I think it's even more fun when you do something that somebody else then uses even if they whine about it not working the fact that they used it is as part of the reward mechanism.”
- The rapid feedback loop allowed developers to conceive an idea in the morning, prototype it by evening, and receive colleague feedback the very next day. - Team interactions were predominantly physical and face-to-face inside Bell Labs' shared 50x50-foot terminal/coffee room. - Early Unix email operated entirely local to a single shared computer system, requiring no internet connectivity.
---
[25:56](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1556s) Bell Labs in History: Survivor Bias and Institutional Influence
Reflecting on Fridman's suggestion that modern computing might not exist without Bell Labs, Kernighan cautions against historical survivor bias. Bell Labs was undeniably special, but other institutions made parallel, earth-shaking breakthroughs during the same era. He singles out Xerox PARC for pioneering many technologies taken for granted in contemporary computing, even though its corporate parent company failed to commercialize them as successfully. He also points to university computer science powerhouses like MIT as vital sources of innovation.
When Fridman suggests that Unix ended up as open-source software because AT&T was a regulated telephone monopoly constrained from selling software, Kernighan corrects the record: Unix was never open source in the modern sense. It was proprietary, patented, and licensed under strict agreements. However, AT&T licensed Unix source code to educational institutions for nominal administrative fees. This allowed generations of university students and professors to study, run, and modify the operating system internals. That widespread academic access eventually inspired Berkeley Unix (BSD)—driven by figures like Bill Joy—to systematically rewrite AT&T components until the codebase became fully independent, despite prolonged legal disputes throughout the late 1980s and early 1990s.
Kernighan emphasizes the direct continuity leading to modern Linux:
> “I think that's a mischaracterization in the sense it absolutely was not open source it was very definitely proprietary licensed but it was licensed freely to universities in source code form for many years and because of that generations of university students and their faculty people grew up knowing about Unix.”
- Xerox PARC and MIT are highlighted as equally groundbreaking research centers whose discoveries shaped modern computing. - AT&T Unix remained strictly proprietary, but broad, inexpensive university licensing gave it the operational feel of an open system long before open-source licensing models existed. - Berkeley's BSD effort, including contributions from Bill Joy, gradually stripped out AT&T proprietary code through clean-room reimplementation. - The culture of Unix knowledge paved the way for Richard Stallman's late-1980s free software efforts and Linus Torvalds' 1991 creation of the Linux kernel.
---
[29:46](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1786s) Constraints, Efficiency, and Unified Abstractions
Fridman asks why Unix proved to be so extraordinarily efficient and robust, wondering whether that was a deliberate byproduct of prioritizing the programmer experience. Kernighan explains that the early hardware constraints forced minimalism upon the developers. Ken Thompson and Dennis Ritchie operated on severely limited minicomputers with tiny memories and slow clock speeds, making bloated, convoluted designs physically impossible. The scarcity of hardware resources compelled them to search for overarching generalizations rather than crafting one-off special cases for individual features.
The defining example of this philosophy is the Unix file system. By establishing a simple, uniform read/write interface for files, the designers realized that peripheral hardware devices could be treated identically to disk files. Later operating systems pushed this uniform abstraction even further: Unix began treating active processes as directory structures (such as `/proc`), and Bell Labs' successor system, Plan 9, structured nearly all local and remote operating system services as synthesized file systems adhering to the exact same file API.
Kernighan summarizes how foundational design abstractions reduce system complexity:
> “Finding the right model of how to do something means that an awful lot of things become simpler and it means therefore that more people can do useful interesting things with them without him to think as hard about it.”
- Severe hardware limitations on early minicomputers prevented bloated code and enforced mechanical minimalism. - A single generalized file system abstraction (open, read, write, close) served both physical disk storage and hardware peripheral devices. - Bell Labs' later Plan 9 operating system carried this philosophy to its logical conclusion, presenting diverse computing resources across network nodes as unified file systems.
[32:01](https://www.youtube.com/watch?v=O9upVbGSBFo&t=1921s) Programming as Art, Science, and Engineering
Lex Fridman remarks that despite Brian Kernighan's understated posture, he radiates a genuine love for programming, and asks whether Kernighan views programming as more of an art or a science—creativity versus rigor. Kernighan answers that it is an amalgam of art, science, and engineering:
> “I think it's some of each it's some combination some of the art is figuring out what it is that did you really want to do what should that program be what would make a good program and that's some understanding of what the task is what the people who might use this program want and I think that's that's art in many respects.”
The scientific aspect, Kernighan explains, lies in figuring out how to do it well using formal computer science principles—selecting correct algorithms and data structures, and ensuring scalability by avoiding quadratic algorithms when a linear approach is required. However, he emphasizes that programming is fundamentally an engineering discipline. Engineering departs from pure science because it requires navigating practical constraints: determining not just an optimal algorithm in the abstract, but the most appropriate algorithm given limited time to compute, limited time to write code, and future maintenance realities regarding who will maintain the software later. A scientist might push those practicalities over the horizon, and an artist would disregard them entirely, but an engineer must confront them directly.
When asked about his personal workflow—whether he sketches out software engineering designs on paper first or dives into iterative coding—Kernighan describes an informal, incremental approach. He notes that he no longer writes large programs; it has been a long time since he wrote a program exceeding a few hundred lines. Most of his current programming consists of: - Small experimental programs to satisfy personal curiosity. - Demonstrations and examples prepared for his university classes. - Exploratory data analysis scripts to investigate new datasets.
For exploratory data analysis, Kernighan often relies on simple existing command-line tools to count elements, or writes two- to three-line AWK scripts to inspect slices of data. When a project grows larger, up to a few hundred lines, he turns to Python because it scales better for that size.
---
[35:18](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2118s) The Design and Elegance of AWK
Lex asks Kernighan to define AWK and explain why it remains widely used for data exploration more than four decades after its inception. Kernighan explains that AWK is a scripting language developed in the late 1970s by Alfred Aho, Peter Weinberger, and himself. It was designed to make quick-and-dirty tasks trivial—such as counting records, rearranging text fields, or extracting summary information from text files.
Kernighan reflects on the unexpected longevity of the tool:
> “Well this is paternal interest I guess but I think in terms of programming languages you get the most bang for the buck by learning awk and it doesn't scale the big programs but it does pretty pretty darn well on these little things where you just want to see all the something's in something so yeah I find I probably write more awk than anything.”
When Fridman asks what brings Kernighan joy about using AWK, Kernighan points directly to its thoughtful default behaviors. AWK automatically handles what would otherwise require a quadruply nested loop: iterating through every input file, reading every line, testing each line against pattern regular expressions, and executing the corresponding action whenever a pattern matches. In addition, AWK automatically splits lines into fields delimited by whitespace and tracks metadata behind the scenes, such as line numbers and field counts. A task requiring 5, 10, or 20 lines in Python collapses into a single one- or two-line command in AWK, allowing programmers to execute it directly inside the terminal shell without switching tools.
```mermaid flowchart TD accTitle: AWK Implicit Execution Loop accDescr: Diagram showing how AWK automatically iterates over files, lines, and patterns without manual loop boilerplate.
subgraph InputProcessing["Input Processing"] A["Input Files"] --> B["Iterate Files"] B --> C["Read Line by Line"] C --> D["Split into Fields & Update Metadata"] end
subgraph PatternAction["Pattern Matching Engine"] D --> E{"Pattern Matches?"} E -- "Yes" --> F["Execute Bound Action"] E -- "No" --> G["Next Pattern / Next Line"] F --> G end ```
---
[38:40](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2320s) Command-Line Philosophy: grep, Windows, and WSL
Lex asks about other beloved shell commands, noting that `grep` acts like a simpler sibling to AWK. Kernighan agrees, noting that `grep` operates under the exact same pattern-action paradigm: it loops over files and lines, matches against a regular expression pattern, and performs a single fixed action—printing matching lines. In fact, one can implement `grep` as a one-line AWK script. Kernighan admits that he uses `grep` more than almost any other utility simply because it is so direct and natural.
Lex questions why mainstream graphical operating systems like Windows did not natively adopt this command-line search paradigm. Kernighan traces this divide back through operating system history:
> “Windows came from ms-dos ms-dos was a pretty pathetic operating system although common own and you know unbounded lis large number of machines but somewhere in roughly the 90s windows became a graphical system and I think Microsoft spent a lot of their energy on making that graphical interface what it is and that's a different model of computing it's a model of computing that where you point and click and sort of experiment with menus it's a model of computing worked right rather well for people who are not programmers just want to get something done whereas teaching something like the command line to non-programmers turns out just sometimes be an uphill struggle and so I think Microsoft probably was right and what they did.”
Lex brings up the ability to run these UNIX utilities natively on Windows via WSL (Windows Subsystem for Linux), jokingly musing over its pronunciation ("whistle"), which Kernighan finds amusing. Kernighan observes that bridging UNIX tooling to Windows has a long lineage, highlighting Cygwin as a project that has made favorite UNIX and Linux utilities run cleanly on Windows for over twenty years. Kernighan still runs Cygwin routinely on his single remaining Windows machine for batch and command-line computing, noting that the native Windows command equivalents remain unfamiliar to him. Lex adds that being able to run Bash scripts on Windows via WSL has completely transformed his workflow.
- AWK was created by Alfred Aho, Peter Weinberger, and Brian Kernighan in the late 1970s. - `grep` functions as a specialized, single-pattern/single-action subset of the AWK execution paradigm. - Cygwin has provided a POSIX/UNIX-like environment on Windows for more than two decades.
---
[42:03](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2523s) Personal Hardware and Computing Setup
Lex asks Kernighan to detail his ideal programming environment, pressing him on his favorite computer hardware, operating system, keyboard, and text editor. Kernighan pushes back gently on the framing, stating that "perfect is too strong a word."
He explains his practical daily setup: - **Machine:** A 13-inch MacBook Air. - **Form factor considerations:** He favors it because it strikes an ideal balance—it is lightweight and portable, packs enough computing horsepower for his tasks, provides an adequate display size, and has a comfortable keyboard. - **Workflow:** He conducts the vast majority of his everyday computing directly on that single laptop.
[42:35](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2555s) The Lineage of Text Editors: From Paper Terminals to Sam
Brian Kernighan notes that while he has a large iMac in his office that he fires up when he needs extra screen real estate, his daily driver relies on a specific set of tools. When asked what text editor he primarily uses, Kernighan names **Sam**, a multi-file text editor written by Rob Pike at Bell Labs. Lex Fridman asks whether Sam predates vi. Kernighan explains that Sam actually post-dates both vi and Emacs; it was directly informed by Pike's deep experience with the Unix line editor `ed` and Bill Joy's `vi`.
Fridman sheepishly admits his own allegiance—"I use Emacs, I'm sorry to say so... I'm sorry to come out with that"—and asks Kernighan to walk through the lineage of editors and their historical interplay. Kernighan traces text editors back to the early time-sharing era. On MIT's Compatible Time-Sharing System (CTSS), an early editor (possibly called `edit`) allowed users to enter and manipulate files. At Bell Labs, Ken Thompson wrote an editor called **QED**, which was exceptionally powerful.
Crucially, these primitive tools operated in an era long before mice, graphical displays, or on-screen cursors existed. Programs ran on teletype terminals that printed directly onto continuous rolls of real paper:
> “And that meant that if you changed a line, you had to print that line, using up another line of paper, to see what changed.”
When Unix was first being developed, Ken Thompson stripped QED down significantly to create `ed`, the lean, original line-oriented Unix editor. In `ed`, text was addressed purely by line numbers (from line 1 to the end of the file). Users manipulated blocks of text via cryptic single-character commands—printing ranges, appending, deleting, or running global substitution regular expressions—all executed blindly onto physical paper.
The breakthrough occurred when CRT (Cathode-Ray Tube) terminals replaced teletypes in the 1970s. For the first time, software could take advantage of cursor addressing to move arbitrarily across a persistent video screen without consuming sheets of paper. Bill Joy wrote `vi` at UC Berkeley in the late 1970s to fully exploit cursor control. Around the same era, Emacs emerged in the Lisp community. Kernighan mentions that although he rarely touches `ed` anymore, he still uses `vi` occasionally, while leaning on `Sam` as his primary editor whenever possible.
```mermaid flowchart TD accTitle: Evolution of Early Text Editors accDescr: Diagram tracing text editors from early time-sharing paper systems through CRT-based visual editors. subgraph PaperEra["Paper Terminal Era (Line-Oriented)"] CTSS["CTSS 'edit'"] QED["Ken Thompson's QED"] ED["Ken Thompson's 'ed' (Original Unix)"] CTSS -.-> QED QED -->|"stripped way down"| ED end
subgraph CRTEra["CRT Display Era (Screen & Cursor)"] VI["Bill Joy's vi (Late 1970s)"] EMACS["Emacs (Late 1970s)"] SAM["Rob Pike's Sam (Bell Labs)"] ED -->|"influenced"| VI ED -->|"influenced"| SAM VI -->|"influenced"| SAM end ```
- **Sam availability**: Maintained by enthusiasts, Sam is derived from the Plan 9 operating system distribution and can be compiled on modern Unix-like systems. - **Editor culture**: Fridman quips that one's primary programming tools feel like an indelible religious heritage: "I think it's like what religion were you brought up with." Though Fridman does his day-to-day work in C, C++, and Python, his foundational "religious upbringing" remains rooted in Lisp and Emacs.
---
[46:39](https://www.youtube.com/watch?v=O9upVbGSBFo&t=2799s) The History of Programming Languages: From Machine Ciphers to High-Level Abstractions
Lex Fridman asks Kernighan to undertake an ambitious challenge: deliver a concise history of programming languages from his vantage point. Kernighan charts this evolution starting in the late 1940s, when computers had to be addressed by raw binary numbers via physical console toggles or punched paper tape—a process he describes as "extremely tedious, awful."
The first evolutionary leap was the invention of crude assembly languages in the late 1940s and early 1950s. Assemblers substituted human-readable mnemonics (like `ADD`) for binary opcodes and automated the grueling clerical labor of mapping memory locations to symbolic labels. Kernighan points out a recent news item: the passing of Tony Brooker, who developed Manchester Mark 1's *Autocode*—an early step above assembly that replaced Alan Turing's peculiar system of inputting binary patterns backwards to match hardware mechanics. However, early assembly code was tied one-to-one to machine architecture:
> “They have, exactly in their simplest form at least, one assembly language instruction per instruction in the machine's repertoire, and so you have to know the machine intimately to be able to write programs in it.”
If a lab acquired a different architecture—such as moving from the EDSAC to an IBM 704 or 7090—every program had to be scrapped and rewritten from scratch.
By the late 1950s, computer scientists realized they could lift the level of abstraction again, giving rise to high-level, domain-specific compiled languages: 1. **Fortran (Formula Translation)**: Developed at IBM to simplify scientific, numerical, and engineering computation. 2. **COBOL (Common Business-Oriented Language)**: Spearheaded by Grace Hopper and committee efforts to handle enterprise data and business workflows. 3. **ALGOL**: Designed to formally express algorithmic computations, establishing structured control flow patterns. 4. **BASIC**: Introduced slightly later to make computing accessible to non-specialists and students.
These languages represented a watershed moment because they decoupled source code from physical machine architectures. As long as a target architecture had an appropriate compiler, the code could run anywhere. Kernighan stresses that this shift was profoundly democratizing:
> “It meant you only had to write the program once, which is very important, and it meant that you could, in fact, if you were a random engineer, physicist, whatever, you could write that program yourself; you didn't have to hire a programmer to do it for you.”
---
[51:04](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3064s) Systems Programming, the Emergence of C, and the Scale Problem
During the late 1960s and early 1970s, the computing industry encountered an acute architectural void: high-level languages like Fortran and COBOL were poorly suited for systems programming. System programs—such as compilers, assemblers, text editors, and operating system kernels—required low-level machine control, tight memory management, bit-level data manipulation, and explicit access to runtime processes.
While many computer scientists pursued systems programming designs during that era, Kernighan notes that the C programming language stands out as the ultimate survivor. C struck an effective balance: it provided abstractions for structured programming and expressive data types while granting developers direct, disciplined access to the underlying machine hardware.
As software projects ballooned into hundreds of thousands of lines of code throughout the late 1970s and 1980s, developers ran headlong into the problem of scale:
> “As you write programs in a language like C, at some point scale gets to you, and it's too hard to keep track of the pieces, and there's no guardrails or training wheels or something like that to prevent you from doing bad things.”
To handle this complexity, object-oriented languages gained traction, most notably Bjarne Stroustrup's C++, which grew directly out of Bell Labs' C tradition to add encapsulation and class abstractions. Kernighan highlights the broader landscape that followed: - **Parallel Functional Track**: Functional paradigms descended from John McCarthy's Lisp. - **Modern Proliferation**: The explosion of general-purpose platforms like Java and web-centric languages like JavaScript. - **Contemporary Systems Languages**: Newer languages like Rust, which adopt modern safety mechanics to prevent memory corruption while retaining low-level performance.
Turning to Kernighan's iconic status as the co-author of *The C Programming Language* (with Dennis Ritchie), Fridman asks him to identify the core reason for C's enduring survival and influence. Kernighan identifies its central virtue as a rare, pragmatic design equilibrium:
> “I think it found a sweet spot of expressiveness, so you can write things in a pretty natural way.”
[53:18](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3198s) The Synergy of C, UNIX, and Writing the Definitive Book
Brian Kernighan explains that the enduring power of the C programming language came from combining expressiveness with raw efficiency. Looking back nearly fifty years—spanning four or five decades of Moore's law—efficiency was vital because hardware was vastly weaker than it is today. C’s fortunes were also tied directly to its native environment: UNIX. Because UNIX itself and nearly all of its supporting tools were implemented in C, any program written in the language became inherently portable across every computer capable of running UNIX. This created a powerful positive feedback loop where the language, the operating system, and the tooling reinforced one another.
```mermaid flowchart LR accTitle: C and UNIX Positive Feedback Loop accDescr: Diagram showing how C's design and UNIX's portability reinforced one another. subgraph Language ["Language Design"] E["Expressiveness & Efficiency"] C["C Programming Language"] E --> C end subgraph Platform ["Ecosystem Adoption"] U["UNIX Operating System & Tools"] P["Cross-Platform Portability"] C -->|"Used to write"| U U -->|"Runs on diverse hardware"| P P -->|"Reinforces demand"| C end ```
Lex Fridman asks Kernighan what it took to produce *The C Programming Language* (co-authored with Dennis Ritchie), noting that it became perhaps the definitive programming book in computer history—both popularizing C and setting the universal standard for how it should be written. Asked whether they harbored grand ambitions of that scale, Kernighan laughs off the suggestion: “Dennis and I wrote the book in 1977... and at that point UNIX was starting to spread I don't know how many there were but it would be dozens to hundreds of UNIX systems.” He attributes their success to an accident of skill, timing, and luck. C was gaining ground on non-UNIX platforms, Bell Labs was the sole authoritative source, and Dennis Ritchie had already authored a magnificent reference manual. Kernighan jokingly recalls that he simply “twisted his arm until he agreed to write a book,” noting the distinct advantage of being first to set the benchmark.
- In their division of labor, Ritchie wrote the entire reference manual while Kernighan took on the expository material, refining the text through constant back-and-forth iteration. - Kernighan describes Ritchie’s writing as authoritative and “crystal-clear prose.”
[56:28](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3388s) The Pedagogical Philosophy of Realistic Examples
Lex shifts to Kernighan's pioneering role in introducing the iconic `"hello, world"` test program, musing that centuries from now, an alien civilization discovering a half-broken human robot would likely find it communicating via `"hello, world"`. In response to what makes code examples truly resonate, Kernighan emphasizes that sample programs must be genuinely representative of real problems developers want to solve. Rather than constructing artificial toy syntax puzzles, the examples in the C book mirrored everyday UNIX utilities: reading an input stream and echoing it (like `cp`), or inspecting text to filter lines (like `grep`).
Kernighan criticizes modern instructional programming books for divorcing syntax from utility. He notes that seeing an example merely showing how to add three numbers together fails to teach how to ingest those numbers into the machine, transform them meaningfully, and format the output cleanly: “I think a good example will tell you how to do something and it will be representative of you might not want to do exactly that but you will want to do something that's at least in that same general vein.” By giving readers immediately practical building blocks centered on reading, transforming, and writing text, developers can intuitively adapt the patterns to their own tasks.
[58:44](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3524s) The Go Language and the Evolution of Concurrency
The discussion shifts to modern languages, with Lex mentioning his interest in Go, Rust, and Julia despite never having used Go during his time at Google. Kernighan remarks that Go shares direct lineage with Bell Labs through co-creators Ken Thompson and Rob Pike, alongside Robert Griesemer, who brought the European computer science tradition from Niklaus Wirth’s school at ETH Zurich. Often labeled as a "C for the 21st century," Go retains familiar C-like syntax and light data structures while introducing modern safety and ergonomics.
```mermaid flowchart TD accTitle: Lineage and Concurrency Model of the Go Language accDescr: Diagram tracing Go's influences from Bell Labs and ETH Zurich to its concurrency model. subgraph Influences ["Design Influences"] BL["Bell Labs: Ken Thompson & Rob Pike"] ETH["ETH Zurich: Robert Griesemer"] end subgraph Core ["Go Language"] CStyle["C-like Syntax & Data Structuring"] CSP["Communicating Sequential Processes (Tony Hoare)"] BL --> CStyle ETH --> CStyle CSP --> GR["Goroutines & Channels"] CStyle --> Go["Go Language"] GR --> Go end ```
Kernighan—who co-authored *The Go Programming Language* with Alan Donovan (whom he credits with doing roughly 90% of the book's heavy lifting)—points out that Go’s crowning achievement is its concurrency model: “Go provides a very nice model of concurrency it's basically the cooperating communicating sequential processes that Tony Hoare set forth I don't know 40-plus years ago and go routines are to my mind a very natural way to talk about parallel computation.” When Lex asks if early C and UNIX pioneers anticipated massive multithreading, Kernighan responds that early systems did not need to confront that problem because single-core processor speeds steadily escalated for decades. Only when physical limits on heat generation and power consumption halted CPU clock scaling did the industry pivot toward packing multiple processor cores onto chips, making parallel concurrency mechanisms essential.
[01:01:57](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3717s) Exploring the Landscape: Testing 20 Languages on a Single Problem
Lex asks Kernighan whether it breaks his heart that he will never have the time to master the explosion of modern programming languages. Kernighan admits that while his heart is not broken, he is fascinated by exploring them through an empirical benchmark he uses in his Princeton spring programming course. To test a language, he implements a single, narrow task: a trivial text formatter that reads variable-length lines and wraps them to wrap at no more than 60 characters wide—similar to text flowing inside a web browser.
The problem requires roughly 15 lines of AWK code, and Kernighan has implemented it across more than twenty languages to evaluate their learning curves, execution speed, and syntactic verbosity: - **Lua**: Downloaded the runtime and completed a working program in under an hour relying purely on web documentation, having never touched the language before. - **Scala**: Found it equally straightforward and simple to get running quickly. - **Haskell**: Required several weeks of effort to write correctly and "ran like a turtle." - **Fortran 90**: Proved painful to work with, though it eventually functioned. - **Rust**: Took several days to get working because its ownership and explicit memory management paradigm felt completely unfamiliar.
[01:04:17](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3857s) Learning Rust and the Evolution of JavaScript
Brian Kernighan reflects on his earlier attempt to learn Rust. When he tried it several years ago, the ecosystem was moving at breakneck speed; documentation was inconsistent, and working examples frequently failed because the language had already changed underfoot. Although he believes Rust has stabilized and remains a language he would like to revisit, he suspects he probably never will, noting: “I think one of the issues you have to have something you want to do if you don't have something that is the right combination if I want to do it and yet I have enough disposable time whatever to make it worse than learning a new language at the same time it's never going to happen.”
Lex Fridman turns the discussion to JavaScript, recalling that when he was coming up in computing, JavaScript was widely viewed as “probably like the ugliest language possible,” yet it has steadily conquered both client-side and server-side computing and grown remarkably fast. Kernighan agrees with that trajectory: in its earliest days, JavaScript was notoriously irregular, and within academic departments, claiming to work on JavaScript would get a researcher ridiculed because it was considered completely unfit for serious study. Over time, both the language itself and compilation technology advanced dramatically, making it a viable and performant solution for full-stack systems. Kernighan has written modest amounts of JavaScript and experimented with translators, though he doubts it will entirely take over the world.
[01:06:28](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3988s) Modern Dependency Culture: The Risks of Package Ecosystems
Lex contrasts the modern development experience—heavily dependent on sprawling third-party ecosystems like Python and JavaScript packages—with the earlier UNIX and C ethos where engineers built nearly everything from scratch. Kernighan finds this shift deeply significant. In the early days, software relied on tiny, well-understood interfaces like `printf` or the standard C library. By contrast, modern workflows require pulling in massive dependencies sight unseen:
> “I've been doing some playing with machine learning over the last couple of days and G something doesn't work well you pip install this okay and down comes another gazillion megabytes of something and you have no idea what it was and if you're lucky it works and if it doesn't work you have no recourse there's absolutely no way you could figure out which in these thousand different packages and I think it's worse in the MPM NPM environment for JavaScript I think there's less discipline less control there...”
Beyond the cognitive impossibility of understanding thousands of nested libraries, Kernighan highlights the severe implications for software reliability and supply-chain security, prompting Lex to joke that one would never want to run a nuclear power plant on JavaScript.
[01:08:16](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4096s) Language Proliferation and the Role of Functional Programming
Lex asks whether the software world should eventually consolidate around a tiny set of two or three dominant languages rather than remaining fragmented across disparate communities (such as Ruby, Python, and C++). Kernighan strongly rejects this ideal, insisting that no single language can address every computing requirement: “I certainly don't hope it I'd not sure that that's right because I honestly don't think there is one language that will suffice for all the programming needs of the world.”
While roughly a dozen languages handle about 95% of real-world production code alongside thousands of niche alternatives, Kernighan values the proliferation of experimental languages because they serve as essential testbeds for powerful abstractions. Lex characterizes this space as a “playground for rebels.” Kernighan points specifically to functional programming as a fertile testing ground where concepts that once seemed computationally impractical—such as recursion in Lisp, first-class functions, closures, pattern matching, and lambdas—were refined before migrating into mainstream imperative and multi-paradigm languages.
[01:10:30](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4230s) Mathematical Programming and the Origins of AMPL
Lex brings up AMPL (A Modeling Language for Mathematical Programming), expressing admiration for its elegance and abstraction power, while playfully preempting Kernighan's characteristic modesty about his contributions. Kernighan quips that AMPL is useful “for minimizing functions,” before demurring that the credit belongs to his co-creators: Robert Fourer (a professor in Industrial Engineering and Management Sciences at Northwestern University) and David Gay (a numerical analyst and optimization expert at Bell Labs).
Kernighan explains that mathematical programming centers on constrained optimization: defining decision variables subject to systems of constraints (equalities or inequalities) to maximize or minimize an objective function. While textbook linear programming is neatly expressed as $Ax \le b$, real-world models produce massive, highly intricate, and extremely sparse matrices whose coefficient distributions obscure the original problem structure. AMPL was created to bridge this gap, offering a readable, high-level algebraic notation that mirrors how humans write mathematics on a blackboard while strictly decoupling the problem formulation from the underlying data and numerical solvers (whether linear, nonlinear, convex, or non-convex).
```mermaid flowchart LR accTitle: AMPL Separation of Concerns accDescr: Diagram showing how AMPL decouples the mathematical model, instance data, and backend numerical solvers.
subgraph UserSpec["User Specification"] M["Algebraic Model<br/>(Variables, Objectives, Constraints)"] D["Problem Data<br/>(Parameters & Sets)"] end
subgraph AMPL_Engine["AMPL Environment"] T["AMPL Translator & Presolver"] end
subgraph Solvers["Optimization Solvers"] LP["Linear / Simplex"] NLP["Nonlinear / Interior-Point"] end
M --> T D --> T T --> LP T --> NLP ```
- AMPL allows optimization experts and domain/data specialists to work independently on the mathematical formulation versus the parameter values. - Solvers are decoupled from the modeling language, allowing users to swap between linear, nonlinear, convex, and non-convex optimization engines without rewriting the core mathematical model. - Prior to AMPL, earlier efforts like GAMS (General Algebraic Modeling System) had begun exploring domain-specific algebraic modeling languages to bypass manual matrix generation.
[01:14:19](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4459s) The Genesis and Architecture of AMPL
In 1984, Robert Fourer spent a sabbatical year at Bell Labs, occupying the office directly across from Brian Kernighan. Kernighan points out that progress often comes down to pure proximity: “it's always geography.” Bob Fourer, Dave Gay, and Kernighan began discussing the awkwardness of existing algebraic modeling systems, which were clunky and heavily resembled Fortran. Fourer envisioned a clean language that mirrored the mathematical notations written on a blackboard—such as summations over sets—and translated those high-level algebraic declarations into a matrix representation to be handed off to an external solver.
Kernighan wrote the very first prototype of AMPL (A Modeling Language for Mathematical Programming), which also happened to be his first C++ program. It was relatively compact—around 3,000 lines of code—but it demonstrated the feasibility of decoupling the human-readable problem formulation from both the underlying data and the specialized numerical solver. A single model could be reused across vastly different data sets without restructuring the mathematical logic.
```mermaid flowchart LR accTitle: AMPL Pipeline Architecture accDescr: Pipeline showing human readable AMPL model and data entering the AMPL translator, feeding into a solver, and returning readable solutions. subgraph Input ["User Specifications"] M["Algebraic Model<br>(AMPL notation)"] D["Input Data Sets"] end subgraph Engine ["AMPL Processing"] T["AMPL Translator<br>(Prototype in C++)"] end subgraph Backend ["Solver Execution"] S["Numerical Solver<br>(Linear / Non-linear)"] end M --> T D --> T T -->|"Matrix & constraints"| S S -->|"Raw numerical results"| T T -->|"Interpreted solution<br>(e.g., quantities to buy/ship)"| Out["Human-Readable Decisions"] ```
When Lex Fridman asks how difficult it is to bridge an algebraic specification with an optimization solver, Kernighan notes that it is manageable because most solvers accept models in standardized representations—either basic constraint matrices for linear programming or functional interfaces and constraint routines for non-linear models. AMPL takes the solver's raw output numbers and translates them back into the user’s original domain terms, telling practitioners how many items to produce, purchase, or ship. While Kernighan stepped back after 1984, he co-authored a book on AMPL, which Fridman praises as one of the best books ever written. Kernighan generously credits Fourer: “Bob wrote most of it and so it's really, really well done he must be a dynamite teacher.” Kernighan also reveals that the book was not typeset in LaTeX, but in `troff`, the Bell Labs formatting system created in the early 1970s that predates Donald Knuth's TeX family by five to ten years.
- **AMPL Origin**: Developed starting in 1984 at Bell Labs by Robert Fourer, David Gay, and Brian Kernighan. - **First Implementation**: Kernighan’s first C++ program, totaling roughly 3,000 lines of code. - **Core Principle**: Clear separation among the algebraic model, the input data, and the solver algorithms. - **Typesetting**: The AMPL book was formatted using Bell Labs' vintage `troff` system rather than TeX or LaTeX.
---
[01:18:01](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4681s) Graph Theory, Heuristics, and P vs. NP
Fridman pivots from system design to Kernighan's contributions to graph theory, asking him to place a bet on whether P equals NP. Kernighan promptly bets that P does not equal NP: “The answer is no, although I'm told that somebody asked Jeff Dean if that was the—what conditions P would equal NP, and he said either P is 0 or N is 1, or vice versa.” When asked whether he possesses an intuitive reason, Kernighan admits he relies on the consensus of expert theoretical colleagues who lean heavily toward P ≠ NP.
Kernighan explains that his work on computational hardness dates back to 1968—before the formal framework of NP-completeness existed. For his doctoral dissertation, Kernighan investigated the graph partitioning problem: given an edge-weighted graph, split the vertices into two equally sized sets while minimizing the total weight of the edges cut between them. Working alongside Shen Lin at Bell Labs, they could not devise an algorithm guaranteed to produce the optimal partition. Instead, they invented heuristic methods—notably the Kernighan–Lin algorithm—that yielded high-quality approximate solutions, while Kernighan isolated a few solvable special cases for his thesis.
```mermaid flowchart TD accTitle: Comparison of Graph Partitioning and Min-Cut accDescr: Diagram illustrating why graph partitioning is computationally hard due to equal partition size constraints compared to unconstrained min-cut. subgraph Easy ["Max-Flow / Min-Cut"] E1["Arbitrary Cut of Graph"] --> E2["No constraint on subset sizes"] E2 --> E3["Solvable in Polynomial Time (P)"] end subgraph Hard ["Graph Partitioning Problem"] H1["Bipartition of Graph Nodes"] --> H2["Strict constraint: equal subset sizes (|A| = |B|)"] H2 --> H3["NP-Complete (Heuristic needed: Kernighan-Lin)"] end ```
Kernighan emphasizes the contrast between graph partitioning and the standard maximum-flow/minimum-cut problem: without a constraint on partition sizes, minimum cut is polynomial and computationally easy, but demanding that the two subsets contain identical numbers of nodes turns it into an intractable, NP-complete problem. This practical work occurred right as Stephen Cook was formulating the foundational theories of NP-completeness.
- **Kernighan–Lin Algorithm**: A landmark heuristic for graph partitioning and the Traveling Salesperson Problem (TSP) designed to find near-optimal solutions quickly. - **Historical Timing**: Researched in 1968, predating Stephen Cook's 1971 paper that established NP-completeness. - **Theoretical CS Pivot**: When Fridman asks why Kernighan did not follow the Donald Knuth path of pure algorithm design, Kernighan self-deprecatingly responds: “Not smart enough... I just didn't have the talent for it.” He recalls briefly trying to work with future Turing Award laureate John Hopcroft at Princeton before concluding, “It became crystal clear I was not cut out for this stuff, period,” choosing instead to focus on building practical software and writing books.
---
[01:22:20](https://www.youtube.com/watch?v=O9upVbGSBFo&t=4940s) 1964 and the Cycles of AI Optimism
Fridman asks about Kernighan's undergraduate senior thesis at the University of Toronto in 1964, which was a literature survey on artificial intelligence. Kernighan characterizes that era as an "AI summer"—the opposite of an AI winter. Researchers and writers widely believed that digital computers would soon solve virtually every high-level human intellectual challenge: automated language translation, grandmaster-level chess, and automated geometric theorem proving.
Kernighan recalls reading the 1963 anthology *Computers and Thought* (edited by Edward Feigenbaum and Julian Feldman), noting that he bought into the excitement: “I drank the Kool-Aid in some sense.” However, goals assumed to be right around the corner took nearly six decades of algorithmic iteration, vast increases in processing capacity, massive datasets, and interconnected open-source software ecosystems to achieve. While modern machines finally master Go and chess and handle complex translation tasks, progress was far slower than early pioneers imagined.
Reflecting on forecasting technological timelines, Kernighan invokes an observation from science fiction writer Arthur C. Clarke (Clarke’s First Law): “When some distinguished but elderly person says that something is possible, he's probably right; and if he says it's impossible, he's probably wrong.” This highlights the danger of near-term overconfidence alongside long-term technological pessimism.
- **1964 Senior Survey**: Conducted at the University of Toronto, examining early symbolic AI and cybernetics literature. - **Seminal Text**: *Computers and Thought* (1963), a foundational compendium that shaped initial optimism in machine cognition. - **Long-term Evolution**: Modern triumphs in machine translation and game playing required 50 to 60 years of hardware advances, massive empirical data, and ubiquitous global networking rather than quick algorithmic breakthroughs.
[01:24:41](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5081s) Machine Learning, Data Bias, and the Dream of Human-Level AI
Lex Fridman brings up the current resurgence of artificial intelligence, asking Brian Kernighan for his thoughts on this modern "summer of AI," marked by machine learning and deep neural networks. Fridman contrasts this new era—where systems absorb massive datasets to discover programs automatically—with the older paradigm of explicit algorithms and search heuristics. Kernighan prefaces his thoughts with self-deprecating humility, noting that he is far from an expert and that most of what he knows comes from his students, who are "probably disappointed in how little I've learned from them."
Kernighan recognizes the undeniable impact machine learning has had on fields like game playing, but he raises a profound caveat: these systems learn exclusively from the historical data supplied to them. If the training data reflects human biases—such as the historically entrenched and "flat wrong" premise that women are less capable than men at certain tasks—the algorithms inevitably learn, perpetuate, and scale those prejudices.
```mermaid flowchart LR accTitle: Data Bias in Machine Learning accDescr: Pipeline showing how historical bias in training data either amplifies societal harm or acts as a mirror for intervention.
subgraph Input ["Data Generation"] A["Historical Human Data"] -->|"Encodes social bias"| B["Training Dataset"] end
subgraph Model ["Machine Learning Model"] B --> C["Neural Network / Algorithm"] end
subgraph Outcomes ["Societal Impact"] C -->|"Pessimistic: Amplification"| D["Reinforced Past Injustices"] C -->|"Optimistic: Mirroring"| E["Exposes Latent Societal Bias"] end ```
When Fridman counters with an optimistic perspective—suggesting that machine learning can act as a mirror that forces society to confront and correct its flaws—Kernighan agrees that such an outcome would be wonderful, though he remains skeptical:
> “That's an optimistic point of view and if it works that way that would be absolutely great and and what I don't know is whether it does work that way or whether the the you know the AI mechanisms or machine learning mechanisms reinforce and amplify things that have been wrong in the past and I don't know I but I think that's a serious thing that we have to be concerned about.” — Brian Kernighan
Fridman then presses Kernighan on the grand, enduring ambition of artificial intelligence since the 1960s: building human-level or superhuman intelligence. When asked what it would take and whether humanity is close, Kernighan admits, "I haven't a clue." He references Alan Turing’s seminal early 1950s work proposing the Turing test, commenting that while the test is an interesting and somewhat objective benchmark, interpreting what it actually proves about intelligence is an entirely different matter.
---
[01:27:49](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5269s) Computing Everywhere and the Erosion of Privacy
Broadening the conversation, Fridman asks whether Kernighan feels excitement or dread about the ubiquitous expansion of computing into everyday human life. Kernighan reflects that while technology generally trends toward good over the long run, there are numerous cases where it produces severe short-term or long-term harms for specific groups.
He highlights corporate and governmental surveillance as an immediate, pressing threat. With social media and modern tracking technologies, an unprecedented amount of personal information is amassed and controlled by external entities—far more than any individual should reasonably feel comfortable with.
Fridman observes that attitudes toward data surveillance vary sharply across generations, noting that younger people often seem less anxious about privacy issues. Fridman speculates that within fifty years, evolving human psychology might alter or invert the public's perception of what constitutes a genuine privacy violation.
---
[01:29:45](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5385s) Moore's Law, Hardware Limits, and Declarative Programming
Fridman transitions to hardware constraints, asking whether Moore's law and exponential computing growth can continue indefinitely or whether a plateau is inevitable. Kernighan responds with a fundamental principle:
> “Well the furball is answer there's no exponential can go on forever you run out of something.” — Brian Kernighan
Kernighan explains that the nature of Moore's law has already changed dramatically. Raw clock speeds no longer increase vertically; instead, manufacturers scale chips horizontally by cramming more processor cores, cache, and memory onto a single die. Ultimately, this approach must bump into physical boundaries when circuit dimensions reach the scale of individual atoms. Fridman references a recent conversation with chip architect Jim Keller, who argued that transistor density could still shrink roughly a thousandfold before reaching insurmountable quantum limits.
Turning to software, Fridman asks how programming languages will adapt to these changing architectural limits. Kernighan predicts that the industry will increasingly move toward higher abstractions where code is generated by software rather than handwritten line by line:
- **Programs writing programs:** The act of writing software will increasingly belong to automated systems rather than manual human coders. - **Declarative over procedural paradigms:** Instead of writing detailed procedural steps specifying *how* a task must be accomplished, developers will express *what* end state they want, leaving the underlying language or system to determine the execution path. - **Broadening domain-specific tools:** The declarative approaches currently confined to narrow, specialized domains will slowly generalize into broader development environments.
---
[01:32:54](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5574s) Demystifying Tech: Teaching Non-Majors at Princeton
Kernighan reflects on his experience teaching "Computers in Our World" at Princeton, an introductory course designed specifically for non-engineering students, such as history and English majors. Addressing the common pedagogical debate over whether "everybody should learn to code," Kernighan demurs:
> “I think this is one of these questions of should everybody know how to program and I think the answer is probably not but I think everybody should at least understand sort of what it is so that if you say to somebody I'm a programmer they have a notion of what that might be or if you say this is a program or this was decided by a computer running a program that they have some vague intuitive understanding and an accurate understanding of what that might imply.” — Brian Kernighan
The curriculum focuses on deconstructing the black box of modern technology, explaining the fundamentals of: 1. How computer hardware processes information. 2. What a software program actually is and how code is structured. 3. How networked devices communicate with one another over modern digital channels.
Kernighan notes that while practically none of the humanities students who take the course go on to become professional software engineers, they leave with an accurate mental model of how computing impacts society. To ground this understanding, he does not start with high-level languages; instead, students are introduced to a simple toy machine model equipped with a tiny instruction set of roughly a dozen operations, on which they write simple assembly language programs to experience firsthand how machines execute instructions at the lowest level.
[01:35:06](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5706s) Levels of Abstraction: From Assembly to Modern Apps
Continuing his explanation of how he teaches non-technical students, Brian Kernighan reflects on where to set the floor of understanding. While one could theoretically keep drilling deeper down into physical gates and electrons, he draws the line at a simple instruction set architecture. He shows students that computers operate on a very small repertoire of fundamental operations—such as adding, subtracting, and branching. From there, he introduces layers of abstraction: higher-level languages like Fortran and C allow programmers to write software that is easier to comprehend and largely independent of specific hardware architectures.
Kernighan points out that users constantly interact with immense software systems without recognizing that they are built upon these very same basic principles. People run operating systems like macOS or Windows and download phone applications every day, taking them for granted. Lex Fridman observes how easy it is to forget that behind these everyday consumer tools are real engineers who wrote code. Kernighan acknowledges that it requires an enormous conceptual leap for a student to connect a five- or ten-line toy assembly program that adds two numbers to a modern mobile web browser, yet at the foundational level, they are fundamentally the same mechanism.
```mermaid flowchart TD accTitle: Levels of Computing Abstraction accDescr: Diagram illustrating how low-level operations build up to modern consumer applications.
subgraph LowLevel["Hardware & Machine Level"] A["Simple Operations<br/>(add, subtract, branch)"] B["Toy Assembly Language<br/>(5-10 line programs)"] A --> B end
subgraph Languages["Abstraction Layers"] C["Higher-Level Languages<br/>(Fortran, C, etc.)"] B --> C end
subgraph Applications["Everyday Consumer Scale"] D["Operating Systems<br/>(macOS, Windows)"] E["Modern Phone Apps<br/>& Web Browsers"] C --> D C --> E end ```
[01:36:35](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5795s) The Changing Nature of Human Interaction
Looking broadly at history, Fridman asks how computing has reshaped the world, noting how students on campus seem constantly glued to their devices. Kernighan reflects on the staggering transformation in how human beings interact both locally and across great distances. During his youth in the 1960s, placing a long-distance telephone call was a major event that cost significant money. Today, people routinely bypass voice calls entirely in favor of text messages, or casually hold regular video calls with friends and family on the other side of the planet without giving the underlying technology a second thought.
When Fridman asks whether this omnipresent connectivity brings people closer together or erodes genuine intimacy, Kernighan views the outcome as nuanced. On a personal level, technology has strengthened his family ties, allowing him to exchange messages with his brother and sister in Canada every two or three days—far more often than they would have spoken over the phone twenty years ago. Conversely, he observes students walking around campus with their heads down, buried in their smartphones to the point that passersby have to dodge out of their way. Kernighan cites sociological research suggesting that individuals may feel less genuinely connected today, musing that it sometimes makes one want to tell them to “wake up and smell the coffee.”
[01:38:57](https://www.youtube.com/watch?v=O9upVbGSBFo&t=5937s) Hopes, Concerns, and the Societal Impact of Computing
Fridman asks whether Kernighan feels optimistic about the next ten to twenty years, considering that computers have expanded from virtually nonexistent machines to ubiquitous devices in nearly every hand worldwide, from Asia to Africa. Kernighan confesses that his outlook is mixed. While access to computing creates immense potential for people to improve their lives globally, he is troubled by the negative social patterns emerging in the short term.
He highlights the surge in tribalism and parochialism, noting that computing platforms frequently magnify an “us versus them” mentality. Furthermore, digital tools make it trivial to spread misinformation, misrepresent reality, or outright lie, which has destabilized local and global political systems. Fridman remarks that while giving marginalized populations a voice is profoundly empowering, granting every single person an unfiltered megaphone unleashes an unpredictable, chaotic reality. “Yeah, it’s kind of scary,” Kernighan agrees regarding the uncertain long-term consequences for society.
[01:40:27](https://www.youtube.com/watch?v=O9upVbGSBFo&t=6027s) The Golden Age at Bell Labs and the Creation of AWK
Fridman asks Kernighan if there is a particular transformative or profoundly happy moment in his career that he would choose to relive. Rather than selecting a single isolated day, Kernighan recalls the vibrant, collaborative environment of the 1970s at Bell Labs. It was a golden era when UNIX was young, the computing landscape was full of low-hanging fruit, and an tight-knit group of talented colleagues built software together. If someone engineered a utility, peers would eagerly test it out and offer feedback.
“I don’t think specific moments; I think there were lots and lots and lots of good times at Bell Labs where you would build something and it worked, and somebody used it, and they said, ‘Gee, that’s neat,’” Kernighan says. He mentions AWK as a prime example of building a tool that his colleagues quickly embraced. When Fridman points out that AWK is now used by millions of people worldwide, Kernighan wryly adds that having millions of users also means all your original mistakes are laid bare for everyone to see. Fridman concludes the interview by thanking Kernighan, calling the discussion an honor.
[01:41:53](https://www.youtube.com/watch?v=O9upVbGSBFo&t=6113s) Outro and Closing Thoughts
Following the conversation, Fridman thanks listeners and acknowledges episode sponsors Eight Sleep and Raycon earbuds. He encourages listeners to support the show via YouTube subscriptions, five-star reviews on Apple Podcasts, Patreon support, and Twitter interactions. He adds a humorous aside about his Twitter handle (@lexfridman), explaining that his surname is spelled without an "e" because his family was not particularly adept at spelling when they immigrated to the United States.
Fridman closes the episode by leaving listeners with a classic programming aphorism from Brian Kernighan: “Don't comment bad code; rewrite it.”
## Notable quotes > [01:41:53](https://www.youtube.com/watch?v=O9upVbGSBFo&t=6113s) Don't comment bad code; rewrite it. — Brian Kernighan
> [51:04](https://www.youtube.com/watch?v=O9upVbGSBFo&t=3064s) As you write programs in a language like C, at some point scale gets to you, and it's too hard to keep track of the pieces, and there's no guardrails or training wheels or something like that to prevent you from doing bad things. — Brian Kernighan
## Mentioned Brian Kernighan, Lex Fridman, Ken Thompson, Dennis Ritchie, Rob Pike, Bill Joy, Alfred Aho, Peter Weinberger, Fernando Corbató, Richard Stallman, Linus Torvalds, Bjarne Stroustrup, Robert Griesemer, Alan Donovan, Tony Hoare, Niklaus Wirth, Robert Fourer, David Gay, Shen Lin, Jim Keller, Alan Turing, Donald Knuth, Bell Labs, AT&T, MIT, General Electric, Xerox PARC, Digital Equipment Corporation (DEC), Microsoft, Princeton University, University of Toronto, UNIX, Multics, CTSS, Plan 9, BSD, Linux, PDP-7, IBM 7094, MacBook Air, iMac, Sam, ed, vi, Emacs, QED, C, C++, Go, Rust, AWK, AMPL, Python, JavaScript, Fortran, COBOL, ALGOL, BASIC, Lua, Scala, Haskell, troff, TeX, Moore's law, Kernighan–Lin algorithm, The C Programming Language, The Practice of Programming, The Go Programming Language, UNIX: A History and a Memoir, Eight Sleep, Raycon
## Video description Brian Kernighan is a professor of computer science at Princeton University. He co-authored the C Programming Language with Dennis Ritchie (creator of C) and has written a lot of books on programming, computers, and life including the Practice of Programming, the Go Programming Language, his latest UNIX: A History and a Memoir. He co-created AWK, the text processing language used by Linux folks like myself. He co-designed AMPL, an algebraic modeling language for large-scale optimization.
Support this podcast by supporting our sponsors: - Eight Sleep: https://eightsleep.com/lex - Raycon: http://buyraycon.com/lex
EPISODE LINKS: Brian's website: https://www.cs.princeton.edu/~bwk/ Unix: A History and a Memoir (book): https://amzn.to/3fFJ1yM Understanding the Digital World (book): https://amzn.to/30ktBJI
PODCAST INFO: Podcast website: https://lexfridman.com/podcast Apple Podcasts: https://apple.co/2lwqZIr Spotify: https://open.spotify.com/episode/5OtSR9U7Nv9Ly9ixzmerrU RSS: https://lexfridman.com/feed/podcast/ Full episodes playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4 Clips playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOeciFP3CBCIEElOJeitOr41
OUTLINE: 0:00 - Introduction 4:24 - UNIX early days 22:09 - Unix philosophy 31:54 - Is programming art or science? 35:18 - AWK 42:03 - Programming setup 46:39 - History of programming languages 52:48 - C programming language 58:44 - Go language 1:01:57 - Learning new programming languages 1:04:57 - Javascript 1:08:16 - Variety of programming languages 1:10:30 - AMPL 1:18:01 - Graph theory 1:22:20 - AI in 1964 1:27:50 - Future of AI 1:29:47 - Moore's law 1:32:54 - Computers in our world 1:40:37 - Life
CONNECT: - Subscribe to this YouTube channel - Twitter: https://twitter.com/lexfridman - LinkedIn: https://www.linkedin.com/in/lexfridman - Facebook: https://www.facebook.com/LexFridmanPage - Instagram: https://www.instagram.com/lexfridman - Medium: https://medium.com/@lexfridman - Support on Patreon: https://www.patreon.com/lexfridman
[Source](https://www.youtube.com/watch?v=O9upVbGSBFo)