Ken Thompson's Wife Left for Three Weeks. He Wrote Unix.

Lex Fridman introduces Brian Kernighan as a Princeton computer-science professor who stood beside Unix creators Ken Thompson and Dennis Ritchie, co-authored *The C Programming Language*, co-created the text tool AWK, co-designed the modeling language AMPL, and wrote *UNIX: A History and a Memoir*. Given that list, Fridman calls him one of the most humble and kind people he has had on the show. After the ads, he asks how Unix was created more than fifty years ago. Kernighan starts further back: Bell Labs in 1969, a group just off Multics, which itself followed CTSS.

In the 1950s and early 1960s most computing lived on physically huge, not very powerful machines in large rooms. You wrote a program on punch cards, handed the deck over a counter, and some while later got word that you had made a mistake. Time-sharing took that same computer and attached electric-typewriter terminals, even at a distance. The operating system woke up for each keystroke, remembered the character, and went back to someone else, handing out small slices of time so each person had the illusion the machine was theirs.

CTSS, the Compatible Time-Sharing System, was arguably the first of these, running on an IBM 7094 modified to twice the usual memory: two banks of 32K thirty-six-bit words, about 150 kilobytes times two. By today's standards that is noise; then it was expensive and wonderful. Kernighan spent the summer of 1966 on it in Cambridge, under Fernando Corbató, who had died earlier in 2020. The scheduler itself he claims no clue about. Quiet nights, you get the machine; at noon a round-robin, maybe tuned for editing versus compiling, is the simplest guess.

Multics — Multiplexed Information and Computing Service — was supposed to do everything CTSS did, better, for a larger population. It was meant as a computing utility you could think of as a plug in the wall, the same idea as cloud computing, fifty-odd years earlier. Kernighan, a summer intern, does not think they pictured grandmothers shopping on Amazon, but a grandmother who was a programmer might have used it. Could he have predicted computers today? Absolutely not. The internship did lead to a summer job at Bell Labs the following year, which turned out to be useful.

Bell Labs sat mostly in Murray Hill, New Jersey, fifteen or twenty miles west of New York, with three or four thousand people, many of them PhDs in chemistry, physics, materials, and strong math, plus a growing taste for computing. It belonged to AT&T, whose job was telephone service for the country; Bell Labs' job was to keep making that service better. That mandate funded transistors, fiber, microwaves, and a lot of basic questions. Kernighan was still an intern. He got lucky.

Multics, despite good ideas and good people, did not become the utility on a timeline Bell Labs cared about. It was too expensive, and what was promised arrived much too late. Around the beginning of 1969 Bell Labs pulled out of the MIT–Bell Labs–General Electric collaboration. That left people with a taste for a really nice computing environment and no environment. They started paper designs. Ken Thompson found a little-used PDP-7, an early DEC minicomputer, maybe 16K of 16-bit words, perhaps on the order of $100,000, already a bit obsolete by 1969, and began filesystem experiments.

Then the famous story: Thompson's wife went to California for three weeks with their one-year-old son, and he sat down and wrote an operating system that became Unix. Fridman asks what it takes to do that. Kernighan corrects him first. "I had nothing to do with it. I did not write it. I have never written operating system code." The first Unix was not big: run processes, keep files when the power went off, an assembler Ken wrote, a text editor, a way to load code from the filesystem, give it control, and take it back. Until about 1973 or 1974 it was all PDP-7 assembly. There are no training wheels. Thompson, he says, is a singularity among programmers, several leagues removed, with no disrespect to Fridman or to himself.

Most of the computers in the world now run a Unix-like system. Could anyone have predicted that seed taking over? No. Kernighan suspects a sequence of blind luck more than inevitability, and thinks it is kind of neat. If you have to pick one person, it is Ken, with tremendous contributions from Dennis Ritchie and the labs around them. The systems were small enough that a big picture was still manageable. Assembly is still a daunting way to build anything complex; he has not written it in a long time.

