Seibeclass="underline" If you’re writing a C program, does that mean C code that would define those data structures?
Thompson: No, little boxes with arrows and stuff.
Seibeclass="underline" So you’ve got this big picture, the pyramid. How much do you stick to that plan once you start coding?
Thompson: I don’t stick to code. If I find a different partitioning halfway through, I’ll just hack and go over it. A lot of people I know, when they write a line of code, it’s concrete from then on for the rest of life, unless there’s a bug. Especially if they write a routine with an API and scribble the API somewhere on an envelope or an API list—then that’s it. It’ll never change, no matter how bad it is. And I’ve always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. I’ve never been a lover of existing code. Code by itself almost rots and it’s gotta be rewritten. Even when nothing has changed, for some reason it rots.
Seibeclass="underline" How do you decide when code needs to be thrown away?
Thompson: When it’s hard to work on. I do it much quicker than most people do. I’ll throw away code as soon I want to add something to it and I get the feeling that what I have to do to add it is too hard. I’ll throw it away and start over and come up with a different partitioning that makes it easy to do whatever I wanted to do. I’m really quick on the trigger for throwing stuff out.
Seibeclass="underline" Is that true working with other people’s code as well?
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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" Such as?
Thompson: NELIAC was a system-programming version of Algol 58.
Seibeclass="underline" 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.
Seibeclass="underline" You’ve presumably heard of the essay, “Worse Is Better” by Richard Gabriel.
Thompson: No.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" 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.
Seibeclass="underline" Are there any features of MULTICS that you did like but that never made it into Unix?