Lex Fridman PodcastJames Gosling: Java, JVM, Emacs, and the Early Days of Computing | Lex Fridman Podcast #126
CHAPTERS
- 0:00 – 4:32
Java’s impact, Lex’s personal connection, and sponsor messages
Lex introduces James Gosling as the creator of Java and reflects on learning object-oriented and concurrent programming through Java. He also delivers sponsor messages and sets up the conversation’s tone and themes.
- •Java as a foundational language for many engineers
- •Lex’s early fascination with concurrency and parallel computing
- •Format of the episode (ads upfront, none mid-roll)
- •Sponsors and ways to support the podcast
- 4:32 – 7:12
Irrational numbers, math beauty, and the square-root-of-two rumor
Lex asks about the myth that √2 is Gosling’s favorite irrational number, which leads to a discussion of “interesting numbers” and mathematical beauty. Gosling connects √2 to the Pythagoreans and how irrationality challenged a worldview of perfect rational structure.
- •Gosling’s teenage fascination with ‘curious and interesting numbers’
- •The Pythagoreans and the disruptive proof of √2’s irrationality
- •How math myths and personal lore get started
- •Why “perfect” definitions often fail under scrutiny
- 7:12 – 8:00
Gödel, three-valued logic, and the messiness of problem solving
The conversation pivots from Gödel’s incompleteness theorem to the human desire for binary answers. Gosling argues that allowing “maybe” (three-state logic) better matches reality, and that both math and programming can be messy despite their formal foundations.
- •Gödel reframed: not despair, but humility about certainty
- •Three-valued logic: true/false/maybe as a practical worldview
- •Math as messy work, not just clean results
- •Parallels to public discourse and oversimplification
- 8:00 – 11:19
Programming as structure: proofs, complexity intuition, and thinking in pictures
Gosling describes programming as navigating logical structures and graphs of possibilities, including the desire to ‘prove’ code works. He shares a story about a brilliant peer who produced complexity answers like an oracle, then explains his own visual style of reasoning about code.
- •Programming as pattern recognition over a space of possibilities
- •Why Gosling values being able to reason/prove correctness
- •The ‘oracle’ anecdote: getting N log N without the derivation
- •Gosling as a visual thinker who experiences code as machinery
- 11:19 – 14:33
Coding style debates: dense formatting, readability, and seeing the whole function
Lex and Gosling discuss the surprisingly emotional nature of code formatting debates. Gosling explains his preference for dense code to maximize what fits on screen, tied to his visual cognition and desire to see entire functions at once.
- •Formatting as an engineering culture flashpoint (braces, whitespace)
- •Dense layout to reduce scrolling and working-memory load
- •Why teams sometimes ‘intervene’ on style differences
- •How cognition (visual vs verbal) shapes coding preferences
- 14:33 – 22:23
First computers and first programs: PDP-8, teletype interfaces, and building with no parts
Gosling recalls learning on a PDP-8 with 4K RAM and teletype I/O—long before modern monitors. He describes programming as a way to build complex systems without material costs, and shares stories of hardware tinkering and early games/graph plotting.
- •PDP-8 specs and the feel of early computing constraints
- •Time-sharing context and ‘hidden’ machines in university corners
- •Programming as building without physical materials or money
- •Early programs: assembly/FOCALFIVE, games, and printed graph plots
- 22:23 – 27:22
Language preferences: pragmatism over syntax, and what Lisp/Simula got right
Gosling emphasizes that languages matter less than what you can build with them, dismissing syntax wars. He praises Lisp’s power (and jokes about parentheses), then highlights Simula’s foundational role in object orientation and early coroutine concepts.
- •Pragmatism: ‘what you can do’ matters more than syntax
- •Lisp’s structure and metaprogramming strengths (despite parentheses)
- •Simula as the first object-oriented language
- •Coroutines as an early concurrency mental model and its limits
- 27:22 – 35:14
Emacs history: TECO macros, editor philosophy, and porting Emacs to Unix in C
Gosling explains Emacs’s origin as TECO macros and the shift toward visual, programmable editing. He describes writing a C implementation of Emacs for Unix at CMU, how it spread through the research community, and the remarkably informal security posture of ARPANET-era sharing.
- •TECO as ‘Emacs with your eyes closed’ and why it mattered
- •Emacs’s philosophy: programmable, extensible editing workflows
- •Why Gosling wrote Emacs in C: Unix portability and practicality
- •How Emacs spread via ARPANET and early trust-based collaboration
- 35:14 – 48:45
ARPANET social life and the early Internet: chat, email, and scaling battles
Gosling describes how social life at CMU centered on early network tools like email and one-line messaging—proto-social media. He also recounts how entrenched industries resisted the Internet, and why their business incentives conflicted with open publishing and user-driven content.
- •Early ‘text messaging’ as terminal-based one-line chat
- •Social coordination on ARPANET: lunches, dates, daily life
- •Cable/phone/broadcast industries resisting an uncontrollable medium
- •Internet as universal publishing—foreseeing YouTube/Netflix-like models
- 48:45 – 56:13
Visionary founders, timing, and leadership: Musk, Jobs, Bezos—and the ‘jerk’ myth
The discussion turns to how companies cross disruptive chasms despite short-term pain, and why public markets punish transitions. Gosling reflects on visionary founders and patient capital, then critiques the Silicon Valley myth that being a jerk is necessary for excellence, using Jobs (and comparisons to Musk) as focal points.
- •Why incumbents avoid disruption: revenue models and quarterly pressure
- •Patient capital and founder control enabling long-term bets
- •Jobs’s vision vs interpersonal harshness; why Gosling wouldn’t work for him
- •Rejecting the idea that cruelty is required for high performance
- 56:13 – 58:49
Work hard and smart: effort, kindness, and cultures that scale performance
Lex challenges ‘work smart, not hard,’ and Gosling agrees it’s an ‘and,’ not an ‘or.’ They discuss pushing for excellence without nastiness and point to cultures (like early Google) that pair intensity with decency.
- •‘Smart vs hard’ reframed as ‘smart and hard’
- •Hard work as necessary for discovering efficient paths
- •Separating demanding standards from abusive behavior
- •Examples of high-performance cultures without toxicity
- 58:49 – 1:10:26
Open source as tool vs ideology: Emacs licensing, Stallman tensions, and sustainable models
Gosling argues open source is powerful for community building but becomes problematic when treated as a dogma that forbids earning a living. Using Emacs’s history and conflicts around “information must be free,” he explores trade-offs, incentives, and pragmatic ways open projects can sustain themselves.
- •Open source benefits: collaboration, community, faster progress
- •Critique of ‘open source as religion’ and the ‘vow of poverty’ implication
- •Why Gosling stepped away from being ‘Mr. Emacs’ to finish grad school
- •Monetization via support/services and the dangers of rapacious pricing
- 1:10:26 – 1:28:31
The origin of Java: embedded devices, safety-first engineering, and escaping C’s pointer traps
Gosling tells the story of Java beginning at Sun (1990–1991) as an exploration of computing beyond PCs—consumer electronics, industrial systems, and early mobile. Reliability and safety needs drove them to challenge C/C++ norms, targeting pointer-related vulnerabilities, memory errors, and concurrency issues to improve developer velocity and production stability.
- •Java’s roots in embedded/consumer electronics, not ‘a language revolution’ at first
- •Road trips to Japan/Europe/Korea to learn how device companies think
- •Safety and reliability over performance hacks; reducing catastrophic bugs
- •Eliminating pointer hazards, memory leaks, use-after-free, buffer overflows
- •Java’s value proposition: faster path from prototype to stable production software
- 1:28:31 – 1:43:48
JVM design and portability: bytecode, purchasing constraints, and lessons from Pascal P-code
Gosling explains the JVM as an abstract machine instruction set that can be interpreted or compiled, enabling portability across CPUs and generations. He connects the idea to earlier experiences translating UCSD Pascal P-code to VAX assembly, then discusses standardization battles (two’s complement, IEEE 754) needed to make cross-platform behavior predictable.
- •JVM as bytecode for an abstract machine: interpret or JIT/compile
- •Portability motivated by vendor lock-in and ‘purchasing department’ pain
- •Personal precedent: translating P-code to VAX assembly efficiently
- •Standardizing arithmetic and floating-point behavior (IEEE 754)
- •Why predictability (‘what does 2+2 mean?’) matters for developers and libraries
- 1:43:48 – 1:47:04
Android and Java at scale: pride, contract violations, and long-term consequences
Lex asks about Java’s role in Android and what Gosling wishes were different. Gosling expresses happiness that Java was used widely on phones but criticizes how Android’s leadership crossed lines that later fueled major legal conflicts, noting it would have been cheaper to collaborate cleanly.
- •Java already running on phones before Android; proven viability
- •Positive feelings about adoption and real-world impact
- •Critique of process: ‘lines crossed’ and contract/license violations
- •Legal fallout as an avoidable cost of adversarial choices
- •Other large-scale Java deployments (smart cards, SIM cards)
- 1:47:04 – 1:51:00
Legacy and advice: risk-taking, learning from failure, and building ‘Star Trek’ futures
In closing, Gosling hopes his legacy encourages people to take leaps of faith despite frequent failures. He advises not fearing risk, learning from mistakes, and making ethical choices in engineering—framing decisions as shaping a Blade Runner vs Star Trek future.
- •Legacy goal: normalize bold experiments and calculated risk
- •Failure as a majority outcome—and still valuable for learning
- •Practical advice: ‘it’s okay to do stupid things once’
- •Ethics in engineering decisions: which future are you building?
- •Preference for optimistic, human-centered technology (Star Trek over dystopia)
