Thompson: It depends on whether I have control. If I have control, sure, itdoesn’t matter. If I don’t have control, it’s someone else’s code, then I’llsuffer. Or not do it.

Seibel: In the case where you’ve inherited someone’s code there’s a dangerin rewriting it that maybe you missed some subtlety to the way it works oroverlooked some bit of functionality that it had. Have you ever been bittenby that?

Thompson: Well, you get bitten, but that’s just part of debugging. If there’ssomething you forgot or didn’t do, when you realize it you do it. That’s justpart of debugging. It’s not complete when you first write something. Youextend it.

Seibel: Once you’ve built a system, do you go back and document it in anyway?

Thompson: It depends on what it’s for. If it’s for me, no I won’t. I’ll put ina usage line if I forget the arguments. And I’ll put in a comment at theheader about what the whole thing does. But very, very brief. If it’s part of asystem or a library or something that’s meant to be published, then I’ll takethe time to document it. But otherwise, no.

Documenting is an art as fine as programming. It’s rare I find documentationat the level I like. Usually it’s much, much finer-grained than need be. Itcontains a bunch of irrelevancies and dangling references that assumeknowledge not there. Documenting is very, very hard; it’s time-consuming.To do it right, you’ve got to do it like programming. You’ve got todeconstruct it, put it together in nice ways, rewrite it when it’s wrong.People don’t do that.

Also, I prefer bottom-up documentation and that’s usually not the way it’swritten. If some program relies on other programs or files or datastructures, I like to see clear a reference to those where I can go off andread those and they don’t refer back.

Seibel: So you’d like to understand code the way you would like to writeit, which is from the bottom up?

Thompson: Yeah. It’s the way I can put a handle on it in my mind andremember. Otherwise I read it and I may understand it right after I read itbut then it’s gone. If I understand the structure of it, then it’s part of me andI’ll understand it.

Seibel: In your Turing Award talk you mentioned that if Dan Bobrow hadbeen forced to use a PDP-11 instead of the more powerful PDP-10 he mighthave been receiving the award that day instead of you and Dennis Ritchie.

Thompson: I was just trying to say it was serendipitous.

Seibel: Do you think you benefited to being constrained by the lesspowerful machine?

Thompson: There was certainly a benefit that it was small and efficient.But I think that was the kind of code we wrote anyway. But it was more thefact that it was right at the cusp of a revolution of minicomputers. The 10was the big mainframe run by the computer center. Computing goingautonomous instead of centralized was, I think, the really serendipitous partof it. And that rode in on the PDP-11.

Seibel: Didn’t Unix also benefit from being written in C while OSs likeTENEX and ITS were written in assembly and couldn’t jump to differenthardware as easily as Unix?

Thompson: There were good system-programming languages that thingswere written in to some extent.

Seibel: Such as?

Thompson: NELIAC was a system-programming version of Algol 58.

Seibel: Was Bliss also from that era?

Thompson: Bliss I think was after. And their emphasis was trying tocompile well. I think it was pretty clear from the beginning that youshouldn’t kill yourself compiling well. You should do well but not reallygood. And the reason is that in the time it takes you to go from well toreally good, Moore’s law has already surpassed you. You can pick up 10percent but while you’re picking up that 10 percent, computers have gottentwice as fast and maybe with some other stuff that matters more foroptimization, like caches. I think it’s largely a waste of time to do really well.It’s really hard; you generate as many bugs as you fix. You should stop, nottake that extra 100 percent of time to do 10 percent of the work.

Seibel: You’ve presumably heard of the essay, “Worse Is Better” byRichard Gabriel.

Thompson: No.

Seibel: He contrasted what he called the MIT style, where correctnesstrumps everything else, and the New Jersey (i.e., Bell Labs) style, wheresimplicity of implementation is highly valued. His theory was that the NewJersey style, which he also called “Worse Is Better” made it possible to getstuff out and running and from there it will get improved.

Thompson: I think MIT has always had an inferiority complex over Unix. Igave a Unix talk at MIT and I was introduced by Michael Dertouzos, I think.He expounded on why Unix wasn’t written at MIT and why it should havebeen. Why they had the opportunity, they had the people, they hadeverything, and why it wasn’t done there. And it dawned on me that therewas a rivalry in their minds. Not in my mind at that point. We did Unix andthey did MULTICS, which was this monster. This was just clearly thesecond-system syndrome.

Seibel: Where MULTICS was the second system after the MIT’sCompatible Time-Sharing System?

Thompson: Yes. So overdesigned and overbuilt and over everything. It wasclose to unusable. They still claim it’s a monstrous success, but it just clearlywasn’t.

Seibel: My understanding was that a lot of the MIT hackers viewedMULTICS that same way. They preferred ITS and the Lisp-based systemsthat they built. It seems there was a real fork post-MULTICS. Unix cameout, as you well know, and at MIT these Lisp guys went off and did theirthings on PDP-10s and built Lisp-based systems which, eventually I guess,begat the Lisp machines.

Thompson: Yeah, yeah. I knew all those guys. I thought it was a crazy job. Ididn’t think that Lisp was a unique enough language to warrant a machine.And I think I was proved right. All along I said, “You’re crazy.” The PDP-11’sa great Lisp machine. The PDP-10’s a great Lisp machine. There’s no needto build a Lisp machine that’s not faster. There was just no reason to everbuild a Lisp machine. It was kind of stupid.

Seibel: Are there any features of MULTICS that you did like but that nevermade it into Unix?

Thompson: The things that I liked enough to actually take were thehierarchical file system and the shell—a separate process that you canreplace with some other process. Before that all systems had some sort of“executive”—that was the typical word for it—which was a built-inprocessing language. Per-process execution. Every time you type to the shelland it creates a new process and runs whatever you typed and when thatdies you come back so that you’re at arm’s length from the thing you’rerunning.

Seibel: So those are all things you did take; there’s nothing you left behindthat you now regret?

Thompson: No.

Seibel: From what I’ve read about the history of Unix, it sounds like youused the design process that you described earlier. You thought about it fora while and then your wife and kid went away for a month and you said,“Oh, great—now I can write the code.”

Thompson: Yeah…. A group of us sat down and talked about a file system.There were about three or four of us. The only person who’s not wellknown is a guy named Rudd Canady. In those days at Bell Labs the amenitieswere great—you could call a telephone number and get a transcription. Youknow, leave a message and say you want it written up and it’ll appear thenext day in your inbox as sheets of paper. And Canady, after we talkedabout the file system on the blackboard for a little while, picked up thephone, called a number, and read the blackboard into the phone.