Among the engineers walking through the doors at Intel’s Silicon Valley campus is a man whose career dates back to the time of vacuum tube computers. In the early 1960s, Steve Russell was among the legendary programmers at the Massachusetts Institute of Technology's Artificial Intelligence Laboratory. He will forever be known as the inventor of Spacewar!, one of the earliest computer games, which he and his colleagues developed on a DEC PDP-1, the first minicomputer. Russell also wrote the first interpreter for Lisp, the language invented by his boss, Marvin Minsky.

The son of a mechanical engineer turned farmer, Russell was born in Hartford, Connecticut, and moved to the state of Washington at age 12. He got accepted to Dartmouth and MIT, and chose the former before doing his research work at the latter. Russell worked at Digital Equipment Corporation for nine years, then headed back west.

I knew about Russell’s early career before I interviewed him by phone, but figured that he would be retired. That Russell, now in his 70s, has found a way to extend his career at Intel speaks well of both the engineer and the company. Two Saturdays a month, Russell volunteers at the Computer History Museum. A working version of Spacewar! is among the exhibits there, and if you’re lucky, you can play Russell at the video game he helped create a half century ago.

In the early 1960s, you were involved in unusual areas of computer science: games and artificial intelligence. How did that happen?

When I started, there was a fairly clear-cut divide between scientific and business data processing. I was on the scientific side around the time artificial intelligence was just getting organized. [Lisp inventor] John McCarthy was hoping for great things. He was asking the question: now that you want to do artificial intelligence, how would you program it? I wrote the interpreter because I had the experience to do it: it didn’t look too hard and it wasn’t. Later on, John grumbled that perhaps making an interpreter was premature, but people started using it right away.

What was it like to develop an interpreter back then?

The Lisp interpreter was around 12,000 lines of code, all in assembler, and ran on a vacuum tube computer. The chances of getting all 12,000 cards read correctly weren’t terribly high, which made it especially ugly to get the code debugged. You’d send the program in to get assembled and would get a set of binary program cards back. Inevitably, the run would fail, at which point the operators would remove the cards and hand you a thick stack of paper, an assembly listing, which was essentially a long list of octal numbers. From that, you’d try to figure out what to correct, then punch the numbers on more IBM cards and put them at the back of the deck some hours later. This cumbersome process started to change with the DEC PDP-1 minicomputer, which used paper tape instead of cards, and transistors instead of vacuum tubes. Soon after it arrived, some research assistants at the lab created a symbolic debugging system that allowed fixes to be made in five or 10 minutes. Instead of finding a bug per day, you could five or six bugs an hour.

This promised much better “⁠play value,⁠”⁠ and I wanted to try it. That’s one thread of why I wrote Spacewar! [MIT AI Lab co-founder] Marvin Minsky had written a simple display program for the PDP-1 consisting of three moving points that influenced each other. It was kind of fun to play with for an hour or two, but it wasn’t very interactive, and after a while, the patterns decayed into something fairly random. I thought I could produce something better.

Why a game about spaceships?

The PDP-1 arrived at MIT in the fall of 1961, the same year that the Russians and Americans had first put men in orbit. So spaceships were very much in the news. But as very few people knew how to fly a spaceship, so a spaceship “⁠trainer⁠”⁠ seemed like an interesting application and something you could actually do on the PDP-1. I got the usual reaction: “⁠That’s a great idea, why don’t you do it.⁠”⁠ I used the usual excuse back then: that I didn’t have a sine and cosine routine, but eventually Alan Kotok got me one from the DEC library. “⁠All right,⁠”⁠ he said. “⁠Now what’s your excuse?⁠”

So I sat down, and after a few weeks of work, I had a prototype running. Other people soon got their fingers into it. Pete Samson thought my random stars were very unrealistic, so he made a real star chart as the background. Dan Edwards looked at my display code and thought he could make it run faster, so he wrote a special purpose compiler that compiled exactly the right code to display the spaceship outline, thereby keeping the display running at full speed.

Looking back, what contribution do you think Spacewar! make to computer science research?