Asked for human stories from the memoir, Kernighan says memory fails, then describes the place. Bell Labs was open, cooperative, and friendly. If you had a problem you talked to someone who might help. People did strange things and tweaked the bureaucracy; most did not take kindly to it, and the bureaucracy put up with an enormous amount. The Unix crowd lived in two or three corridors of one giant building, plus a common space he guesses at fifty feet by fifty feet, with computer access, a coffee machine, and people hanging out. Email existed, all on one machine, so there was no need for an internet. Someone walked into your office.

The philosophy, as he lived it, was a programmer environment. Unix was used for word processing, lab control, and as a front end to big dumb systems, but it was not designed for those jobs. It was meant to make writing programs easier and more productive. Dennis Ritchie observed, near the end of Kernighan's book, that from his standpoint the real goal was a community of people who could work as programmers on a system. Because it was easy to write programs, people wrote interesting ones, other programmers used them, and a virtuous circle followed.

Writing programs in that early Unix was a blast. There was low-hanging fruit, nice tools, a responsive system, and tremendous colleagues. You could have an idea in the morning, something limping that night or the next day, and a colleague saying it was wonderful except where you had really screwed up. The loop was short. Programming is puzzle-solving, which is fun, but it is more fun when somebody uses the thing, even if they whine that it does not work. Use is part of the reward.

Would computing look different without that building? Kernighan reaches for survivor bias. Other places were doing interesting work. Xerox PARC is the obvious one: an enormous amount of what we take for granted came from there. The parent company was perhaps not as lucky at capitalizing on it. Universities were no slouch either. Bell Labs was special. It was not the only special place.

Fridman offers a common story: Unix became open source because AT&T was in the telephone business. Kernighan calls that a mischaracterization. It was very definitely proprietary. It was licensed freely to universities in source form for many years. Generations of students and faculty grew up knowing it, and there was enough expertise in the community for people to go off and build something Unix-like. Berkeley started from that licensed code, picked up enough of its own — notably from Bill Joy — to become free of AT&T code, and then there was a great deal of legal jockeying in the late 1980s and early 1990s.

Richard Stallman started thinking about an open-source movement in the late 1980s. By 1991, when Linus Torvalds decided to do a Unix-like system, the system-call interface and the tools were already a visible target. What people mean by Unix is often Linux. Technically it was not open and it belonged to AT&T. Pragmatically, with a very large number of university licenses that could talk to one another, it felt open. Faculty and students carried that feeling out into the world.

Why was Unix robust and efficient, not only pleasant for programmers? It began on extremely modest hardware. You could not get carried away; you did not have the processor or the memory. That enforced a minimum of mechanisms and a search for generalizations: one mechanism for many jobs instead of special cases. The filesystem is the example. The interface is extremely straightforward, which makes it efficient to write against. Then someone noticed that reading and writing devices could be the same as reading and writing a disk.

Plan 9, in the late 1980s, pushed the idea further: many resources became filesystems sharing that interface. Finding the right model means an awful lot of things become simpler, and more people can do useful work without thinking as hard. Asked whether programming is art or science, Kernighan says some of each. Art is deciding what the program should be and what its users want. Science is algorithms that scale — avoid quadratic when linear is right — and data structures. Engineering is the constraints: time to compute, time to program, who will maintain it. He writes small programs now, often AWK or Python, for class examples and exploratory data analysis. He has not written anything much over a few hundred lines in a long time.

AWK is a scripting language Kernighan built in the late 1970s with Al Aho and Peter Weinberger; the name is their initials. It was meant for quick-and-dirty work on text: counting, selecting, rearranging, summarizing, running a command on each line. It is still exceptionally widely used more than forty years later. What they did not appreciate, he says, is how good the model was for a lot of data processing. With paternal interest, he thinks that among programming languages you get the most bang for the buck by learning AWK. It does not scale to big programs. On "see all the somethings in something," it does pretty darn well. He writes more AWK than anything else at this point.

