Peter Seibel - Coders at Work - Reflections on the craft of programming

Modern programming scares me in many respects, where they will just build layer after layer after layer that does nothing except translate. It confuses me to read a program which you must read top-down. It says “do something.” And you go find “something.” And you read it and it says, “do something else” and you go find something and it says, “do something else” and it goes back to the top maybe. And nothing gets done. It’s just relegating the problem to a deeper and deeper level. I can’t keep it in my mind—I can’t understand it.

Seibel:So why not still read bottom-up? The leaves are there, somewhere.

Thompson:Well, you don’t know what are leaves and what aren’t. If it’s well described you can read the English and get it and then you don’t have to read the code. But if you’re actually just given a bunch of code and told, “Read it and try and make it better or try and make it do something else,” then typically I read it top-down.

Seibel:Do you ever write down anything before you start writing code?

Thompson:I usually write down data structures before I write down code. I don’t write down algorithms—no flowcharts, or stuff like that. But the stuff you have to refer to on almost every line of code—data structures.

Seibel: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.

Seibel: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.

Seibel: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.

Seibel: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.

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.