It’s hard to say. Spacewar! was not the first game played on a computer, nor the first two-player game on a computer, nor the first game played on a display. I think its influence is that it set a standard. About half the PDP-1s were in universities, so many people had played it. And when other computers came out, people would write their own version of Spacewar!, helping spread the program to other hardware. For about 10 years, it ran on three different platforms, all expensive machines that required a research budget to purchase. But when computers and displays got cheap enough, an arcade version appeared. There were at least three of those.

As your mandate was to do scientific computational research, where did computer games fit in?

A game is an interesting programming exercise. It’s frequently more rewarding than the run-of-the-mill scientific computation, which typically produces a lot of numbers and obscure graphs--neither of which will impress your girlfriend. I’ve often said that if playing games is fun, writing them is even more fun.

How has the profession of computing changed?

From a development standpoint, the ability to debug programs more quickly stands out. The AI people led the charge to interactive computing because they had grand plans for big complicated programs. Anyone who used the PDP-1 understood that it represented a much better way to get code debugged than with batch processing. The only issue was how to make the hardware cheap enough so people could use it.

What’s your assessment of where has Lisp has wound up?

As a programming language, it’s a little cranky. The newer languages are somewhat better in helping you debug your code. Its natural successor is probably Scheme, which has also been around for a while. One problem with original Lisp is that it’s interpreted, which makes it kind of slow. And it’s a single-type language, which means it gives you no help in keeping your thoughts straight. You have to be clear in your mind of the intended type of every variable, because the language won’t tell you when you’re being inconsistent. C is a little better in that regard, while strongly-typed languages like Pascal and Modula are much better at requiring consistency. I think that’s useful because instead of having to debug the code, you just get a message from the compiler that says, in effect: “⁠You’re confused--right here.⁠”⁠ That specificity saves you a lot of time.

Has something been lost in people not being able to do assembler?

People still do things in assembler. Essentially every system programmer, anyone developing a compiler or doing demanding applications like games will have some pieces of code in assembler and some in a higher level language. Of course, it’s inherently processor-dependent. I had one prospect who faced having to rewrite his entire code because he needed to go to a new chip. But who didn’t want to convert to C because he never learned it in college. I think I was a little rude to him.

What do you do now?

I’m consulting at Intel, being a hack programmer on a secret project.

You’re not retired?

I didn’t retire because I’m not super comfortable financially, and I admit that, at age 70, it can be a pain to put in a 40-hour week. But I’m still reasonably happy. And programming is still fun, and I’m surrounded by a lot of interesting people who are smarter than I am. My colleagues include people from all over the world, many with recent PhDs in computer science associated with hardware and software design.

So a man who began his career on a vacuum tube computer is working at Intel. What has changed? What’s your working day like?

The cubicles are smaller, and there are more of them. Judging by the parking lot, Intel seems to have a lot of people who work irregular hours. They have learned a number of lessons about developing hardware that Digital never learned, and they seem to have it relatively together, although they have some strange opinions. We are working on a relatively big system that fortunately gets recompiled frequently to make sure that everything still works, which is a very good practice. We do tend to sit around waiting for the compile and build and test processes to get done. Ironically, one of the reasons for that is because we don’t have enough CPU power to do all the tests in parallel. Now if there is one place where CPU power is cheap, it should be the Intel production line.

What is your advice for staying relevant in your profession?

Have multiple skills. Among software engineers, I’m a really good writer and among writers, I’m a remarkably good software engineer. That combination is not too common. I also have a relatively high level of understanding of what computers do and the ability to dig down into the ugly details when things don’t go right. Of course, that’s changed over the years. Back in the vacuum tube days, you’d expect a computer to fail several times a week. The PDP-1, which was hailed as more reliable because it used transistors, would still fail several times a month. Now, you can go for years but things can still go wrong, but the experience is still useful for determining whether a problem is related to hardware or software.

What about the future?

I have trouble thinking about what the future is going to be or drawing too many generalizations from the past. I’m more interested in what interesting projects we can do now. I think a good project is like a good story: there should be some conflict, some obstacles to overcome, some unexpected plot twists and turns, and some unexpected results.