The joy is default behavior. AWK reads through files, then lines, then matches patterns you wrote; a matching pattern fires an action. That is a quadruply nested loop you never mention. It splits lines into fields, tracks line numbers and field counts, and leaves you the pattern and the action. A five-to-twenty-line Python script becomes one or two lines you can type at the shell. grep is the same paradigm, simpler: one regular-expression pattern, one action, print if it matches. You could write grep in AWK as a one-liner. He uses grep more than anything else because it is convenient and natural.

Why does Windows not have grep as a native reflex? He does not claim it is strictly unique to Unix, but it is focused there. MS-DOS was a pretty pathetic operating system that nonetheless ran on a huge number of machines. In the 1990s Windows became graphical, and Microsoft spent its energy on point-and-click menus, a model that works rather well for people who are not programmers and just want to get something done. Teaching the command line to non-programmers is an uphill struggle. From Microsoft's angle, they were probably right. Cygwin has carried favorite Unix tools onto Windows for at least twenty years; he uses it on his remaining Windows machine. Fridman says WSL, and being able to write Bash on Windows, changed his life.

Kernighan's default machine is a 13-inch MacBook Air, plus a big iMac when he needs a screen. Perfect is too strong a word. The editor is Sam, which Rob Pike wrote long ago at Bell Labs. It postdates both vi and Emacs and comes out of Pike's experience with ed, the original Unix editor. Fridman is an Emacs person; Kernighan never internalized Emacs. He still uses vi sometimes, and Sam when he can, usually downloaded from the Plan 9 distribution.

On the first time-sharing systems, editors were purely command-based. There were no mice and no cursors, because terminals printed on paper. Ken Thompson wrote QED, which was very powerful, then stripped it way down into ed: a line editor. You loaded a file, talked about lines one through last, printed ranges, added, deleted, changed, or substituted within a line. If you changed a line, you had to print that line, using up another line of paper, to see what you had done. CRT displays made cursor control possible without reprinting everything. vi, by Bill Joy, dates from around the late 1970s and took full advantage. Emacs was roughly the same time.

Kernighan's short history of languages starts in the late 1940s with switches, paper tape, and zeros and ones. Assemblers turned mnemonics like ADD into bit patterns and figured out where named locations sat in memory. Tony Brooker, who had just died when they recorded, did Autocode at Manchester, a flavor of assembly a little higher than Alan Turing's language, which you entered in zeros and ones in backwards order because that is how the hardware worked. Each machine had its own assembly language. One instruction per machine instruction; know the machine intimately; change machines and start over.

In the late 1950s people played the game again and moved closer to how people think. FORTRAN from IBM was formula translation for scientific and engineering work. COBOL, with Grace Hopper and others, aimed at business. ALGOL described algorithms. BASIC came a little later. Two things followed. A compiler for each hardware meant you wrote the program once. And a physicist or engineer could write it themselves instead of hiring a programmer — maybe not as good, but pretty good. That democratized code.

The 1970s brought system programming languages for editors, assemblers, compilers, and operating systems themselves: more memory management, processes, a closer but controlled conversation with the machine. C is the survivor. When C programs got large, with no guardrails, C++ came out of that tradition, then an explosion — Java, JavaScript, and the rest. Lisp and functional ideas ran on a parallel track. Fridman still does most of his programming in C, C++, and Python, with a Lisp religious upbringing he cannot quite quit.

Why did C last? Kernighan says it found a sweet spot of expressiveness — you could rewrite things in a pretty natural way — and efficiency, which mattered when computers were four or five generations of Moore's Law weaker. The environment mattered too. Programs written in C ran on every Unix machine, and those machines, including the operating system, were written in C. Portable OS, portable tools, a positive cycle. He and Dennis Ritchie wrote *The C Programming Language* in 1977. Unix was spreading from dozens to hundreds of systems; C was showing up on non-Unix machines; there were no other C books; Bell Labs was the source. He twisted Ritchie's arm until he agreed.

They had no ambition to set a standard. Timing, skill, and luck. Ritchie was a superb writer; the reference manual in the book is his, period. Kernighan spent a lot of time finding examples that hang together and tell you what you need at the moment you should be thinking about it. A good example shows how to do something representative of a job you will actually want, even if not that exact job. Many of the book's examples are Unix text chores: copy input to output, then grep. A lot of programming books, when he looks, give pure syntax. "Here's how you add three numbers. Come on. I could figure that out. Tell me how I would get those three numbers into the computer" and something useful back out, neatly formatted.

