MNEMOSYNEv0.1.2563

Podcasts/Lex Fridman Podcast/Gosling, James

Gosling, James

creator and lead designer of the Java programming language; earlier author of a widely-used early Unix implementation of Emacs

James Gosling: Java, JVM, Emacs, and the Early Days of Computing

Lex Fridman Podcast · Sep 24, 2020

▶ Watch on YouTube

Core ideas

Gosling describes himself as a visual thinker who mentally converts code into pictures of interconnected machinery rather than processing it verbally, which is why he prefers dense code layouts that let him see an entire function at once — a preference that has repeatedly put him at odds with engineering teams who staged literal "interventions" over his formatting style. He traces his path into computing from a PDP-8 at the University of Calgary (4KB of RAM, a Teletype interface, no monitor) through scrap-built electronics projects (a relay-based tic-tac-toe machine wired to a dangerously improvised 300-volt power supply) to graduate work at CMU, where he wrote a Unix implementation of Emacs in C after falling in love with Bernie Greenberg's Lisp-based Multics Emacs. That project spread across nearly every non-military host on the early ARPANET, but Gosling deliberately stepped back from maintaining it (handing it to two developers who would later commercialize it, on the condition it stay free for universities) rather than become "Mr. Emacs" forever instead of finishing his PhD — a decision that seeded his long-running disagreement with Richard Stallman, whose free-software absolutism ("all information must be free," in Gosling's framing) he rejects as effectively demanding that software creators take "a vow of poverty," while still calling himself a strong general supporter of open source as a collaboration model.

A substantial section covers the ARPANET-era internet and the incumbents who resisted its rise: Gosling recalls proposing, in an early-90s Sun paper, that anyone could become a content publisher over IP networks — an idea cable and phone companies rejected because their actual business model (selling captured eyeballs to advertisers, not "delivering content" as most of their own employees believed) depended on gatekeeping distribution. He generalizes this into an account of why large, profitable incumbents (his examples: Kodak's digital-imaging division, which saw its own film business's decline coming on a graph but couldn't justify the necessary quarterly earnings hit) rarely lead disruptive transitions, contrasting them with companies like early Amazon and Tesla that could ignore short-term stock pressure because a founder held a large, patient block of stock. This leads into an extended, candid discussion of "jerk" leadership: Gosling, who interviewed and negotiated with Steve Jobs multiple times, says he liked Jobs personally but could never have worked for him, arguing that yelling at people and name-calling crossed from legitimately pushing people to excel into needless cruelty — and that Silicon Valley's mythologizing of Jobs's (and, by extension, Elon Musk's) harshness as the cause of their success is a harmful and false lesson, since he knows many successful, non-abrasive leaders (citing Google's Larry Page, Sergey Brin, and Sundar Pichai) who simply don't generate the same press coverage.

The episode's technical core is Java's origin. Gosling describes a small Sun team in 1990–91 that, worried the computing industry was missing major shifts happening outside it, took fact-finding trips to consumer-electronics companies in Japan, Korea, and Europe — observing both that these companies were repeating decades-old computer-networking mistakes, and that they treated their customer relationships as inviolable in ways the computer industry didn't (never trading off reliability for performance, unlike, e.g., Cray deliberately introducing statistical error into division for speed). Motivated initially by C's dominant role in security vulnerabilities (pointer bugs and buffer overflows — Gosling notes with dark amusement that a 2020-era study found the same ~60-70% of Chrome's C++ vulnerabilities were still pointer-related, three decades later) and by the industrywide pain of memory leaks and dangling pointers, the team built Java's precursor language, discovering along the way that eliminating "back doors" around object-oriented interfaces (forcing developers to fix the interface rather than sneak around it) dramatically improved large-team software reliability — at the cost of some initial developer frustration. Gosling traces the Java Virtual Machine concept directly to a grad-school side project: rewriting UCSD Pascal p-code (originally designed to run on obscure "Three Rivers" workstations) directly into VAX assembly, discovering that an abstract, portable bytecode could be both cheap to build and higher-quality than existing compiler output — a lesson he later scaled into Java's core value proposition for consumer-electronics purchasing departments, who were "welded" to a single CPU vendor once software was written for a given chip's peculiarities. He also credits standardizing on two's-complement arithmetic and full IEEE 754 floating-point compliance (fighting Intel over their non-compliant transcendental functions) as essential, underappreciated groundwork for cross-platform reliability. On Android, Gosling says he's glad Java succeeded there (having already run on billions of pre-Android phones and in smart cards) but is candid that Android creator Andy Rubin "crossed a lot of lines" in ways that were legally and commercially unnecessary and later erupted into major litigation — while suggesting Android's success was likely inevitable regardless of how it was built.

Closing on personal reflection, Gosling says he's long filtered his technical choices through a simple ethical heuristic drawn from science fiction — "are you building Blade Runner or Star Trek?" — preferring Star Trek's Data over Skynet as his mental model for AI's trajectory, and offers young engineers permission to take risks and fail (noting more than half of his own projects "crashed and burned") while cautioning that the tolerance for repeating the same mistake runs out after the first time or two.

Excerpts

On why eliminating "back doors" around interfaces was a deliberate, if initially unpopular, design choice:

“The whole point of that was to say if the interface here isn't right, the wrong way to deal with that is to go through a back door — the right way to deal with it is to walk up to the developer of this thing and say, change the interface, fix it... it was kind of like a social engineering thing, and people ended up discovering that that really made a difference.”

On why he rejects free-software absolutism despite broadly supporting open source:

“My basic opposition is that when you say information must be free, to a really extreme form, that turns into all people whose job is the production of everything from movies to software — they must all take a vow of poverty because information must be free, and that doesn't work for me... I don't want to be wildly rich, I am not wildly rich, but I do actually — I can feed my children.”

On why he thinks Jobs's and Musk's harshness gets mythologized as the cause of their success:

“It seems like there's come this sort of mythology out of Steve Jobs that the reason that he succeeded was because he was super hard on people... and in a number of corners people start going, oh, if I want to succeed I need to be a real jerk. And that for me just does not compute — I mean, I know a lot of successful people who are not jerks, who are perfectly fine people. They tend to not be in the public eye.”