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

Seibel: In the case where you’ve inherited someone’s code there’s a danger in rewriting it that maybe you missed some subtlety to the way it works or overlooked some bit of functionality that it had. Have you ever been bitten by that?

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

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

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

Documenting is an art as fine as programming. It’s rare I find documentation at the level I like. Usually it’s much, much finer-grained than need be. It contains a bunch of irrelevancies and dangling references that assume knowledge 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 to deconstruct 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’s written. If some program relies on other programs or files or data structures, I like to see clear a reference to those where I can go off and read those and they don’t refer back.

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

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

Seibel: In your Turing Award talk you mentioned that if Dan Bobrow had been forced to use a PDP-11 instead of the more powerful PDP-10 he might have 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 less powerful 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 the fact that it was right at the cusp of a revolution of minicomputers. The 10 was the big mainframe run by the computer center. Computing going autonomous instead of centralized was, I think, the really serendipitous part of it. And that rode in on the PDP-11.

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

Thompson: There were good system-programming languages that things were 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 to compile well. I think it was pretty clear from the beginning that you shouldn’t kill yourself compiling well. You should do well but not really good. And the reason is that in the time it takes you to go from well to really good, Moore’s law has already surpassed you. You can pick up 10 percent but while you’re picking up that 10 percent, computers have gotten twice as fast and maybe with some other stuff that matters more for optimization, 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, not take that extra 100 percent of time to do 10 percent of the work.

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

Thompson: No.

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

Thompson: I think MIT has always had an inferiority complex over Unix. I gave 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 have been. Why they had the opportunity, they had the people, they had everything, and why it wasn’t done there. And it dawned on me that there was a rivalry in their minds. Not in my mind at that point. We did Unix and they did MULTICS, which was this monster. This was just clearly the second-system syndrome.

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

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

Seibel: My understanding was that a lot of the MIT hackers viewed MULTICS that same way. They preferred ITS and the Lisp-based systems that they built. It seems there was a real fork post-MULTICS. Unix came out, as you well know, and at MIT these Lisp guys went off and did their things 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. I didn’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’s a great Lisp machine. The PDP-10’s a great Lisp machine. There’s no need to build a Lisp machine that’s not faster. There was just no reason to ever build a Lisp machine. It was kind of stupid.

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

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

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

Thompson: No.

Seibel: From what I’ve read about the history of Unix, it sounds like you used the design process that you described earlier. You thought about it for a 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 well known is a guy named Rudd Canady. In those days at Bell Labs the amenities were great—you could call a telephone number and get a transcription. You know, leave a message and say you want it written up and it’ll appear the next day in your inbox as sheets of paper. And Canady, after we talked about the file system on the blackboard for a little while, picked up the phone, called a number, and read the blackboard into the phone.