In 2002 Deutsch quit work on Ghostscript in order to study musical composition. Today he is more likely to be working on a new musical composition than on a new program, but still can’t resist the urge to hack every now and then, mostly on a musical score editor of his own devising.
Among the topics we covered in our conversation were the deep problems he sees with any computer language that includes the notion of a pointer or a reference, why software should be treated as a capital asset rather than an expense, and why he ultimately retired from professional programming.
Seibel: How did you start programming?
Deutsch: I started programming by accident when I was 11. My dad brought home some memo from the Cambridge Electron Accelerator, which was being built at the time. There was a group that did design computations and some memo of theirs accidentally found its way to him. I saw it lying around his office and it had some computer code in it and there was something about it that caught my imagination.
It turned out the memo was actually an addendum to another memo so I asked him if he could lay his hands on the original memo. He brought that home and I said, “Gee, this stuff is really interesting.” I think I might actually have asked him if I could meet the guy who had written the memos. We met. I don’t really remember the details any more—this was 50 years ago. Somehow I got to write a little bit of code for one of the design calculations for the Cambridge Electron Accelerator. That’s how I got started.
Seibel: So that was when you were eleven. By 14 or 15 you were playing on the PDP-1s at MIT, where your dad was a professor.
Deutsch: When I was 14, I found my way to the TX-0 and to the PDP-1 shortly thereafter. I remember getting a hold of a copy of the Lisp 1.5 programmers’ manual. I don’t remember how. It was a very early version—it was actually mimeographed—the old purple ink. There was something about Lisp that caught my imagination. I’ve always had a kind of mathematical bent, and Lisp just seemed sort of cool. I wanted to have one to play with and I couldn’t get my hands on the Building 26 mainframe. So I did my Lisp implementation on the PDP-1.
Seibel: Do you remember at all how you designed your PDP-1 Lisp?
Deutsch: I’m smiling because the program was so small. Have you seen the listing? It’s only a few hundred lines of assembler.
Seibel: I’ve seen it; I didn’t try to understand it. Was it just a matter of transliterating the thing in the 1.5 manual into assembly?
Deutsch: No, no, no. All that was in the 1.5 manual was the interpreter. I had to write a reader and tokenizer and I had to design the data structures and all that stuff. My recollection was that I did that the way I actually have done most of my programming, which is to do the data structures first. When I was young enough that my intuition would point me in the right direction—I won’t say infallibly, but close enough—that was a really good approach.
In the last couple of years I’ve noticed that I’ve gotten rusty—my intuition doesn’t work so well anymore. I’ve been doing a substantial project off and on for several years now to do a good open-source music score editor. I’ve been fiddling with that off and on for several years now and I find that letting my intuition steer me to the right data structures and then just writing everything out from there just doesn’t work anymore.
Seibel: Do you think your intuition is actually worse or did you used to have more stamina for making it work even if your intuition was actually a bit off?
Deutsch: I think it’s some of each but I think it’s more the former. I think what intuition is, really, is an unconscious process for synthesizing a solution out of a large amount of data. And as I’ve gotten further and further away from being immersed in the stuff of software, the data that goes into that synthesis has become less and less accessible.
I’ve heard it said that to be a master at something you have to have, pretty much at your command, something like 20,000 specific cases. What’s happened is the 20,000 specific cases of software design that passed in front of my face in my 45 years in the industry are just gradually becoming less and less accessible, the way memories do. I think that’s pretty much what’s going on.
Seibel: Do you remember what it was about programming that drew you in?
Deutsch: With the benefit of 50 years of hindsight, I can see that I have always been drawn to systems of denotative symbols—languages. Not only languages of discourse—human languages—but languages in which utterances have effects. Programming languages certainly fall right into that category.
I think that also has something to do with why the career that I’ve switched into is musical composition. Music is a language, or a family of languages, but what you say in those languages not only has denotation, maybe, but it also it has effects on people. Music is kind of interesting because on the spectrum of formality it falls between natural languages and computer languages. It’s more formal and structured than a natural language, but it doesn’t have nearly the structure or formality of a computer language. That, I think, may have to do with why I went into music and not poetry. I think poetry is not structured enough for me.
But the short answer really is, I just gravitated to this stuff right away.
Seibel: Do you remember the first interesting program you wrote?
Deutsch: The first program that I wrote because the content interested me was actually the second program that I wrote. The first program I wrote was some piece of calculation having to do with the Cambridge Electron Accelerator. The second program was a floating-point-output-formatting program.
Seibel: Which is a pretty hairy problem.
Deutsch: Well it is on a binary machine. It’s not a hairy problem on a decimal machine, and I was working on a decimal machine. You just slide the string around and decide where to put the decimal point. You have to decide whether to use the E or F format. But in those days, everything was a lot harder—I was writing in assembly language on a batch-processing machine—so this was not a trivial problem. It wasn’t a hard problem but it wasn’t a trivial one. That was the first program that I wrote because I wanted to.
Seibel: So you were hanging out at MIT during high school and then you went to Berkeley for college. Did you want to escape the East Coast?
Deutsch: Sort of. I realized that it would be really good for me to go to someplace that was far away from my parents. The three places that I considered seriously were, I think it was University of Rochester, University of Chicago, and Berkeley. That was a no-brainer—only one of the three has reasonable weather. So that’s how I ended up at Berkeley. And it was one of the best things that ever happened in my life.
I was at Berkeley and I found Project Genie pretty quickly after I arrived and stayed with that project until—well there was Project Genie and then there was Berkeley Computer Corporation and then there was Xerox.
Seibel: Presumably at Berkeley you started working on bigger projects than your PDP-1 Lisp implementation.
Deutsch: Oh, yeah. Considerably larger projects at Project Genie. To begin with I wrote pretty much the whole operating-system kernel. The kernel was probably pushing 10,000 lines.
Seibel: How did that change—an order-of-magnitude difference in size—change your design process?
Deutsch: I’m trying to remember what was in the kernel. It was still a small enough program that I could approach it as a whole. There were obviously functional divisions. I know I had a clear mental model of which sections of the program were allowed to interact with which of the key data structures. But in fact there weren’t very damn many data structures. There was a process table; there were ready lists. There were I/O buffers and there was some stuff for keeping track of virtual memory. And then there was an open file table, per process. But the descriptions of all the system data structures probably could have fit on, in terms of C struct definitions, probably could have fit on two pages. So we’re not talking about a complicated system.