Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Ken Thompson
475
Thompson: I write mostly in C. I do all my test stuff and toy stuff in C
while Google is C++, strictly C++. It’s no big deal programming in C++, but
I don’t like it. I resist it.
Seibel: You were at AT&T with Bjarne Stroustrup. Were you involved at
all in the development of C++?
Thompson: I’m gonna get in trouble.
Seibel: That’s fine.
Thompson: I would try out the language as it was being developed and
make comments on it. It was part of the work atmosphere there. And you’d
write something and then the next day it wouldn’t work because the
language changed. It was very unstable for a very long period of time. At
some point I said, no, no more.
In an interview I said exactly that, that I didn’t use it just because it wouldn’t
stay still for two days in a row. When Stroustrup read the interview he
came screaming into my room about how I was undermining him and what I
said mattered and I said it was a bad language. I never said it was a bad
language. On and on and on. Since then I kind of avoid that kind of stuff.
Seibel: Can you say now whether you think it’s a good or bad language?
Thompson: It certainly has its good points. But by and large I think it’s a
bad language. It does a lot of things half well and it’s just a garbage heap of
ideas that are mutually exclusive. Everybody I know, whether it’s personal
or corporate, selects a subset and these subsets are different. So it’s not a
good language to transport an algorithm—to say, “I wrote it; here, take it.”
It’s way too big, way too complex. And it’s obviously built by a committee.
Stroustrup campaigned for years and years and years, way beyond any sort
of technical contributions he made to the language, to get it adopted and
used. And he sort of ran all the standards committees with a whip and a
chair. And he said “no” to no one. He put every feature in that language
that ever existed. It wasn’t cleanly designed—it was just the union of
everything that came along. And I think it suffered drastically from that.
Ken Thompson
476
Seibel: Do you think that was just because he likes all ideas or was it a way
to get the language adopted, by giving everyone what they wanted?
Thompson: I think it’s more the latter than the former.
Seibel: It seems there are a lot of people who say, “Gosh, C++ is terrible.”
Yet everyone uses it. For instance, it’s one of Google’s four official
languages. Why do folks continue to use it if it’s so bad?
Thompson: I don’t know. I think it’s losing at Google. Now there are
more people who don’t like it than like it.
Seibel: And they switch to Java?
Thompson: I don’t know. There’s almost no replacement for it. They
complain, but they don’t switch. Graduate students coming out—the people
who are hired by Google—know it. So it’s hard to do anything else. That’s
the reason it keeps going—it saves a tremendous amount of education, re-
education. It gets people productive faster.
Seibel: Are there other languages that you enjoy, or have enjoyed,
programming in?
Thompson: All of the funny languages at one point I’ve taken a step in.
Like for solving equations and stuff: Maple and Macsyma, things like that. For
strings, SNOBOL. Anyway, I’ve played with dozens and dozens of languages,
if they do something that’s interesting.
Seibel: And are there development tools that just make you happy to
program?
Thompson: I love yacc. I just love yacc. It just does exactly what you want
done. Its complement, Lex, is horrible. It does nothing you want done.
Seibel: Do you use it anyway or do you write your lexers by hand?
Thompson: I write my lexers by hand. Much easier.
Seibel: Have you ever done any literate programming, a la Donald Knuth?
Ken Thompson
477
Thompson: No. It’s a great idea, but it’s almost impossible to do in
practice.
Seibel: Why?
Thompson: It’s two representations of the same program that are often
out of phase and conflict with each other. And there’s no way to resolve it.
If something is written well in a programming language, then it’s readable. It
suffices. The comments don’t need to be that parallel. The comments are
maybe for algorithms, or if you do something tricky it’d probably be more in
the form of a warning or something. I’m not a big, gross comment kind of
guy. It’s legendary.
Seibel: When I interviewed him, Knuth said the key to technical writing is
to say everything twice in complementary ways. So I think he sees that as a
feature of literate programming, not a bug.
Thompson: Well if you have two ways, one of them is real: what the
machine executes. One of them is not. Only if one is massively more brief
way than the other is it worthwhile. If it’s the same volume, you read the
one that works. If one is much more terse, much less precise, and you can
get out of it what you need, then that’s great. But very often you can’t get
out of it what you need—you really need the nitty-gritty and then you go to
the other. Depending on what you’re after, you read one or the other. But
to try to have microscopic descriptions of an algorithm, one in the
programming language and one in English—maybe Knuth can do it, but I
can’t.
Seibel: Have you ever read any of his literate programs?
Thompson: Just his stuff in the early papers. Nothing recent.
Seibel: And are there books that you think are particularly important—that
either were important to you or that you would recommend people to
read?
Thompson: I don’t read beginning programming books, so I have trouble
recommending such things. If I have to learn a new language or something
I’ll try to find a book. I prefer much denser books that just give me the
Ken Thompson
478
syntax and semantics rather than chatting me up and telling me what’s good
style and what’s bad style.
When I taught, I would have to select a textbook for my course and would
read all of the textbooks in the area and have to make a selection. So at two
points in time, I knew the basic literature for those courses. But outside
that I don’t read.
Seibel: When you were inventing Unix you had your plan to do the four
pieces that would actually give you an operating system. Then your wife and
kids went away, leaving you free to hack for a month. I assume you put in
some long hours in that month. Why do we do that? Is it necessary? Is it
just because it’s fun?
Thompson: You do it when you’re driven. I don’t think I could have not
done it. The other thing is when the wife and kid are around you have this
synchronizing to a 24-hour cycle. When they go away, I don’t have a 24-
hour cycle. There’s nothing that keeps me and the sun together. And so I
typically sleep on a 27- or 28-hour cycle, sleeping 6 hours. So I drift. When I
get to sleep until I wake up I’m in better shape to work than if I get to sleep
and get up when the kid starts screaming.
Seibel: So that’s when you’re driven by a project and you wake up wanting
to get to the computer to start writing more code. But people also work
long hours because we have this idea that we’ve got to get this product out
the door and the way to do it is for everyone to work 80, 100 hours a
week.
Thompson: That generates burnout. Excitement programming, I never
ever felt stress. I’ve been in other situations too where deadlines—external
deadlines—generate stress. That’s not fun; I don’t like that.
Seibel: You burn out at the end, which is obviously bad, but in terms of
getting things done in the short term, does it work?
Thompson: Usually you’re in a position where such a thing is continual.
That as soon as that deadline is over another one starts coming up over the
horizon. If you’re constantly under deadlines like that, then the next one
Ken Thompson
479
you’ll have less enthusiasm and pretty soon you just can’t live like that. I
can’t.
Seibel: Tied up with trying to meet deadlines is being able to estimate how
long things are going to take. Can you estimate how long it’s going to take
to write a given piece of code?
Thompson: It depends on whether I’m writing it for me or writing it for
production. I can if I’m writing for me. I can live with the quirks. I can not do
the extra ten percent. I can avoid the gaping holes that I know are in there.
Things like that. I can produce it and then clean it up at leisure and still use
it. Maybe that’s a different definition of finished. But if you’re doing it for
production then usually there are other people involved and coordination—
I can’t estimate that.
Seibel: In one 1999 interview you said you didn’t think much of Linux, and
got the Linux guys all up in arms. What do you think of it now about a
decade later, and it’s taking over the world?
Thompson: It’s much more reliable—there’s no doubt about that. And I’ve
looked at the code occasionally. I don’t look at it as much as I used to. I
used to, for Plan 9. They were always ahead of us—they just had massively
more resources to deal with hardware. So when we’d run across a piece of
hardware, I’d look at the Linux drivers for it and write Plan 9 drivers for it.
Now I have no reason to look at it. I run Linux. And I occasionally look at
code, but rarely, so I can’t really tell whether the quality has gotten better
or not. But certainly the reliability has gotten better.
Seibel: Do you ever read code just for fun?
Thompson: In the past I used to; less so now. When I first came here I did
it just to try and get the feel of the place. You’ve got to. There’s so much
unsaid that you’ve got to know.
Seibel: Would you pick a program and completely understand it, or were
you just sort of looking for how do they do things around here?
Thompson: A little bit of both. I’d certainly try to pick the big libraries at
first. I’d look at the main programs of some of the things. The programming
Ken Thompson
480
style here at Google is so bizarre. They take a subroutine call, package it as
an RPC, and store it somewhere static. Which means anybody can call it at
any time for any reason. And then they call generic listening kind of code
and somebody somewhere gets a message, goes off and finds that, and
makes that subroutine call.
Seibel: So that’s a mechanism for distributed computation.
Thompson: Yeah. That’s all this place does. It’s very hard to read. So you
go off and you start reading the binding code. And then this code. And then
the general IPC. That gets you a handle into where you can actually start
reading stuff and understanding stuff. Before that, you can’t understand a
thing.
Seibel: When you work on a team, what’s the structure that you like?
Thompson: Just working with good, compatible people.
Seibel: When you’re working with compatible people, do you favor strong
code ownership: “I wrote this piece of code; it is mine and I’m responsible
for it,” or more shared ownership: “We all own this code together and
anyone can do what they see fit.”?
Thompson: I’ve always worked halfway in between. There’s somebody
who owns it and if you have a problem with it, you mail them or tell them
and their job is to fix it. And then at some point they disappear, they don’t
want it, they don’t fix it, they’re not responsive—then you fix it. The
catchphrase is, “You touched it last.” You own it. So it’s halfway between.
You don’t have a bunch of people going in and modifying the code willy-nilly.
It’s all filtered through an owner. But that owner can change pretty easily.
Seibel: These days there are folks who advocate pair programming,
meaning two people working at one keyboard. Have you ever worked that
way?
Thompson: Something small can be done like that. Very often I’ll be typing
and somebody else, who will obviously be faster at it than I, will sit down
and they’ll type and I’ll talk. I’ve done that on orders of minutes to hours,
Ken Thompson
481
very few hours, to get one thing done that both of us could have done
separately.
Seibel: And did you find that the result was better or it got done faster?
Thompson: The result isn’t better. Probably debugging is faster—as you’re
typing, someone can catch a bug over your shoulder. So I think it will
generate fewer bugs as you go. But I didn’t find it as a philosophy as a way
to go—it just happens.
Seibel: Do you still enjoy programming?
Thompson: Yes. I like small programs. Small, meaning you can do it in a
month. If you’re trying to do some monster task that takes a year, I can’t
keep in it that long.
Seibel: Was that always the case, or have you lost the energy for longer
projects?
Thompson: I don’t know. It depends on the actual thing. Something big
that takes years, like an operating system, you subdivide that and there are
lots of fun pieces, so that counts as multiple small things as opposed to one
big thing. But there are lots of things that are just one big thing, and those I
think I’ve always found difficult. I need gratification, feedback. And if you
have to sit there and work and work and work for days, months and see
nothing except a pile of code, then I have trouble doing that.
Seibel: You’ve mostly worked in research and it seems you’ve had a lot of
latitude to work on what you like, but did it change when it become a job?
Did it take any of the fun out of it?
Thompson: No. It’s always been fun, and mostly because I just selected
what I wanted to do. And even when it was a job, back in college, there
were tons and tons of jobs available. It seemed to me that there were tons
of people who were doing something, whatever it is, and they needed some
little programming task done on the side to aid them. So they were perfect
for me. They were little tiny jobs that I could get into, get in and out in days
and pick and choose which one I wanted to take.
Ken Thompson
482
I think my first one was a humanities professor cataloging Homer’s work.
And he had The Iliad and The Odyssey on cards. He wanted word frequencies
and counts—essentially statistical analysis of these two works. And that was
fun. It was text processing, which just wasn’t done by computers in those
days. So that was my first odd job.
Seibel: In a 1999 interview you talked about how you had told your son he
should go into biology instead of computers because you thought
computers were played out. That was almost ten years ago. How do you
feel about that now?
Thompson: I feel the same. Nothing much new has happened in
computers that you couldn’t have predicted. The last significant thing, I
think, was the Internet, and that was certainly in place in ’99. Everything has
expanded—the speed of individual computers is still expanding
exponentially, but what’s different?
Seibel: Reading the history of Unix, it seems like you guys basically
invented an operating system because you wanted a way to play with this
computer. So in order to do what today might be a very basic thing, such as
write a game or something on a computer, well, you had to write a whole
operating system. You needed to write compilers and build a lot of
infrastructure to be able to do anything. I’m sure all of that was fun for its
own sake. But I wonder if maybe the complexity of modern programming
that we talked about before, with all these layers that fit together, is that
just the modern equivalent of, “Well, first step is you have to build your
own operating system”? At least you don’t have to do that anymore.
Thompson: But it’s worse than that. The operating system is not only
given; it’s mandatory. If you interview somebody coming out of computer
science right now, they don’t understand the underlying computing at all. It’s
really, really scary how abstract they are from what a computer is or even
the theory of computing. They just don’t understand it.
Seibel: I was thinking about your advice to your son to go into biology
instead of computing. Isn’t there something about programming—the
intellectual fun of defining a process that can be enacted for you by these
magical machines—that’s the same whether you’re operating very close to
the hardware at a very abstract level?
Ken Thompson
483
Thompson: It’s addictive. But you wouldn’t want to tell your kid to go into
crack. And I think it’s changed. It might just be my aging, but it seems like
when you’re just building another layer on top of another layer on top of
another layer, you don’t really get the benefit of writing, say, a DFA. I think
by necessity algorithms—new algorithms are just getting more complex
over time. A new algorithm to do something is based on 50 other little
algorithms. Back when I was a kid you were doing these little algorithms and
they were fun. You could understand them without it being an accounting
job where you divide it up into cases and this case is solved by this
algorithm that you read about but you don’t really know and on and on. So
it’s different. I really believe it’s different and most of it is because the whole
thing is layered over time and we’re dealing with layers. It might be that I’m
too much of a curmudgeon to understand layers.