Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Guy Steele
335
Steele: Yes. So if I were walking up to Emacs, I’d say, “OK, let’s take a look
at the code that does ‘forward a character’.” And I won’t completely
understand it but at least it’ll introduce me to some data structures it uses
and how the buffer is represented. And if I’m lucky I can find a place where
it adds one. And then once I’ve understood that, then I’ll try “backwards a
character.” “Kill a line.” And work my way up through more and more
complicated uses and interactions until I feel that I’ve traced my way
through some of the more important parts of the code.
Seibel: And would “tracing” mean looking at the text of the source code
and mentally executing it, or would you fire it up in a debugger and step
through it?
Steele: I’ve done it both ways—I’ve done it with a stepping debugger
mostly on smaller codes back in the ’70s or ’80s. The problem nowadays is
from the time a program first fires up until it begins to do anything
interesting can already be a long initialization process. So perhaps one is
better off trying to find the main command loop or the central control
routine and then tracing from there.
Seibel: And once you find that, would you set a break point and then step
from there or just do it by mental execution?
Steele: I’d be inclined to do it by desk-checking—by actually reading the
code and thinking about what it does. If I really need to understand the
whole code then at some point I might sit down and try to read my way all
the way through it. But you can’t do that at first until you’ve got some kind
of framework in your head about how the thing is organized. Now, if you’re
lucky, the programmer actually left some documentation behind or named
things well or left things in the right order in the file so you actually can sort
of read it through.
Seibel: So what is the right order in the file?
Steele: That’s a very good question. It strikes me that one of the problems
of a programming language like Pascal was that because it was designed for a
one-pass compiler, the order of the routines in the file tended to be
bottom-up because you had to define routines before you use them. As a
result, the best way to read a Pascal program was actually backwards
Download at Boykma.Com
Guy Steele
336
because that would give you the top-down view of the program. Now that
things are more free-form, you really can’t count on anything other than the
programmer’s good taste in trying to lay things out in a way that might be
helpful to you. On the third hand, now that we’ve got good IDEs that can
help you with cross-referencing, maybe the linear order of the program
doesn’t matter so much.
On the fourth hand, one reason I don’t like IDEs quite so much is that they
can make it hard to know when you’ve actually seen everything. Walking
around in a graph, it’s hard to know you’ve touched all the parts. Whereas if
you’ve got some linear order, it’s guaranteed to take you through
everything.
Seibel: So when you write code these days would you present more of a
top-down organization with the high-level functions before the lower-level
functions on which they depend?
Steele: I’d try to present the high-level ideas. The best way to present that
might be to show a central command-and-control routine with the things it
dispatches to beneath it. Or, it might be that the important thing is to show
the data structures first, or the more important data structures. The point
is to present the ideas in an order such that they tell a story rather than just
being a pile of code thrown together.
One of the wonderful things about working at MIT was that there was a lot
of code sitting around that was not kept under lock and key, written by
pretty smart hackers. So I read the ITS operating system. I read the
implementations of TECO and of Lisp. And the first pretty printer for Lisp,
written by Bill Gosper. In fact I read them as a high-school student and then
proceeded to replicate some of that in my 1130 implementation.
I would not have been able to implement Lisp for an 1130 without having
had access to existing implementations of Lisp on another computer. I
wouldn’t have known what to do. That was an important part of my
education. Part of the problem that we face nowadays, now that software
has become valuable and most software of any size is commercial, is that we
don’t have a lot of examples of good code to read. The open source
movement has helped to rectify that to some extent. You can go in and
read the source to Linux, if you want to. Reading the source to TeX was a
Download at Boykma.Com
Guy Steele
337
valuable exercise just because it was a large body of well-thought-out, well-
debugged code.
Seibel: I usually have the best luck reading code when I have a very specific
need to know how something works; what is your mindset reading a
program like TeX?
Steele: Sometimes I’ve got a specific goal because I’m trying to solve a
problem. There have been exactly two times, I think, that I was not able to
fix a bug in my TeX macros by reading The TeXbook and it was necessary to
go ahead and read TeX: The Program to find out exactly how a feature
worked. In each case I was able to find my answer in 15 minutes because
TeX: The Program is so well documented and cross-referenced. That, in
itself, is an eye-opener—the fact that a program can be so organized and so
documented, so indexed, that you can find something quickly.
The other thing I learned from it is how a master programmer organizes
data structures, how he organizes the code so as to make it easier to read.
Knuth carefully laid out TeX: The Program so you could almost read it as a
novel or something. You could read it in a linear pass. You’d probably want
to do some jumping back and forth as you encountered various things. Of
course, it was an enormous amount of work on his part, which is why very
few programs have been done that way.
Seibel: And when you get to the end, what are you going to take away?
Steele: I’ll have a pretty good idea of how it’s organized and I may have
come away with some ideas about how to organize my own code better. I
don’t think I’ll ever be able to write in the style of Knuth any more than I
could write in the style of Faulkner or Hemingway. Nevertheless, having
read novels by those writers will influence my own thinking about English
style a little bit. Maybe I’ll make a conscious decision not to write like
Hemingway for some reason or another. It’s a valuable experience. Not to
mention just the enjoyment of going through a well-written novel or a well-
written piece of code.
Seibel: Have you ever written literate programs?
Download at Boykma.Com
Guy Steele
338
Steele: Not in nearly the disciplined way that Knuth has. It has influenced
my style in that I think about those issues—I will often actually write a
paragraph of prose before beginning to write a subroutine. But I don’t do it
in nearly as disciplined a style. And sometimes I wonder whether he does,
either, when he’s doing exploratory programming before he readies it up
for publication. I don’t know what his process looks like there.
Seibel: So you’ve tried it but it didn’t strike you as something that made
programming much more productive or enjoyable?
Steele: In part I didn’t feel like doing a lot of tool building for myself. The
tools he had built were organized around Pascal and then C. Pascal I could
see but I was quite aware of the flaws in C and I wasn’t sure that using
literate programming tools would suffice to overcome them. If he had built
literate programming tools for Common Lisp I might have jumped over to
them much more quickly.
Seibel: Leaving aside literate programs and back to reading code, do you
find that you can read usually well-written programs from beginning to end?
Or is it always a hypertext that you have to find your way through?
Steele: I don’t necessarily object to hypertext. But I think if a program is
well written, there will be something about its structure that will guide me
to various parts of it in an order that will make some kind of sense. You
know, it’s not just what the program does—there’s a story. There’s a story
about how the program is organized, there’s a story about the context in
which the program is expected to operate. And one would hope that there
will be something about the program, whether it’s block comments at the
start of each routine or an overview document that comes separately or
just choices of variable names that will somehow convey those stories to
you. And one would hope that a good programmer, a really good
programmer, will have given thought to conveying those stories in addition
to the story of what the program actually does.
Seibel: What code have you read most recently just for fun?
Steele: It’s hard to find good code that’s worth reading. We haven’t
developed a body of accepted literature that says, “This is great code;
everybody should read this.” So it tends to be one-page snippets, often in
Download at Boykma.Com
Guy Steele
339
papers, rather than chunks of code out of existing stuff. Probably the code
I’ve read most recently is the stuff that my own team has been producing as
part of the Fortress implementation. And parts of the Java libraries.
Probably the last substantial body of code I read just for fun was written by
George Hart. He’s a mathematician, a specialist in polyhedra. And he has a
very interesting piece of code that will generate and display complex
polyhedra using VRML within a browser. And so he’s got this enormous
body of JavaScript code that constructs VRML code and then feeds that to
the VRML displayer.
I decided to try to enhance it in various ways so I went in and read his code
thoroughly. And then proceeded to try to make various enhancements to it
and understand what was going on: try to make some somewhat funkier
polyhedra and so forth. I also managed to make several bad errors—there
was a relaxation algorithm that tries to spread out the vertexes of the
polyhedra to make it prettier and easier to display, and occasionally I’d
introduce mathematical instabilities which would cause grotesque things to
happen. Tremendous fun, and I was doing this purely for my own edification.
That was probably six or seven years ago.
Seibel: How much did the reading and the modification intertwine? Can
you read sitting at a table with a printout or at a computer without
executing it to see what happens if you twiddle that little bit there?
Steele: Well I did, in fact, print out the code on paper. I would sit at a desk
and read it. And very often mark it up and make annotations and ask myself
questions and things like that. And then I’d go back to the computer and
start typing in things and see how it behaved. And tracing it.
Seibel: In this case you wanted to modify it, so that’s what you did. But
could you get some benefit or enjoyment out of just reading the code? Print
it out, read it, maybe scribble some questions on it, and then put it down?
Steele: Yes. If I had stopped at that point, it would have been a worthwhile
exercise, just having read the code. It taught me something about VRML; it
taught me something about JavaScript, which is that it doesn’t have as many
abstractions as I would like. The dynamic typing was a little bit too free-
form for my taste—in an object-oriented language.
Download at Boykma.Com
Guy Steele
340
Seibel: So let’s talk a little bit about designing software. You’re not coding
as much these days as you used to, but how did you go about designing a
new piece of software? Do you sit down at a computer and start coding or
do you sit with a pad of graph paper, or what?
Steele: I’m being very cautious here because it’s all too easy to have a
revisionist memory and say, “Oh, well, back in the ’70s this is the way I
should have done it so that must be the way I did it.” I’m trying to
remember actual things I did.
Sometimes I would draw flowcharts—I did have an IBM flowcharting
template and pads of such paper. And I learned to program before the
structured programming era, so some of my designs were structured and
some of them weren’t. As I became aware of structured programming I
recognized some of the good ideas in that and I think during the ’70s my
assembly language programming became more structured in nature and I
was thinking explicitly of making if/then/else paths and loops and things like
that and I thought more about the structure of my assembly-language code.
I would often make lists describing the kinds of inputs I wanted to be able to
give to a program and then write down a description of what kind of output
I wanted. Or I would sometimes make up short examples. I recently found
an example of one of the earliest APL programs that I ever wrote. I was
probably 15 or 16 at the time. And what I had was a piece of APL code—
this was the first thing I jotted down on paper before I’d actually tried it out.
And enclosed was another piece of paper, which was an example of what I
thought the input/output interaction would look like. It has bugs in it and
doesn’t match the code and so forth but at least I was struggling to try to
produce some examples of what I thought it would be like to use this
program. It was exactly what I thought the terminal transcript would look
like, on a printing terminal. Here’s a series of interactions that I think we
can cause with this program.
Once I started working on the Maclisp project, that provided a structure.
Nearly everything I did was a new function being added to an already
existing large collection of functions. There were already plenty of examples
of what documentation of functions ought to look like so it was just a
matter of adding to that pile.
Download at Boykma.Com
Guy Steele
341
Seibel: You said you took over the interpreter from JonL, who had been
doing both the interpreter and the compiler.
Steele: We’d collaborate on the design work. I was the junior member so
he’d say, “Here’s a function we should have and here’s how it should work;
why don’t you go code it.” Or, more often, we’d get requests from the
Macsyma implementers saying, “We need something to do this,” and JonL
and I would put our heads together and say, “Well, why don’t we design an
interface that looks this way,” and I then would go off and code it.
Seibel: So those were new language features being added to Maclisp that
had to be implemented in the interpreter and the compiler?
Steele: Yeah, language features. Many of a systems-oriented flavor—they
needed to be able to control resources or allocate pages. I implemented a
new data type called a “hunk,” which was probably the biggest disaster in
language design we ever put in. It was essentially a cons cell with more than
two pointers. It was a desperation move because we were running out of
address space on the PDP-10. Recall that the 10 only had an 18-bit address
space. In a list, 50 percent of the pointers were dedicated to just maintaining
the structure of the list, whereas with a threaded set of hunks, maybe only
one-eighth of the pointers were dedicated to the threading of the chunks so
you’d get better memory usage that way.
Seibel: So you had this stream of requests for features—given that it was
incremental, how did you maintain some kind of coherence? If you just keep
adding one thing in the most obvious way, eventually you end up with a big
pile of kludges that barely holds together.
Steele: There were one or two big reorgs. I think probably the most
notable one was the complete redesign and reimplementation of all the
input/output operations in the language. This was the so-called New I/O
design, something I undertook in, I want to say, 1975 or ’76, somewhere in
there. The goal was that the old I/O system allowed for only one input
stream and one output stream, plus being able to interact with the console.
We realized that it would be a lot more flexible if we could have actual Lisp
objects that stood for I/O channels and then we could have as many as 15
I/O channels open.
Download at Boykma.Com
Guy Steele
342
The other thing that was pushing this was that Maclisp was beginning to be
ported to other operating systems. Every site had its own variant of the
PDP-10 operating system. When we looked at all the customers we had, we
realized there were a half a dozen different operating systems we wanted to
support: TENEX, TWENEX, ITS, TOPS-10, WAITS, and the CMU variant.
So there was a summer when I sat down with JonL and we designed a new
set of APIs. We didn’t call them APIs at the time, but it was descriptions of
functions that could be used to create file objects, open and close them, do
things like “delete” and “rename” in a systematic way, and get directory
listings.
Then there was a point where I took a fresh listing of all of Maclisp on paper
and retreated to my parents’ summer home for a week with six sets of
operating-systems manuals and the listing and spent six hours a day
scribbling corrections and changes in the code.
I had to figure out for each feature, such as the “rename” function, how is
that done, because the details of how you interact with the operating
system to rename a file were very different among those six operating
systems. But it tended to fall into three clusters—the TOPS-20 variants, the
TOPS-10 variants, and ITS.
I spent a solid week doing that, and notice, doing design and implementation
without sitting at a computer terminal. This was all desk work. And then
after a week of that, I came back to MIT and spent the next month typing it
all in and debugging and testing it.
Seibel: Why did you do it that way?
Steele: I did it that way because for every function I had to write, it would
have to be preceded by an enormous amount of research. As I say, I’d have
to read the specification for six operating systems. And I would have to
spend an hour doing that and then write the 30 lines of code, probably
times three. It didn’t seem to make sense to be sitting in front of a terminal
when it wasn’t going to be buying me that much. It’s not as if I could Google
something or access online documentation. I wasn’t spending most of the
time typing. Better to use that desk space for the paper documents in front
of me.
Download at Boykma.Com
Guy Steele
343
Seibel: Are there situations today where you think turning off the
computer and clearing your desk is the right approach?
Steele: Yeah, I still do that. In fact, I find that I literally have to turn off the
computer because if the fan is whirring behind me there’s the lure of
“Check your email, check your email.” So I’ll turn it off or at least put it to
sleep, come over to this table on the other side of the room, and spread
out my papers and think. Or work at the whiteboard or something.
Seibel: I read something where you paraphrased Fred Brooks’s saying
about flowcharts and tables, saying, “Show me your interfaces and I won’t
need your code because it’ll be redundant or irrelevant.” When you’re
working in a language like Java, do you start your designs from interfaces?
Steele: Yeah, I’ve become much more interface-oriented than I used to be.
Descriptions of the inputs and actions and outputs of methods with no
code. I love writing that stuff. I also enjoy writing the code that implements
it, but I do less of that nowadays than I used to. And of course it’s important
to have had an experience doing that so you don’t design impossible
specifications. You should have an idea what the implementation is going to
look like as you design the interface. You should at least have an idea for the
implementation. Then if someone comes along with a better one, that’s fine.
Seibel: Other than the possibility of implementing it at all, how do you
decide whether your interfaces are good?
Steele: I usually think about generality and orthogonality. Conformance to
accepted ways of doing things. For example, you don’t put the divisor
before the dividend unless there’s a really good reason for doing so because
in mathematics we’re used to doing it the other way around. So you think
about conventional ways of doing things.
I’ve done enough designs that I think about ways I’ve done it before and
whether they were good or bad. I’m also designing relative to some related
thing that I’ve already designed before. So, for example, while looking at the
specifications for numeric functions in Java, I’d already done numeric
functions for Common Lisp. And I’d documented numeric functions for C. I
knew some of the implementation pitfalls and some of the specification
pitfalls for those things. I spent a lot of time worrying about edge cases.
Download at Boykma.Com
Guy Steele
344
That’s something I learned from Trenchard More and his array theory for
APL. His contention was that if you took care of the edge cases then the
stuff in the middle usually took care of itself. Well, he didn’t say it that way; I
guess that’s the conclusion I draw from him.
To turn it around, you want to design the specification of what’s in the
middle in such a way that it naturally is also correct on the boundaries,
rather than treating boundaries as special cases.
Seibel: During your time at MIT you were somehow involved in the birth
of Emacs. But the early history of Emacs is a bit hazy. What is your version
of the story?
Steele: My version of the story was that I was playing standards guy. What
had happened was there was this display mode that turned TECO into
something like a WYSIWYG editor. On our 24✕80 screens, 21 lines of
what was in the buffer would be shown on the screen and the bottom 3
lines were still a TECO command line.You’d be typing in these TECO
commands and only when you hit the double almode would they then be
executed. Then there was the real-time edit mode, where it was suggested
that a TECO command throw you in this other mode whereby instead of
waiting for you to type the double altmode, TECO would react immediately
to single character commands. If you type one character, it would do the
command. You type another character, it would do the command. And
most printing characters were self-inserting. Then the control characters
were used to move forward, back, up, and down. It was a very, very
primitive—it looked like a very primitive version of Emacs.
Then came the breakthrough. The suggestion was, we have this idea of
taking a character and looking it up in a table and executing TECO
commands. Why don’t we apply that to real-time edit mode? So that every
character you can type is used as a lookup character in this table. And the
default table says, printing characters are self-inserting and control
characters do these things. But let’s just make it programmable and see
what happens. And what immediately happened was four or five different
bright people around MIT had their own ideas about what to do with that.
Within just a few months there were five completely incompatible GUI
interfaces to TECO.
Download at Boykma.Com