Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Ken Thompson
455
be a teacher because you end up teaching your class over and over and
over. I could never do that. But I love the teaching: the hard work of a first
class, the fun of the second class. Then the misery of the third.
Seibel: What was the first interesting program you wrote?
Thompson: The first long computational program I wrote was solving the
pentaminos problem. Do you know it?
Seibel: The tile game, right?
Thompson: It’s a tile game. And I ran it on an IBM 1620 that was in the
physics department. I knew where all the underground computers were in
the place, and I had them all running at night doing my jobs. Plus, at the main
computer center I probably had 20 accounts under different rocks. There
are 12 pentaminos. These are different tile pieces made out of 5 squares.
And there are 12 different such shapes.
Seibel: Sort of like Tetris tiles.
Thompson: Yes. But every piece has five squares. If you put them all
together on the board there are two configurations that are—I don’t
know—appealing. One is the most square, which is ten-by-six, and then the
second is eight-by-eight with a two-by-two hole in the middle. And I solved
all configurations of those two boards of how you place the pieces for those
boards. And I did it generically by laying out a pattern of the boards and
then laying out pattern pieces, and then it would fit the pieces in the
patterns. It didn’t know it was pentaminos.
Seibel: This was basically brute-force search?
Thompson: Brute force.
Seibel: And so this was also in assembly probably?
Thompson: I have to think. Yeah, it was probably assembly. I can’t
remember.
Seibel: You must have learned Fortran somewhere along the line.
Download at Boykma.Com
Ken Thompson
456
Thompson: Yeah, well, I had to teach Fortran in the computer center and
debug the Fortran programs. I never programmed in it. I wrote a Fortran
compiler for Unix early, and B was an attempted Fortran compiler that got
away from me.
Seibel: I thought B was your translation of BCPL.
Thompson: It sort of was. It started off as—I didn’t know what it was.
Semantically, it turned out to be BCPL. As I started it, it was going to be
Fortran. And at that point I got my first description of BCPL. And I liked the
clean semantics. And that’s when I abandoned Fortran and it turned into
essentially C syntax and BCPL semantics.
Seibel: Is there any really big differences in how you think about
programming or how you practice programming from when you learned to
now? Do you feel like your programming has matured in some way or you
got better at it or you learned things that make you look back and say, “Oh,
man, I didn’t know what I was doing back then.”?
Thompson: No, not really. Sometimes I look back at stuff I did and say,
“Wow. I was much better then.” The period from when I spent that week
reading that program to maybe when I was 30, 35 years old, I knew, in a
deep sense, every line of code I ever wrote. I’d write a program during the
day, and at night I’d sit there and walk through it line by line and find bugs.
I’d go back the next day and, sure enough, it would be wrong.
Seibel: Do you think when you were 35 you could still remember the stuff
you had written a decade before?
Thompson: Yes. Then I started being selective about what I’d remember.
Seibel: Is there anything you would have done differently about learning to
program? Do you have any regrets about the sort of path you took or do
you wish you had done anything earlier?
Thompson: Oh, sure, sure. In high school I wish I’d taken typing. I suffer
from poor typing yet today, but who knew. I didn’t plan anything or do
anything. I have no discipline. I did what I wanted to do next, period, all the
time. If I had some foresight or planning or something, there are things, like
Download at Boykma.Com
Ken Thompson
457
typing, I would have done when I had the chance. I would have taken some
deeper math because certainly I’ve run across things where I have to get
help for math. So yeah, there are little things like that. But if I went back and
had to do it over I’m sure that I just wouldn’t have it in me to do anything
differently. Basically I planned nothing and I just took the next step. And if I
had to do it over again, I’d just have taken the next step again.
Seibel: After school you got hired directly into the Bell Labs; how did that
happen? It doesn’t sound like you were a classical academic researcher at
that point in your career.
Thompson: I just drifted. It was hard to describe. I certainly wasn’t in
school in any real sense. In the formal sense, yes, I was. One of my
professors, who is actually a very good friend, sicced the Bell Labs recruiter
on me. But I wasn’t looking for a job. In fact, I had absolutely no ambitions;
nothing. And he made me appointments to see him in his little recruiting
booth, and I either slept through them or told him I wasn’t interested. And
he kept after me. At some point he called me and said that he wanted to
come over and see me. So he came over to my apartment. And said that he
wanted me to come out and interview at Bell Labs. I told him no. And he
said, “It’s a free trip. You can do what you want to out there.” And I say,
“Well, up front I’ll just tell you that I’m not interested in a job. I’ll be glad to
go for a free trip ’cause I have friends on the East Coast. I’ll go visit them.”
And he says, “Fine.” So that was the interview that I got into. And I went
and spent my two days at Bell Labs and then rented a car and went up and
down the East Coast visiting my high-school friends that were spread out all
over everywhere.
Seibel: Obviously there was something that the folks at Bell Labs saw in
you and said, “We should get this guy into our lab.”
Thompson: I don’t know their side of it. My side of it is that these are
people that I was reading the papers of in the classes I was taking/teaching.
And I knew them by name and reputation. And they were still doing fun
things. To me, work was work and these guys weren’t working. They were
having a good time. Just like school.
Seibel: And so what kind of things did you do when you first arrived there?
Download at Boykma.Com
Ken Thompson
458
Thompson: Bell Labs was in the MULTICS project and I was hired in to
work on MULTICS. And I did. I played with the machines, booted up
MULTICS, and did my little piece of it. At some point, Bell Labs decided that
MULTICS wasn’t for them, and they backed out of the project.
But they had these MULTICS machines which were special-purpose
machines that were just sitting around idle until someone could cart them
away. So for approximately a year I had this machine that was monstrous.
There are maybe two or three of us that used it. So I started doing
operating-system stuff, trying to get a little operating system up and running.
It was insanely hard because it was a real complex computer. But I got it up
where it would sit there and say hello on 50 Teletypes around the building.
And then it went out the door. So I shopped around then and found some
other unused machines and essentially built Unix on these very, very small
PDP machines.
Seibel: Did you have the time to do that because your bosses knew that
that’s what you were doing and said this is a good research project, or was
it just because you were in between jobs?
Thompson: No, I was sort of incorrigible, to be honest. I suspected that I
would eventually get fired, but it didn’t bother me. We were supposed to
be doing basic research but there was some basic research we should be
doing and some basic research we shouldn’t be doing. And just coming out
of the ashes of MULTICS, operating systems was one of those basic
research things we shouldn’t be doing. Because we tried it, it didn’t work, it
was a huge failure, it was expensive; let’s drop it. So I kind of expected that
for what I was doing I was going to eventually get fired. I didn’t.
Seibel: How do you design software? Do you scribble on graph paper or
fire up a UML tool or just start coding?
Thompson: Depends on how big it is. Most of the time, it sits in the back
of my mind—nothing on paper—for a period of time and I’ll concentrate on
the hard parts. The easy parts just fade away—just write ’em down; they’ll
come right out of your fingertips when you’re ready. But the hard parts I’ll
sit and let it germinate for a period of time, a month maybe. At some point
pieces will start dropping out at the bottom and I can see the pyramid build
Download at Boykma.Com
Ken Thompson
459
up out of the pieces. When the pyramid gets high enough in my mind, then
I’ll start at the bottom.
Seibel: But you’re not just building leaves—you know the structure they’re
going to fit into.
Thompson: Suppose someone is describing something to me from
postulates like, “Here’s a computer and here are the op codes.” I can
visualize the structure of programs and how things are efficient or inefficient
based on those op codes, by seeing the bottom and imagining the hierarchy.
And I can see the same thing with programs. If someone shows me library
routines or basic bottom-level things, I can see how you can build that into
different programs and what’s missing—the kinds of programs that would
still be hard to write. So I can envision that pyramid, and the problem is to
try and decompose it and get the bottom pieces.
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.
Download at Boykma.Com
Ken Thompson
460
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
Download at Boykma.Com
Ken Thompson
461
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.
Download at Boykma.Com
Ken Thompson
462
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.
Download at Boykma.Com
Ken Thompson
463
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?
Download at Boykma.Com
Ken Thompson
464
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.
It came back and it was about as close to a design document as we got
except that it had homonyms that you wouldn’t believe. So I went off and
implemented this file system, strictly on a PDP-7. At some point I decided
that I had to test it. So I wrote some load-generating stuff. But I was having
trouble writing programs to drive the file system. You want something
interactive.
Seibel: And you just wanted to play around with writing a file system? At
that point you weren’t planning to write an OS?
Thompson: No, it was just a file system.
Download at Boykma.Com