Steele: I’m being very cautious here because it’s all too easy to have arevisionist memory and say, “Oh, well, back in the ’70s this is the way Ishould have done it so that must be the way I did it.” I’m trying toremember actual things I did.

Sometimes I would draw flowcharts—I did have an IBM flowchartingtemplate and pads of such paper. And I learned to program before thestructured programming era, so some of my designs were structured andsome of them weren’t. As I became aware of structured programming Irecognized some of the good ideas in that and I think during the ’70s myassembly language programming became more structured in nature and Iwas thinking explicitly of making if/then/else paths and loops and things likethat 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 togive to a program and then write down a description of what kind of output Iwanted. Or I would sometimes make up short examples. I recently found anexample of one of the earliest APL programs that I ever wrote. I was probably15 or 16 at the time. And what I had was a piece of APL code—this was the firstthing I jotted down on paper before I’d actually tried it out. And enclosedwas another piece of paper, which was an example of what I thought theinput/output interaction would look like. It has bugs in it and doesn’t matchthe code and so forth but at least I was struggling to try to produce someexamples of what I thought it would be like to use this program. It was exactlywhat 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 alreadyexisting large collection of functions. There were already plenty of examplesof what documentation of functions ought to look like so it was just amatter of adding to that pile.

Seibel: You said you took over the interpreter from JonL, who had beendoing both the interpreter and the compiler.

Steele: We’d collaborate on the design work. I was the junior member sohe’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 theMacsyma implementers saying, “We need something to do this,” and JonLand I would put our heads together and say, “Well, why don’t we design aninterface that looks this way,” and I then would go off and code it.

Seibel: So those were new language features being added to Maclisp thathad to be implemented in the interpreter and the compiler?

Steele: Yeah, language features. Many of a systems-oriented flavor—theyneeded to be able to control resources or allocate pages. I implemented anew data type called a “hunk,” which was probably the biggest disaster inlanguage design we ever put in. It was essentially a cons cell with more thantwo pointers. It was a desperation move because we were running out ofaddress space on the PDP-10. Recall that the 10 only had an 18-bit addressspace. In a list, 50 percent of the pointers were dedicated to just maintainingthe structure of the list, whereas with a threaded set of hunks, maybe onlyone-eighth of the pointers were dedicated to the threading of the chunks soyou’d get better memory usage that way.

Seibel: So you had this stream of requests for features—given that it wasincremental, how did you maintain some kind of coherence? If you just keepadding one thing in the most obvious way, eventually you end up with a bigpile of kludges that barely holds together.

Steele: There were one or two big reorgs. I think probably the mostnotable one was the complete redesign and reimplementation of all theinput/output operations in the language. This was the so-called New I/Odesign, something I undertook in, I want to say, 1975 or ’76, somewhere inthere. The goal was that the old I/O system allowed for only one inputstream 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 Lispobjects that stood for I/O channels and then we could have as many as 15I/O channels open.

The other thing that was pushing this was that Maclisp was beginning to beported to other operating systems. Every site had its own variant of thePDP-10 operating system. When we looked at all the customers we had, werealized there were a half a dozen different operating systems we wanted tosupport: 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 newset of APIs. We didn’t call them APIs at the time, but it was descriptions offunctions that could be used to create file objects, open and close them, dothings like “delete” and “rename” in a systematic way, and get directorylistings.

Then there was a point where I took a fresh listing of all of Maclisp on paperand retreated to my parents’ summer home for a week with six sets ofoperating-systems manuals and the listing and spent six hours a dayscribbling corrections and changes in the code.

I had to figure out for each feature, such as the “rename” function, how isthat done, because the details of how you interact with the operatingsystem to rename a file were very different among those six operatingsystems. But it tended to fall into three clusters—the TOPS-20 variants, theTOPS-10 variants, and ITS.

I spent a solid week doing that, and notice, doing design and implementationwithout sitting at a computer terminal. This was all desk work. And thenafter a week of that, I came back to MIT and spent the next month typing itall 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 wouldhave to be preceded by an enormous amount of research. As I say, I’d haveto read the specification for six operating systems. And I would have tospend an hour doing that and then write the 30 lines of code, probablytimes three. It didn’t seem to make sense to be sitting in front of a terminalwhen it wasn’t going to be buying me that much. It’s not as if I could Googlesomething or access online documentation. I wasn’t spending most of thetime typing. Better to use that desk space for the paper documents in frontof me.

Seibel: Are there situations today where you think turning off thecomputer 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 thecomputer 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 tosleep, come over to this table on the other side of the room, and spreadout my papers and think. Or work at the whiteboard or something.

Seibel: I read something where you paraphrased Fred Brooks’s sayingabout flowcharts and tables, saying, “Show me your interfaces and I won’tneed your code because it’ll be redundant or irrelevant.” When you’reworking 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 nocode. I love writing that stuff. I also enjoy writing the code that implementsit, but I do less of that nowadays than I used to. And of course it’s importantto have had an experience doing that so you don’t design impossiblespecifications. You should have an idea what the implementation is going tolook like as you design the interface. You should at least have an idea for theimplementation. Then if someone comes along with a better one, that’s fine.