Kernighan also co-authored *The Go Programming Language*. About 90 percent of the work, he says, was Alan Donovan's; he is not a Go expert. Go comes from the Bell Labs tradition through Ken Thompson and Rob Pike, plus European influence through Robert Griesemer. On the surface it looks very much like C — people call it C for the 21st century — with better data structuring. What stands out for him is concurrency: communicating sequential processes, the model Tony Hoare set out more than forty years earlier. Goroutines have been, in his few experiments, a natural way to talk about parallel computation, easy to write, typically working, and efficient. Did early Unix people foresee threads and massively parallel machines? He would guess not at a level where you had to do anything. Processors got faster, then stopped because of power and heat, and then there were more of them on a chip.

The variety of languages does not break his heart, but he would love to try more of them. In a spring programming class he writes one small example in as many languages as he can; he is at twenty. The task is a trivial formatter: lines of varying length, rewrapped to no more than 60 characters, about fifteen lines in AWK. He cares how big it is, how fast it runs, and what pain the first step cost, because the first step is the hardest. Lua: download, an hour, never written it in his life. Scala: equally trivial. Haskell: several weeks, ran like a turtle. FORTRAN 90: painful, worked. Rust: several days, because the memory model was unfamiliar and, a few years ago, the documentation would not stay still — examples failed on the version he had. He would like to go back to Rust. He probably will not. You need something you want to do and enough disposable time at once, or learning a language never happens.

JavaScript was treated as ugly; academics would ridicule you for working on it. The language evolved, compiling got fantastically better, and it is a viable back-end as well as front-end. He has written a modest amount and played with translators; he cannot keep up. He does not think it will take over the world. It is worth knowing. The deeper change, Fridman notes, is libraries. Old Unix and C were fun partly because you built it yourself, with maybe a standard library. Today you pip install and down comes another gazillion megabytes of something you cannot inspect. If you are lucky it works; if not, you cannot find which of a thousand packages broke. NPM, he thinks, has even less discipline. There are security and robustness issues. You do not want to run a nuclear power plant in JavaScript. Variety is still good: a dozen languages probably cover 95 percent of programming, and the long tail is a playground, especially functional languages, where ideas like recursion, first-class functions, closures, and lambdas showed up before they entered the mainstream.

Fridman loves AMPL, an algebraic modeling language for linear programming and related optimization: decision variables, constraints, an objective to max or min. The textbook picture is a big matrix A times x less than or equal to b, plus a linear objective. In the real world A is huge, sparse, and unreadable; the mathematics you write on the board is "the sum of this is greater than the sum of that." AMPL is a language for those constraints. Model and data stay separate, so one model wears many datasets, and solvers — linear, nonlinear, convex or not — stay someone else's hard work. Kernighan credits Bob Fourer, a Northwestern industrial-engineering professor, and Dave Gay, a Bell Labs numerical analyst. He is not the expert.

GAMS already existed and looked like clunky FORTRAN. In 1984 Fourer spent a sabbatical in the office across from Kernighan — geography again — and the three of them started talking. Kernighan wrote the first AMPL in C++, his first C++ program, about 3,000 lines, enough to show you could specify a model naturally and turn it into something a solver could import. The solver comes back with numbers; AMPL translates them into how much to buy, make, or ship. Fridman used to send models to colleagues who had never programmed, and they could see the optimization. A language people can read matters more than how fast it is. They wrote a book he typeset in troff, a 1970s formatter that predates TeX by five to ten years. Fridman remembers it as beautiful.

