Lex Fridman PodcastBrian Kernighan: UNIX, C, AWK, AMPL, and Go Programming | Lex Fridman Podcast #109
CHAPTERS
- 0:00 – 4:01
Brian Kernighan’s legacy (UNIX, C, AWK, AMPL) + podcast housekeeping
Lex introduces Brian Kernighan’s foundational role in UNIX-era computing and his work on C, AWK, and AMPL. He also runs through sponsor messages and sets up the conversation’s scope: history, languages, tools, and the future of computing.
- •Kernighan’s contributions: UNIX community, C book with Ritchie, AWK, AMPL, Go book
- •Lex frames Kernighan as influential yet humble
- •Sponsor/ads segment and how Lex structures ads outside the main conversation
- 4:01 – 11:31
From punch cards to time-sharing: CTSS and the road to Multics
Kernighan explains the pre-UNIX world: batch computing with punch cards and the slow feedback loop it created. He describes the breakthrough of time-sharing via CTSS on the IBM 7094 and how this inspired the ambitions of Multics as an early “computing utility.”
- •Punch-card workflow vs interactive terminals and rapid iteration
- •Time-sharing concept: slicing CPU time to create the illusion of a dedicated machine
- •CTSS hardware constraints (memory sizes, 36-bit words) and why it still felt revolutionary
- •Multics vision as a precursor to cloud computing—utility computing decades early
- 11:31 – 22:06
Bell Labs culture and the accidental birth of UNIX
The conversation shifts to what made Bell Labs a unique incubator: dense talent, open collaboration, and a tolerance for bending bureaucracy. Kernighan recounts how Bell Labs exited Multics, leaving a craving for a good computing environment—then Ken Thompson found a PDP-7 and UNIX began as a practical rebuild rather than a grand plan.
- •Bell Labs as a mission-driven research environment tied to improving phone service
- •Open, cooperative culture with fast in-person feedback loops
- •Multics disappointment and Bell Labs’ withdrawal in 1969
- •Ken Thompson’s PDP-7 experiments and the famous ‘three weeks’ UNIX origin story
- •Early UNIX built in assembly; small systems made “big picture” manageable
- 22:06 – 31:54
UNIX philosophy in practice: minimal mechanisms, files, and pragmatic “openness”
Kernighan describes UNIX as a programmer-centric environment optimized for writing and sharing tools, creating a virtuous cycle of productivity. He explains how severe hardware constraints pushed simplicity and generalization (especially the file model), and clarifies UNIX’s licensing history—source-available to universities but not truly open source.
- •UNIX designed primarily as a productive programmer environment
- •Constraint-driven minimalism: simple mechanisms over many special cases
- •The file system as a unifying interface (devices as files; later Plan 9 generalizations)
- •Community dynamics: tools built by one person quickly become shared infrastructure
- •UNIX licensing: proprietary but widely source-licensed to universities; path to BSD/Linux ecosystem
- 31:54 – 35:18
Is programming art, science, or engineering? + Kernighan’s way of writing code
Kernighan argues programming blends art (figuring out what to build), science (algorithms/data structures), and engineering (constraints, maintenance, time). He then describes his own pragmatic workflow: small experiments, exploratory analysis, and choosing tools like AWK or Python depending on scale.
- •Art: understanding user needs and deciding what the program should be
- •Science: algorithms, data structures, scalability considerations
- •Engineering: constraints, maintenance, and future handoffs
- •Modern Kernighan workflow: small programs, experiments, and data exploration
- •Tool choice as scale changes (AWK for tiny scripts; Python for larger work)
- 35:18 – 41:53
AWK and grep: why tiny tools are still unbeatable for real work
Kernighan explains AWK’s origin as a ‘quick and dirty’ text/data processing language and why its defaults make one-liners powerful. He compares it to grep as the simplest pattern-action tool, and discusses why command-line paradigms flourished in UNIX but weren’t native to Windows’ GUI-first lineage.
- •What AWK is: pattern-action scripting for line/field-oriented text processing
- •Power of defaults: implicit loops over files/lines, automatic field splitting, built-in counters
- •Why grep feels magical: regex match + print as a universal primitive
- •UNIX tool ecosystem encourages composability and fast iteration
- •Windows history (MS-DOS → GUI focus) and the rise of Cygwin/WSL to bridge the gap
- 41:53 – 46:27
A working programmer’s setup: Macs, Sam, and the evolution of text editors
Kernighan shares his practical setup (MacBook Air) and his preference for Rob Pike’s Sam editor, with occasional vi usage. He then walks through editor history: from paper terminals and line editors (QED/ed) to CRT-driven cursor editing (vi) and the cultural ‘religions’ around editor choice.
- •Kernighan’s hardware: lightweight laptop as an effective balance
- •Sam editor (Rob Pike) and its lineage from earlier UNIX editing ideas
- •ed as a stripped-down descendant of QED; line-oriented editing on paper terminals
- •CRT displays enabled cursor-based editors; vi as a key milestone
- •Editor choice as cultural imprint: ‘what religion you were brought up with’
- 46:27 – 52:48
A whirlwind history of programming languages: assembly to high-level to systems languages
Kernighan sketches language evolution from raw bit patterns to assemblers, then to high-level languages like Fortran/COBOL/ALGOL that democratized programming and improved portability. He describes the rise of system programming languages and why C emerged as the enduring survivor that balanced machine control with expressive power.
- •Early programming: switches, paper tape, and the first assemblers
- •Portability problem: every machine had its own assembly language
- •High-level languages (Fortran/COBOL/ALGOL) moved closer to human intent and widened access
- •System programming languages aimed at OS/tools/compilers and closer machine control
- •C as the standout survivor from late ’60s/’70s system-language experimentation
- 52:48 – 58:44
Why C endured + how K&R became the defining programming book
Kernighan explains C’s staying power as a ‘sweet spot’ between expressiveness and efficiency—especially crucial on constrained hardware—and amplified by UNIX portability. He recounts how the K&R book happened largely through timing and necessity, and why clear writing plus carefully chosen examples shaped how generations learned C.
- •C’s sweet spot: natural expression with high performance on limited machines
- •UNIX and C reinforced each other via portability and shared tooling
- •K&R origin story: wrote early (1977) when C spread but books didn’t exist
- •Dennis Ritchie’s reference manual prose as a gold standard
- •Examples matter: teach realistic tasks, not just syntax trivia; “Hello, World” legacy
- 58:44 – 1:04:58
Go’s place in the language ecosystem: simplicity, lineage, and concurrency that works
Kernighan situates Go as a modern language influenced by both Bell Labs (Thompson/Pike) and European language design traditions (Wirth lineage via Griesemer). He highlights Go’s approachable concurrency model (goroutines, CSP ideas) and discusses what makes learning new languages hard: documentation quality, stability, and having a motivating project.
- •Go lineage: Bell Labs tradition + ETH/European design influence
- •Surface familiarity to C, but with modern structure and safer patterns
- •Concurrency as a core differentiator: goroutines and CSP-inspired communication
- •Why early C/UNIX didn’t foreground threads (hardware trends changed later)
- •Learning languages via a single benchmark program; experiences with Lua/Scala/Haskell/Fortran/Rust and documentation pitfalls
- 1:04:58 – 1:10:30
JavaScript, dependency culture, and whether languages should converge
Kernighan reflects on JavaScript’s evolution from ‘ugly and ridiculed’ to viable and performant thanks to better engines/compilers. He contrasts earlier eras of building from scratch with today’s dependency-heavy ecosystems (pip/npm), raising maintainability and security concerns, and argues that language diversity is valuable for idea exploration even if only a dozen dominate usage.
- •JavaScript’s reputation shift: from academic punchline to serious tool
- •Modern programming often means stacking libraries you don’t understand
- •Dependency risks: debugging opacity, version churn, and security/supply-chain concerns (esp. npm)
- •Diversity vs convergence: no single language fits all needs; a small set dominates in practice
- •Research languages (often functional) as idea incubators: recursion, closures, lambdas entering mainstream
- 1:10:30 – 1:18:01
AMPL: turning math into optimization software (and keeping model, data, solver separate)
Kernighan explains AMPL as a modeling language for mathematical programming, enabling humans to express optimization problems in readable algebraic form. He tells the origin story: Bob Fourer’s sabbatical at Bell Labs, collaboration with David Gay, and Kernighan’s quick C++ prototype that proved feasibility—bridging from high-level constraints to solver-ready representations.
- •What AMPL is for: linear/nonlinear optimization with constraints and objective functions
- •Key design: separate model from data, and separate modeling from solver implementation
- •Motivation: real-world matrices are huge/sparse and not human-comprehensible; need algebraic specification
- •Origin story (1984 Bell Labs): Fourer + Gay + Kernighan; “geography matters” collaboration
- •Implementation notes: early AMPL prototype in C++; AMPL generates solver inputs and maps results back to model terms
- 1:18:01 – 1:22:20
Graph theory roots, heuristics before complexity theory, and the P vs NP detour
Kernighan revisits his PhD-era work on graph partitioning, emphasizing that the effort was heuristic-driven before NP-completeness was widely formalized. He explains why certain constraints transform easy problems into hard ones, shares his skepticism on P=NP (via community intuition), and reflects on choosing programming and writing over deep theory.
- •Graph partitioning problem: split nodes evenly minimizing crossing edge weight
- •Heuristics that worked well without guarantees—developed before NP-completeness framing
- •Constraint effects: balanced cut vs unconstrained min-cut/max-flow tractability
- •P vs NP: no strong personal intuition; notes prevailing expert bet is “no”
- •Career reflection: recognizing fit—moving from theory aspirations toward building systems and books
- 1:22:20 – 1:43:09
AI then and now: 1964 optimism, today’s ML realities, Moore’s Law, and life reflections
Kernighan recalls the ‘AI summer’ of the 1960s, when machine translation, theorem proving, and chess seemed imminent—then reality arrived decades later through data, compute, and infrastructure. He discusses present-day concerns (bias, privacy, surveillance, misinformation), cautiously speculates about abstraction and declarative programming, and closes with reflections on teaching non-majors and the joy of building tools people use.
- •1960s AI optimism: ‘Computers and Thought’ era and underestimated timelines
- •Progress drivers: hardware growth, more data, and broader collaboration infrastructure
- •ML risks: biased data leads to biased models; uncertainty whether systems expose or amplify bias
- •Moore’s Law: exponential trends can’t run forever; shifts from faster cores to more parallelism
- •Programming’s future: higher abstraction, more declarative “say what, not how,” possibly natural language interfaces
- •Teaching “Computers in Our World”: giving non-majors a grounded mental model via a toy assembly machine
- •Societal effects: communication changes, privacy tradeoffs, political manipulation, and mixed optimism
- •Personal happiness: the ‘it worked’ moment and the golden-era feedback loop at Bell Labs