Forced to bet whether P equals NP, Kernighan says no. He has no intuition; he reads colleagues who bet no, and that is the popular bet. Someone asked Jeff Dean under what conditions P would equal NP and got a joke about P being 0 or 1; Dean is a lot smarter than he is. His 1968 Princeton thesis was on big-O notation, before complexity classes were invented, on graph partitioning: split nodes into two equal piles so the weight of crossing edges is as small as possible. With Shen Lin at Bell Labs he never found an algorithm guaranteed to be right, only heuristics that worked pretty darn well, while Steve Cook was showing that some problems really do look hard. Max-cut without the equal-size constraint is easy; add the constraint and it is hard. He briefly worked with John Hopcroft, realized he was not cut out for that talent, and moved toward writing programs and books.

Kernighan's 1964 Toronto senior thesis was a literature survey on artificial intelligence, in what he calls the opposite of an AI winter, a summer. People thought computers would do machine translation, chess, geometry theorems, anything. He drank some of the Kool-Aid in *Computers and Thought*. What looked a few years off took decades. Chess and Go are now better than people; translation is a lot better, after fifty or sixty years, better hardware, more data, and the internet's open-source infrastructure. The lesson reminds him of Arthur C. Clarke: when a distinguished elderly person says something is possible, he is probably right; if he says it is impossible, he is almost surely wrong. You do not know the timescale.

On today's machine-learning summer he is incredibly far from an expert; most of what he knows he learned from students, who are probably disappointed. Games show the potential. The serious problem is that models learn from the data we give them. If the data says something flat wrong — that women are not as good as men — because of historical treatment, the system will propagate it. The optimistic reading is that machine learning puts a mirror to society and helps us remove the bias. He does not know whether it works that way or whether the mechanisms amplify what was already wrong. That has to be taken seriously. What would it take to build human-level intelligence? He has not a clue. The Turing test is interesting and in some vague sense objective; what you can read into the conclusions is another story.

Almost all technologies are for good in the long run, with plenty of counterexamples. Computing everywhere means commercial and government surveillance, an enormous amount known about us. Younger people may feel differently; he is curious what privacy looks like in fifty years. Moore's Law: no exponential goes on forever. If it lasts long enough, that might be all we need. Processors stopped getting faster; the same density now grows horizontally, more processors and memory on a chip, until you near individual atoms. Will we find a way around that? If he says we will not, he will be wrong, so perhaps we will. Jim Keller had just told Fridman there is still a long way before the atom. Programming languages, Kernighan thinks, will keep moving toward programs writing programs, more declarative than procedural: say what you want, let software figure out how, first in narrow domains, then broader, maybe someday in natural language. Abstraction keeps going up.

At Princeton, Kernighan teaches "Computers in Our World" to non-majors, typically history or English. Should everybody learn to program? Probably not. Everybody should understand what programming is, so "I am a programmer" and "a computer running a program decided this" mean something accurate. Students write a very small amount of code on a toy machine with a tiny instruction set, then look up at FORTRAN and C, then at the phone OS and apps they already use. He admits the leap from five lines of assembly to a mobile browser is enormous. In essence it is the same thing. He draws the line there; you can always go lower.

What computers changed, as he sees it, is how people interact. In the 1960s a long-distance call was a big deal because it cost serious money. Today people send texts and sit on video with family anywhere. He emails his brother and sister in Canada every two or three days, far more than he used to phone them; that brought them closer. Campus kids walk with their heads in their phones until he has to duck. Some sociology says people are less close than they used to be. He does not know if that is true. He can see the downside. The next ten or twenty years are mixed: real potential for people to improve their lives, and in the short run more tribalism, more ways to mislead, misrepresent, or lie, affecting politics everywhere. Fridman adds that oppressed people now have a voice, and so does everybody, and the chaos is fascinating and kind of scary.

If he could relive a moment that made him truly happy, he does not pick one instant. He picks a class of them: Bell Labs in the 1970s, Unix young, low-hanging fruit, a group of people who would try what you built and say it was neat. AWK is the example that went worldwide. Millions of people use it every day, which means all of his stupid mistakes are right there for them to look at. Mixed, terrifying, vulnerable, and beautiful, Fridman says, because it affected so many people. Fridman leaves listeners with Kernighan's line: "Don't comment bad code. Rewrite it."