Книга: Coders at Work: Reflections on the craft of programming

Dan Ingalls

Dan Ingalls

If Alan Kay is Smalltalk’s father, Dan Ingalls is its mother—Smalltalk may have started as a gleam in Alan Kay’s eye, but Ingalls is the one who did the hard work of bringing it into the world. Starting with the first implementation of Smalltalk, written in BASIC and based on one page of notes from Kay, Ingalls has been involved in implementing seven generations of Smalltalk from the first prototype to the present-day open source implementation, Squeak.

Originally a physicist, Ingalls started programming with Fortran, made a business selling a profiler he wrote while in grad school, and eventually found his way to Xerox PARC, where he joined Kay’s Learning Research Group, which built Smalltalk and explored the use of computers in children’s education.

While at PARC, Ingalls also invented the BitBlt operation used in bit-mapped graphics and coded it in microcode for PARC’s Alto computer, allowing the high–performance bit-mapped graphics that enabled UI innovations such as pop-up menus that we now all take for granted. (At one of Ingalls’s in-house demonstrations of the Smalltalk system, a pop-up menu caused the subject of my next chapter, L Peter Deutsch, to leap to his feet and exclaim, “Did you just do what I thought you did?”)

Now a Distinguished Engineer at Sun Microsystems, Ingalls is working on Lively Kernel, a Smalltalk-like programming environment that runs completely in the browser using JavaScript and browser-provided graphics. He received the Association for Computing Machinery Grace Murray Hopper Award in 1984 and the ACM Software System Award in 1987 for his work on Smalltalk. In 2002 he won the Dr. Dobb’s Excellence in Programming Award.

In our conversation, we talked about the importance of interactive programming environments, why it was a lucky thing he never learned Lisp, and why it’s better to build flexible, dynamic systems and then lock them down rather than building static systems and then trying to add dynamic features.

Seibel: To start at the start, how did you get involved in programming?

Ingalls: Let’s see. I grew up being an inventor in my basement, and physics was the closest I could come to that so that was my college major. I went to Harvard and there was a course on programming in Fortran, which I took.

Seibel: What years would that have been?

Ingalls: I was at Harvard from ’62 to ’66. My two programming experiences were this course on Fortran and there was a great lab in the basement of one of the buildings where I took a course on analog computers. It makes you think completely differently—you’ve got this big patch panel and then just a bunch of circuits that are integrators, differentiators—things that you can wire together to solve all sorts of problems in real time. But it began with Fortran and I loved it from the get-go. I tried to see how much shorter I could make programs, and stuff like that.

As a result I decided that maybe I was interested in electrical engineering. So I came out to Stanford in double E and took some computer-science courses there and really enjoyed that. I didn’t spend that much time with double E. I got into Don Knuth’s course and he had a graduate course on program measurement and I loved that. I actually worked on a program that would analyze other programs and dropped out of Stanford to make a business out of it. I got my master’s the next year, and then dropped out. So we’re in ’68 now, I guess.

Seibel: So it was a PhD program you dropped out of?

Ingalls: Right, in the radio science department at Stanford, which was part of double E.

Seibel: So the program you made a business out of—what was it?

Ingalls: Well, it started out with Knuth, as a part of a seminar I took. The seminar was to measure programs and look at their dynamic behavior.

Seibel: Meaning, profiling?

Ingalls: Yeah. So there was a program that would gobble up a Fortran program and insert counters at every branch point. I made a fancier version of it that also had a timer-interrupt process so that it would keep track of how much real time was spent in various parts of the program.

Seibel: So basically a sampling profiler?

Ingalls: Right. And what was notable about these was that until that time profiling had typically been in terms of memory locations, and it took a quantum mechanic to know what the results were telling you, whereas this came out in terms of your source code and you could see, “Oh, it’s spending all its time here.” This was immediately usable to the user. I recognized, “Whoa! people could be using this.”

Seibel: So you ran your business for a while—is that what you were doing up until you went to Xerox PARC?

Ingalls: Pretty much. In fact, that’s how I ended up at PARC. I wound up spending a bunch of time in local service bureaus. There was a Control Data one and an IBM one. And I would take my program around to these various places and make sure that it ran on their particular computer.

Seibel: And this was profiling Fortran code still?

Ingalls: Yeah. But I found out an interesting thing. Who were the big Fortran users? They’re big scientific computation users. And who are they all working for? They’re all working for the government. Do they care how efficient their program is? Not really. What they really want to do is to show that the computer is overloaded and that they need a new computer and more money. I showed this at a couple of companies and they said, “Jeez, if you had this for COBOL it would be great.”

Seibel: Because no one’s going to give them more money to buy big iron for COBOL.

Ingalls: Exactly. So I wrote the same thing for COBOL. This was my immersion into COBOL. I remember writing the completion routine that would put together the statistics from the timer interrupts. The completion routine wanted to be written in the same language as the thing you’re measuring so that it could all be loaded in together. I may be the only person who’s ever written a hash table in COBOL.

Anyway, that sold great. I can remember several sales calls where I’d go out and as a demo I’d run it on one of their programs and, in the course of the demo, would show them how to save more money than the program cost.

In the process of going around to these service bureaus, I wound up at the CDC service bureau in Stanford industrial park—typically you’re working late at night because that’s when it was less expensive—there was another guy there who had a Fortran program to do speech recognition. He had various speech samples and his program analyzed the spectra and grouped the phonemes and stuff like that. I started talking to him and I said, “Well, jeez, you want to run my program on yours?” So we did that and parted company.

He called me up a couple of weeks later and said, “I’ve been hired by Xerox to do a speech-recognition project and I’ve got no one to help me with the nitty-gritty; would you like to work with me?” So I started consulting with him. That was George White, who went on for a long time to do speech recognition. That’s how I got in with Xerox and also with Alan Kay, because it turned out that my office was across the hall from Alan’s and I kept hearing conversations that I was more interested in than speech recognition.

Seibel: Was the domain of speech recognition not that interesting or was it something about the programming involved?

Ingalls: Oh, it was interesting—it was fascinating. I ended up building up a whole personal-computing environment on this Sigma 3 minicomputer. It used card decks and Fortran was the main thing I had to work with. Out of that I built an interactive environment. I wrote a text editor in Fortran and then something so we could start submitting stuff remotely from a terminal. It wound up being a nice little computing environment, just done in this sort of strange way.

Seibel: This desire for an interactive environment is a theme that’s come up a bunch of times in your career. For example, you wrote the first Smalltalk in BASIC because that was the interactive environment you had at hand. Where did you get that idea that given a problem to solve, the first thing you need is an interactive programming environment?

Ingalls: That’s a good question. I think anything where you get immediate gratification feeds on itself by definition.

Seibel: So what was that first place that you had that immediate gratification?

Ingalls: There were a couple of experiences. I had a chance to work with a semi-interactive PL/I. And a friend of mine was working at an IBM where they had an interactive APL environment. I can’t remember which of those was first. I really remember the APL one. That affected me in a number of ways because of both the immediacy of interaction—seeing your results come back—and the expression evaluation, which is really different from Fortran’s statement-oriented programming.

You still see that now, it’s amazing—the whole C/C++/Java tradition, although it goes in an object-oriented direction, is still statement-oriented. But if it’s convenient to make expressions, it really makes the experience different. To me it brings the mathematics to life more. Anyway, it was one of those two. When I got to Xerox there wasn’t much interactive except the Lisp guys’ stuff. I happened not to be into Lisp. Things would have been different if I were, I expect.

Seibel: How so?

Ingalls: I think I would have gone completely in that direction. And by not having gone in that direction, it left me wanting to do that kind of thing in a different way. I think what I worked on with Alan had that same kind of nice, lively, expression feel, but it included the notion of objects and messages more naturally.

I think if I had been as comfortable in a system like Lisp, I never would have bothered. I would have tried working around it to get objects, but starting with the notions of objects from the get-go and then making that nice and interactive and convenient was, I think, a contribution.

Seibel: Alan Kay has said that both Lisp and Smalltalk have the problem that they’re so good they eat their children. If you had known Lisp, then Smalltalk would have been the first eaten child.

Ingalls: Maybe so.

Seibel: So that’s a nice example of the advantage of some ignorance; it leaves some room for creativity. But sometimes it feels like ignorance is endemic in this industry—that people are unaware of things and wheels are constantly being reinvented with pointy corners.

Ingalls: That’s true.

Seibel: Should we be trying to fix that? Is it just a price that we have to pay so that people can have room for creativity? Or would we be better off if people were a little more aware of what else is going on?

Ingalls: I’m an embrace-diversity guy. The example we just went through, I think, says, “No, let people go whatever way they want.” There will be waste from ignorance, but natural selection will take care of straightening things out. And you will get these occasional sports that take you into the future.

I can think of lots of areas where trying to standardize, trying to all go in one direction, has suppressed creativity. I work at a company that’s supported by Java, so I’m not going to go very far with this, but it is the case that when Java came out—the easiest way I had of measuring it was looking at what went on at OOPSLA—when Java came out not only did work slow down and even maybe come to a halt on other object-oriented programming languages but even in dynamic programming in general. I think that was a loss.

But it wasn’t permanent. People finally realized “Oh, wait a minute, Java has all these great strengths and we’re using it for this and that but we were on to other good things with dynamic programming languages and it’s time to get back to that.” But that’s an example that’s easy for me to see because I’m involved in it.

In a much bigger sense I hate to see computer-science departments that feel their role is to prepare people to work in an industry and the industry is going that way and therefore we have to teach our students that way. It’s exactly the wrong thing to do. What you should be doing with your students is teaching them to think generally—think outside the box and plot the other courses we should be pursuing.

It’s not a simple problem because there is great value to having that whole standard out there. Having thousands of programmers who have worked on thousands of routines and they’re very solid—you can get your work done that way.

It’s a little bit the difference between computer science in the service of production and computer science in the service of moving the intellectual content forward. I’ve been having fun with the Lively Kernel, which is, in a way, trivial. There’s nothing new about it—I’m using all stuff that was there before. It’s built on JavaScript and the graphics you can get in a browser. But it’s been really fun because it’s another kernel like Squeak. Because JavaScript is all there in the browser and the graphics is all there in the browser, the work on the kernel is very tiny. It’s just, how do you bring the graphics to life and how do you build up a little computing environment.

Whenever you do something like that, small enough, then anybody can understand it. If you take a few things out of the equation, like the language and the graphics, then the question is, what is the kernel? And I think that’s an interesting question.

I’m hoping that this—not particularly my stuff—but this kind of investigation might reinspire computer science to do some studies about how do you make a kernel, what other kernels could we build that are even simpler, even more uniform.

It’s like what math did. Math found by symbolizing things that you could simplify a lot of stuff. Then, because of that, you could start to think about bigger constructs. That’s my hope.

Seibel: When you say a kernel, you’re talking about a programming kernel. What’s the core of the Lively Kernel?

Ingalls: What I mean by a kernel, typically, is you put together enough stuff that it can, in some sense, build itself or build other useful things. Squeak is one that really can build itself. The Lively Kernel presumes the existence of JavaScript and some graphics, but it ends up with the ability to edit the graphics so that you can make new graphical things and to edit the programs so you can make new programs. So it’s enough to build all the applications that you might want to build in a browser.

I think in playing this game you get to hide layers that you want to. The question is, where is your playing field. In Squeak the whole language is part of the kernel so it’s got its own compiler and byte-code interpreter. And it’s got its whole graphics system—it’s got BitBlt and all the stuff around that.

It looks like those are an important part of any kernel but you can take them out. You can say, “Let’s assume that we have a dynamic language; let’s assume that we have graphics.” In my old thinking, I would have thought, “Well, there is nothing else.” But it’s not true. What’s left is, how do you put the graphics together to make an interesting user interface environment? And how do you bring programs and scripts up to the level that you can change them?

I was forced, by trying to come up with something that would run without installation, in a browser, to take what was in the browser. What’s in the browser? Well, we’ve got JavaScript and we’ve got a graphics environment. It was a chance to step back from all this and say, “Well, yes there are language kernels, there are graphics kernels, and then there’s this other kind of self-supporting user-interface environment kernel.”

Seibel: In both Lively Kernel and Squeak, from the little that I’ve played with them, part of that kernel that’s not the language or the graphics is this notion of a UI that’s always programmable—it’s got these little handles and so forth that you can do programmatic things with.

Ingalls: Right.

Seibel: I found that pretty confusing. Am I programming? Am I using this application? Sometimes I wished there were a bit more of a distinction.

Ingalls: Yup. This is another of those double-edged swords. I don’t think there’s a simple answer. At the very bottom, it’s a wonderful thing that we’ve built computers that totally allow for change. It’s all random-access memory; it’s all programmable. To me it’s important to keep that liveliness, that malleability, that changeability. If you have a system that’s dynamic and changeable, it’s much easier to then draw boundaries and say, “You can’t change stuff inside of here” than it is to start out with something that’s not dynamic and changeable and then try to make it that way.

If you look at web programming right now, it started out with this textmarkup language and then JavaScript came into the picture to try and make it dynamic. It would have been so much easier to start out with something that was like the dynamic graphics everyone knew about in those days and then make stuff fixed and printable when you needed to.

Seibel: Well, easier for everybody except someone who just wanted to put some text on the Web.

Ingalls: I suppose that’s true. But it’s easier for someone to put a layer, like HTML, on top of that. I think it’s better to have the underlying systems be as dynamic as possible. Then you can put on syntax or type restrictions, or this, that, and the other that make it into a fixed thing. Absolutely there are situations when people are just using a system—you want things to be fixed that don’t need to be flexible. And yes it does seem that if people perceive that it’s flexible, it’s scary to them. If you take the Lively Kernel as it is right now, it’s not at all something that an end user would want. Nobody wants to suddenly see their window tilted at 20 degrees.

Seibel: Or to inspect the code of the button they’re trying to press.

Ingalls: Right, right. Really it’s a demo to try to inspire people who want to go that direction. It’s also very simple so somebody could put in a layer that would make it usable and not changeable in those various weird ways. But yeah, there’s a real trade-off between having things be flexible and general and having things be codified and able to be used as a cookbook and always do what you expect.

Seibel: Do you really think the current Lively Kernel, or some near-term evolution of it, will become a way people are going to build apps, or is this really a thought experiment out of Sun Labs to show people a way of thinking?

Ingalls: Well, it’s definitely a thought experiment. It offers a couple of sweet spots that might actually survive as real products in some sense. It’s got the ability to very quickly do something like, if you wanted to make a red heart and put a message in it and make it throb, and then store that as a web page, you can do all that from within it, never having installed any software. So you get the Lively Kernel and you build this little dynamic thing with a little bit of scripting in it and it’s got the WebDAV protocol to go out and create and store a new web page.

That’s something that’s simple and useful and if the scripting were equally simple, the way the tile scripting is in eToys, I think that a lot of people could have fun playing with that. So that’s sort of a gimmick. But if you take that about two levels more, you’re into stuff that’s actually educational—you could build simple dynamic models that you could interact with. It’s a lot like Flash but it’s simpler and more integrated with programming.

From there, I just think of it as being possibly a nice environment for embedding lots of little dynamic, educational examples. A decade or two ago there was HyperCard and lots of teachers were able to understand that and do useful things in it. It’s really strange that that whole experience didn’t naturally go right into the Web. I think there’s still a role to be filled there with tools as simple as HyperCard and as immediate as the Web. It would be cool if it went that way.

Seibel: You’ve famously been involved in five or seven or however many generations of Smalltalk implementations. Let’s start with the first Smalltalk that you did in BASIC. You had a couple pages of notes from Alan Kay that you had to make real. What did you do?

Ingalls: I just started typing in code. I think the first thing was to validate the execution model. There were just a couple of basic structures that were needed, the equivalent of a stack frame. So I just made, it must have been an array, in BASIC, to do that and put together enough that would execute a piece of code.

Typically with something like that—the word that’s coming to mind is you “breadboard” it—you just do what you need to do to put a structure in place that’s the structure you think you’re going to want to interpret and then try to make it work. I remember the first thing we got to run was six factorial. It’s a really simple example but it involves the process of dynamic lookup and creating new stack frames. And then once you’ve got that working, you come to understand how things are going to go and you find out what’s difficult.

Eventually you figure out where the time’s going and so you improve all those things. Then, in this particular case, once that worked there was the problem of putting a layer on it which is essentially a parser so you can type text into it and get it to go into that structure that you breadboarded. Then you’ve got a little environment and you start learning things.

Then you say, “OK, I see how this works, I’m going to write it in assembly code,” or whatever else. Then you suddenly realize, “Oh, yeah, we need automatic storage management. So how are we going to do that?” It’s one thing after another.

Seibel: So have there ever been things where that sort of just-in-time development either failed to work, or you knew it would not work and you had to do a design in some different way?

Ingalls: Well, you always do what you can and when you’re stuck you always turn away and reflect.

In the spectrum of implementers, I probably err on the side of just making things happen. A lot of that is because I get so much of a thrill bringing things to life that it doesn’t even matter if it’s wrong at first. The point is, that as soon as it comes to life it starts telling you what it is.

And you find out that, yes, maybe you could have done the storage management completely differently, but the really important things you’re learning have nothing to do with that. The first Smalltalks I did used reference counting for garbage collection; probably it would have been better to use something else. For a while there was a certain amount of pain associated with reference counts. But that didn’t matter—the point was the system was up and alive and running and we were learning all this other great stuff about how you put together things with objects, what it’s like to do numerics in an object-oriented style—all that other real progress.

Seibel: I don’t know that you’re that far out on the spectrum, at least among the people I’ve talked to for this book. Though Don Knuth did write TeX in pencil in a notebook for six months before he typed in a line of code and he said he saved time because he didn’t have to bother writing scaffolding to test all the code he was developing because he just wrote the whole thing.

Ingalls: I believe that. There are people who operate completely differently. But for a given person I think that’s just how they have to operate. I know I’ve wasted some time one way or another. But there’s also this side of it, and it’s sort of the archetypal aspect of exploratory programming, which is if it gets you more quickly to an environment that you can learn from, you may find out that some of your original goals don’t even matter. What’s much more important is that other thing over there. And that becomes a whole new focus.

Coming back to this need to reflect and get things right, there have been a couple of times when I’ve done that. The example that comes to my mind is BitBlt. When I decided to do the thing that became BitBlt, it had this challenge to it that I had to sit and noodle for a night or two. Which is, how are you going to efficiently move all these bits on bit boundaries across word boundaries? That was a case where there weren’t any alternatives out in the world for me to work with. And so I thought about that and thought about that and came up with a simple model. It wasn’t somebody else’s spec but I had looked at all the places we were doing line drawing and text display and scrolling so I had a spec in my mind for what it needed to do.

Seibel: Maybe you can explain the basic problem that BitBlt was designed to solve.

Ingalls: The disconnect between wanting to think about the display as just a 1000x1000-pixel screen and the fact that the memory is organized word by word. If you want to pick up these four bits and put them down there, they may be in a different part of the word where you put them down. In fact they might straddle two words. If, on the screen, you’re trying to move this thing to there, it may be that you’re going to have to pick up pieces from two separate words here and lay them down there. And when you lay them down you have to store an entire word. So you’re going to have to insert that into what was there before and mask around it. So it’s a mess.

Then there’s the screen raster—the line-by-line aspect of the screen that gives you two dimensions. BitBlt handles the possibility that the source and destination may have differing numbers of words per scan line.

That was a challenge where there was a clear spec for what needed to happen, and it was also one of these things where you tried to have a very general kernel, because if you do this right, it will not only give you moving things from one part to another, but it will allow you to do overlapping scrolls. And it will also allow you to blend pixels. There’s all this opportunity for generalization.

I tested it and made sure it ran first in Smalltalk, then in assembly, then put it into microcode for the Alto. When finally done, we could do these operations at essentially the full speed of the memory without any delay due to all the yucky masking and shifting because that could all be hidden under the memory-cycle time.

Having microprogrammed computers around was a wonderful motivation because it was clear that if there was a little kernel that would do what was needed, then that could be put in microcode and the whole thing would run fast. So I was always motivated to do that.

The thing I came up with for all of this, it actually came to me as an image rather than anything else, which is, it’s like a wheel. If you think of the source and the destination and word boundaries, it’s like there’s a wheel picking up whole words here and then dropping them off here, and there would only be one shift required—that was the picture that came to me. Then it was just a matter of putting that into code.

So at the center of the BitBlt operation there’s essentially one long shifter, which is picking up words from the source and dropping them in the destination. That was the thing I had to sit down and think about. But once you had that you could do storing of constants this way, you could do the laying down of text, the extraction of glyphs from a font, and putting them down at any pixel location.

Seibel: Back to the BASIC implementation of Smalltalk: that was sort of the primordial Smalltalk, before even Smalltalk-72?

Ingalls: Right. The minute that worked I set off and did this whole assembly-language version—because that’s what I had on the Nova—that was fairly complete. So we used that to debug a bunch of stuff and then, in parallel with that, the Alto was being built. As soon as it was available, we moved over and started running on the Alto. That became Smalltalk-72.

Seibel: So Smalltalk-72 was written in assembler—where along the line did it become self-hosting? You often hear that one of the great things about Smalltalk was that so much of it was implemented in itself.

Ingalls: That was a long time later. Smalltalk-72 had a big pile of assembly code with it. And Smalltalk-76 did, too. The big difference from Smalltalk-72 to Smalltalk-76 was that I came up with the byte-code engine for Smalltalk that had the keyword syntax and it was compilable. Also that classes and even stack frames were real objects, to your point about self-description.

Seibel: Where did you get the idea to write a byte-code interpreter?

Ingalls: That was a mechanism. The big thing that I was grappling with was that Smalltalk-72 parsed on the fly and for two reasons, at least, we needed to be able to compile something that had those kinds of semantics but that didn’t require parsing everything on the fly.

So I came up with the Smalltalk-76 syntax, which is pretty much the Smalltalk-80 syntax. Then the question is, what do you compile that into that will run effectively this way? The only place where it got complicated was in doing what we called remote evaluation—variables you declare up here but they get evaluated down here. This is what ended up as blocks in Smalltalk, which are like closures in other systems.

Seibel: Why not just compile to machine code?

Ingalls: We were still very space-conscious and this stuff wound up incredibly compact compared to anything else around. And it needed to be that compact because we were still trying to run this on Altos that had 96K. Then they came out with the big one, which was 128K. The compactness was important.

Seibel: Meaning the generated code would be smaller because the byte codes were richer than native machine instructions?

Ingalls: Yeah. I also just plain loved the idea and was inspired by Peter Deutsch’s work on the byte-code engine for Lisp. I was further inspired by this synergy—it’s another one of these kernels that could fit in microcode. From the beginning I envisioned it as going into the microcode of the Alto.

Seibel: And the microcode was RAM so you could put the Smalltalk kernel in there and then switch to Lisp and put the Lisp byte-code interpreter in there.

Ingalls: Yup.

Seibel: Then what was the next evolution?

Ingalls: Smalltalk-76 inherited all the same sort of graphics baggage—a lot of special code for line drawing, text display, and so on. But at that time I had done BitBlt, so I rewrote the kernel so all the graphics just used BitBlt and Smalltalk, so that made the kernel much smaller. That was Smalltalk-78, which was the first one we ran on a microprocessor—on an 8086.

But that still wasn’t Smalltalk in Smalltalk. The Smalltalk in Smalltalk wasn’t until Squeak. Smalltalk-80 had a virtual machine spec that was published in the book, but all the implementations were in C or assembly code.

Seibel: What about the compiler?

Ingalls: The compiler was written in Smalltalk. Actually, when we were doing the Smalltalk-80 books, Dave Robson and I—it was mainly his work—wrote a Smalltalk emulation of the byte-code interpreter. As part of the Smalltalk-80 release we wanted to help people build their own virtual machines. We had discovered that one of the most useful aids was a trace of exactly what byte-codes get executed in what order when you first start up the system.

So he wrote an emulator in Smalltalk, because our Smalltalk was getting fast enough that that was a reasonable thing to do, and produced all those traces that would help people debugging.

Seibel: And you wanted to help people write Smalltalk virtual machines because the point of Smalltalk-80 was to be an escape pod so Smalltalk could go out into the world even if PARC decided not to do anything with it?

Ingalls: That’s right. Then I left the industry and when I came back, I wanted to do a Smalltalk for a new project. At that time things were running so fast that, “Wait a minute; why don’t we just try running the Smalltalk version of it and see what that does?” But the “aha!” was, it shouldn’t be hard to mechanically translate that to C and then it would be as fast as the other engines. If you wanted to change something about the virtual machine you could change that in Smalltalk—you could try it out in Smalltalk and then push a button, and it would suddenly be in the production interpreter.

Seibel: So you took this Smalltalk interpreter written in whatever subset of Smalltalk it happened to be written in and wrote a special-purpose compiler that knows how to compile that subset into C?

Ingalls: And the C translator was simply a subset of the Smalltalk compiler—we just had to make the parse trees print out in C. This was actually something we had done before at Xerox—Ted Kaehler had written a virtual memory in Smalltalk, and then we used the same trick to translate that to BCPL. Same thing.

Seibel: When Smalltalk-80 got out in the world there were Smalltalk companies; objects were a big thing; Byte did its issue all about Smalltalk.

The promise was that objects were going to be these reusable components and that programmers would just go down to Ye Olde Object Shoppe and buy some objects and plug them into their program. Has that promise been kept?

Ingalls: I think yes and no.

Seibel: So in what ways has it happened?

Ingalls: Look at the world of Java—it’s that kind of a world. There are huge bodies of software that work well together because of those kinds of interfaces. I think that was all a real step forward. There were several things going on in Smalltalk that did end up in the world more or less. One of them is object-oriented design and interfaces. The other is dynamic languages and user interfaces. It didn’t take over and you can look at various little places in history where things could have been done differently and it might have had a better chance. But I don’t think that’s a big thing lost or gained. The world moves forward slowly. Other things got done that were better. Natural selection takes care of it all.

Seibel: But natural selection can also select some pretty grotesque outcomes.

Ingalls: Oh yeah, Beta and VHS, it’s true. But ultimately, nothing that’s really good ever gets really lost.

Seibel: Another aspect of Smalltalk that Alan Kay has particularly emphasized in recent years is that it wasn’t supposed to be about objects; it was about message passing. C++ and Java don’t have message passing in nearly the same way Smalltalk did. Why is that such a core idea?

Ingalls: Because it gives you real separation. Alan’s latest phrase—which is appropriate, I think—is it should be like the Internet all the way down. We worry about where we have security and various sorts of security mechanisms in programs and there are all sorts of things wrong with them. But the Internet-style separation is a real layer that there’s no way around.

So why is message passing such a good thing? That’s the reason: it separates the inside from the outside, 100 percent. At least, done right it does. And there are other systems that have gone farther with this and I think we’ll see more in that space.

Seibel: So nothing good ever gets really lost. Are there ideas, from Smalltalk or anywhere else, that you wish had been adopted by the mainstream?

Ingalls: I don’t really have wishes for the mainstream—I have things I want to do or that I would like to be easy. My one wish for the mainstream, in the context of computer science, is that people would go back to first principles a little bit more about ways to leverage computing in the intellectual space.

We’ve gotten incredibly good with the programming systems and the languages we know. What if we were that good with logic programming? And had it integrated well? I think we would be doing extraordinarily more stuff in much more of a human-oriented space. It does go in the direction of artificial intelligence. You have to know that at some point we’re going to cross a threshold where computers will be doing a better job thinking about stuff than we do.

I wonder sometimes if we’re unconsciously holding that off. A lot of progress was made, up until 1980, in that area. And the computers are orders of magnitude faster and bigger now. On the latest computer I got, if I run the Smalltalk music synthesis, in Smalltalk, it can compute the radio signal for a radio station. This is hard for somebody who, at one point, could watch simple arithmetic being computed.

So you take that and put it against all sorts of possibilities in logic programming, in rule-based systems, and artificial intelligence, and you have to know there’s lots of progress to be made there. I would like to see the kind of thinking that led to the Lively Kernel—what is a kernel apart from the language and the user interface? What other kernels are there? What if you build a kernel around logic programming and what kinds of things can you do with that? I don’t think that people are playing around with, tinkering with that stuff enough. Because, Lord, the machines we have today—if you have a minor breakthrough there you could do incredible stuff.

Seibel: Smalltalk was originally envisioned as a platform for use in education, right?

Ingalls: It was envisioned as a language for kids—children of all ages—to use Alan’s original phrase. I think one of the things that helped that whole project, and it was a long-term project, was that it wasn’t like we were out to do the world’s best programming environment. We were out to build educational software, so a lot of the charter was more in the space of simplicity and modeling the real world.

Something about having this educational goal made it easy to keep inspiring the lower-level stuff to be as simple as possible. So there were lots of things we did that didn’t run as fast as you might like. The first Smalltalk-72 system was really slow—the second revision on it ran about 20, 25 times faster. But we had it running, by God, and we were able to use it with kids and learned a huge amount before even trying a second version.

We focused a lot on getting some cool graphics to work, bitmapped graphics, music, and putting it together in a fairly simple language. What we learned from that did actually make a seriously good language. So after Smalltalk-72, we did Smalltalk-76, which was essentially Smalltalk-80. And I saw that that could be a serious programming environment for the industry. There was some tension there with Alan because he wanted to not get scattered in that direction.

It wasn’t too much longer before he left Xerox, and so we pursued those separate paths. But that was because we had discovered some things. For instance, our turnaround time for making changes in the system from the beginning was seconds, and subsecond fairly soon. It was just totally alive. And that’s something which I, and a bunch of the other people, got a passion for. Let’s build a system that’s living like that. That’s what Smalltalk became. So that then became a new goal, which then spun Smalltalk-80 off. Squeak was a return to that, but with the doing-it-in-itself bit added.

Seibel: So you and Kay followed, as you say, separate paths. Did you become disenchanted with the original Smalltalk vision?

Ingalls: No, not at all. I’ve talked about my training as a physicist, and I think it’s in my nature to look at the world—how it works, how forces are, how the planets move, how the winds blow, and all that stuff—as asking questions about it and really being in touch with the phenomenon. In the physical world, at least, that’s easy. You can zero in and come away with an understanding of, “Yes, that’s how it works.”

In computers I think there’s the same kind of thing. You should be able, in a computing environment, to zero in on music and musical synthesis and sound and just understand how the whole thing works. It should be accessible. The same thing with graphics. It’s put together very much the same way. You’ve got atomic things, which are the various graphical effects, and then you’ve got structural things you put them together with. The same thing’s the case for numerical calculation.

When I take somebody new with Smalltalk, I’ll say, “What interests you, taking text apart? Playing with numbers? Looking at graphics? Or playing with music?” And then we start there and do a deep dive on that. It’s very much still a part of my passion, and I’m sure Alan’s too, to take people through some deep dive in a direction that they’re motivated about so they come away with what Alan calls powerful ideas—the “aha!” that lets you see this amazing variety is really a couple of small, general things at work.

You can see that in music. You can see it in graphics. You can see it in numbers and text manipulation. And it’s really exciting to me to make that available and accessible.

The Squeak environment is really a computer scientist’s environment. The eToys environment is a kids’ environment, but not as comprehensive as it could be, and I still feel there’s a thing we haven’t done out there, which would allow you equally intuitively to dive in and get a physical understanding of those powerful ideas.

I’m still as passionate about that as anything. Why I’m here doing this stuff—JavaScript and the browser—is that we’re getting pretty close to being able to put Squeak-like material on a web page that you can browse from any browser and interact with in some nice, self-revealing way. That’s part of this whole picture. I’m sure it’s going to change. Browsers are going to change. We’ll get other languages besides JavaScript, and I’m still totally in touch with Alan and his group, who are doing another take on this going deeper down and trying to solve some of these other things more seriously. But it’s absolutely still the same vision.

Seibel: You mention four disciplines: music, graphics, mathematics, and text. Those are about as old as humanity. Clearly there are powerful ideas there that are independent of computers—the computer just provides a way to explore them that might be hard without the computer. Is there also a set of interesting, powerful ideas inherent in the computer? Is programming or computer science another deep discipline—a fifth area—that we can only do now that we have computers?

Ingalls: Yes, I think that’s what I am getting at. The curriculum I’ve always envisioned is one in which you start with one of these and maybe from the motivation of going deep in one of those areas, you move over to one of the other ones that’s less familiar and do a similar thing there. And a lesson to be learned is that the way in which you get to those simpler, deeper structures that generate that whole field is similar in every case.

There’s an algebra of graphics. It’s primitive objects, superposition translation, rotation. Or music. It’s notes and temporal sequences and chordals—same thing. And I think this goes back to seeing how the wind works and how the planets move. It’s an invitation to go down and find out how things work and learn the things that make up the algebra—the processes and the primitive things. So yes, that fifth area, as you call it, is just what’s common about all of these things.

Seibel: Would you expect someone who has played with three or four of these areas to end up learning how to program? Or is that just one of the things that could happen if their interest happened to go down a particular channel?

Ingalls: I think it’s just one of the things that could happen. Hopefully you’ve sharpened their thinking skills. Both by introducing them to stuff and by getting them excited about stuff in some way or another. But there are people who are going to like programming and there are people who are not. I’ve got a 12-year-old son and all he wants to do is do 540s on skis, and there’s a time and a place for everything.

Seibel: Back to some nitty-gritty: how do you test your software?

Ingalls: It depends what I’m doing. I always set it up for the most immediate gratification. So when trying to do something new, I just think of what would be the first piece of success that’s achievable. And it’s different in every case. If I had a more normal life, in more normal programming teams, I’d probably be totally into the current way of team programming. But for me, it’s much more self-induced—even down to a question of my attention span. If I think I could get this working over the weekend, then that’s the chunk I pick and that’s the thing that I go flat out for, ignoring all the other things. It’s hard for me to generalize this except to say, there’s a place you want to get to, you pick a piece of it that would be gratifying and that would demonstrate that you’re on the path and that you can fit into the time until you next get pulled off to do this at home or that at work.

Seibel: Since you’ve picked something that’s going to have some kind of gratifying result at the end, that’s your first test—an acceptance test: does it draw a window on the screen or whatever? What about finer-grained tests?

Ingalls: If it’s the first time you’ve made it possible to pick something up and drag it over and drop it down, there’s a framework that you need to have working there. Is the framework factored so that someone else coming along will see that these are the tests? That’s something that I have not typically done. This may just be the luxury of my generation—nobody would get away with that these days. But I’m an old fart and they’re not going to make me do it. But I think the underlying feeling is still the same. The Squeak code used to be full of comments that are executable and things to check. For instance, in lots of the BitBlt tests, there are these little things that will pick something up from one place on the screen, do something to it, and put it back, and if you see anything change on the screen, it’s not working right and the comment says so. That’s a straightforward test.

Seibel: So let’s talk about working with others. The Learning Research Group at PARC sounded like a pretty close-knit group. How did you collaborate on the code itself?

Ingalls: Just by being close. And occasional mayhem. It was never a big group and we each had our own areas. There’s a lot of team programming expertise that’s grown up and I’m not up on it at all. Right now, in the Lively Kernel, the kernel part has been just me and one other guy, Krzysztof Palacz. And we sort of have our separate areas that we work on. We actually do use a code repository now, and there are other guys on the team who are doing more application stuff and a little bit in the kernel. And I see that it’s nice having a shared repository that works—that’s great. The next step for the Lively Kernel is to integrate it with the repository—you can change stuff in the Lively Kernel but it’s only that running version; it doesn’t get pushed out to the repository and become a part of the future. That’s the next step we need to do.

Seibel: Have you ever done pair programming?

Ingalls: I’m trying to think of examples. Usually I’ve been on my own or working on a separate part. There are lots of projects on which I’ve worked with others, and many intense pair debugging sessions.

Seibel: Are there any techniques for managing that kind of collaboration? When everybody goes off to each do their own work, there’s always the potential of things not quite fitting together.

Ingalls: Either you agree on some interface, or often I’ll build some framework that’s incomplete but that works for one example and then it’s obvious to someone else where their stuff would fit in. Or they’ve done that and it’s obvious to me where my stuff fits in. It’s usually been in that concrete way, rather than any kind of spec because we’ve usually been working on something that nobody wrote down. It’s all kind of been following the needs of the moment.

Seibel: You’ve worked at a lot of levels from down in the bits of BitBlt and writing microcode up to fairly high-level stuff in Smalltalk. How much do programmers need to know about the various levels of software and hardware they’re dealing with?

Ingalls: That’s a good question. To think outside the box, you’ve got to be a little outside the box. If there’s something to be taken advantage of that you don’t see in your normal exposure to a language, then you’ve got to have some intuition outside and some understanding of that and the ability to work in a system that has control over that.

In the context of language design, maybe you’re going to want to work with the processors that are out there so maybe you don’t need to know a lot about them, other than, for decent performance, how caching works and that kind of stuff. I think you have to stand back and say, “What boundaries is this going to cross?”

Seibel: Leaving aside how much you need to know eventually, when it comes to learning to program, some people say you should start with a high-level language and learn certain universal concepts. Other people say you need to start with assembly and work your way up so you understand what’s going on. Do you buy that?

Ingalls: No, I don’t think I necessarily buy that. That’s how I learned it and I was fascinated with it. And I think there will always be people who are fascinated with this level or that. But I don’t think there’s any one way, just like there’s any one way to do art.

I think there are other things that are equally exciting and probably more appropriate nowadays still to be explored. Lord, we were thinking of doing artificial intelligence a quarter of a century ago. The machines are immeasurably faster and we’re doing almost nothing in that space—we’re still doing very close to Fortran. Prolog has been out there for a long time; there’s all sorts of stuff that can be done with logic programs. If you ought to learn about assembly and find out how that works, you ought to be doing some immersion in things that are more outside the box and that are really a possible piece of the future.

So I’m not saying, “not assembly language.” I’m saying, you should learn some of these other powerful techniques so when you think about how to go forward, you can take advantage of them. In terms of a place to start, immediate gratification has always worked for me. When I want to teach somebody Smalltalk, I usually start with a little dialog: “What interests you most? Are you interested in how to play with text or things you can do with numbers or things you can do with music, or things you can do with graphics?” And start with any one of those.

There’s all kinds of fun stuff you can do taking text apart and putting it together. There’s all kinds of fun stuff you can do with numbers and different bases and floating-point and fixed. And the same thing with music: you can start with notes and put them together in melodies and chords. And with graphics: superpositions and rotations. Any one of those is a rich space to explore. I really think different people think differently that way. Similarly, if you’re going to teach somebody to program a computer, maybe you work with expression evaluation, maybe you work with logic programming. Maybe you do some stuff in user interface. People will light up in one area and that’s where they should go deep.

Seibel: As I understand it, the original purpose of Smalltalk was to teach a kind of programming literacy. Is that something everyone should have, just the way everyone is expected to be able to read and write and do a little bit of math? Should everyone have some ability to program a computer just because it’s a useful way of thinking?

Ingalls: It’s very hard for me to say that anyone should do anything, because I’ve met people that I think are better than me in this way or that way that know nothing about programming. In terms of literacy, the stuff that’s under there is logic and math and yes, people should be able to think logically. But I’d never say that somebody should know how to program, I don’t think. There’s stuff we do in everyday life that’s like programming. You need to know about procedures with steps, that kind of thing.

Computers incorporate some powerful ideas and can bring some powerful ideas to life. The wonderful thing about computers is they bring mathematics to life. So they can be a great tool that way. Now, my feeling about the powerful ideas that are necessary to lead a good life, it’s not clear how many of them are in this space.

Seibel: Seymour Papert wrote in Mindstorms about debugging as an important element of an intellectual toolkit—the idea that the name of the game is not to get the right answer but to get an answer and then debug it.

Ingalls: Oh, absolutely! People should learn to think clearly and to question. And to me it’s very basic. If you grow up in a family where when the cupboard door doesn’t close right, somebody opens it up and looks at the hinge and sees that a screw is loose and therefore it’s hanging this way vs. if they say, “Oh, the door doesn’t work right; call somebody”—there’s a difference there. To me you don’t need any involvement with computers to have that experience of what you see isn’t right, what do you do? Inquire. Look. And then if you see the problem, how do you fix it? To me that’s so basic and human and comes so much from parent to child.

Computers are certainly a medium for doing that. But they’re just computers. There’s a lot of that that will transfer, but to me it’s really big and basic and human, so it’s not like we’re going to enlighten the world just by teaching them computers.

Seibel: Do you remember the first interesting program you wrote?

Ingalls: Oh, let’s see. In each programming experience, there was something that was out of the box. When I discovered VisiCalc, I wrote a spreadsheet to translate English to pig Latin in VisiCalc. That was, to me, interesting, because it used the spreadsheet metaphor as a parallel programming approach. Parsing text that way was fun and enlightening.

Seibel: So VisiCalc had primitives for taking apart strings?

Ingalls: Yeah, you could take apart strings. Maybe what I actually had was Lotus 1-2-3, not VisiCalc, because I’m not sure that VisiCalc had string primitives. I got one of those little Poqet PCs—it was the first truly handheld PC. It ran on two penlights, and I put 1-2-3 on it, and I had a plane flight across the country and I thought, “What can I do in this time?”

Seibel: That must’ve been well after you learned to program, because there obviously weren’t Poqet PCs when you were starting out.

Ingalls: That was later on. The really interesting thing that I did in Fortran was I got a hold of Val Schorre’s paper on META II—just a wonderful, really simple compiler compiler and wrote an implementation of that in Fortran. So all of a sudden this meant you could have other languages in a Fortran only environment. That was the most interesting thing I did in Fortran, because it used Fortran to escape from the world of Fortran.

Seibel: That seems to be a bit of a theme: the pig-Latin spreadsheet, then this, and a hash table in COBOL for your profiler—is there a part of you that just likes cutting against the grain?

Ingalls: I don’t feel like it’s against the grain, but whenever I have a computing environment to play with, I like to try new things in it. That’s what’s been so much fun about doing the Smalltalk systems I did. You start from pretty much scratch and your job is to figure out what to assemble and get working first that will help you to do the next step and build stuff up from there.

In these cases, it was a matter of getting outside the box. That’s a way of asserting that you’ve mastered the thing—if you can do some things that you wouldn’t have thought you could do in it.

Seibel: Can you identify any big changes in the way you think about programming now?

Ingalls: That’s a good question. One thing is we’ve got lots of computer cycles to spend. So I’m comfortable now, as the pejorative saying goes, pissing away cycles to get something done cleanly. But the basic thing hasn’t changed for me at all, which is trying to get clear about what the kernel or kernels are that I have to work with and the goal that I’m trying to achieve.

It’s changed a little bit in that I’m no longer the quantum mechanic in the group that I work in. I’m more at a higher level—that just means that I’m spending a little bit more time on goals and politics than on code. It’s got more to do with creating a context. Until this later phase of my life, I’ve been lucky to be in an existing context where I didn’t have to create it. But every once in a while I still get down and write serious code.

Seibel: I was looking at one of your papers from the ’70s about your Fortran profiler. In the preamble you were very enthusiastic about how that tool changed your programming from figuring out what you were going to write, writing it, and debugging it, to figuring out what you were going to write, writing a really simple version, profiling it, then optimizing it. Do you still work that way?

Ingalls: I definitely go for effects first, bits on the screen or whatever it is, because that’s so motivating, and you often learn something new about what you had wanted to do just by getting a chance to glimpse where it’s going.

Then if profiling is what’s needed, you profile. Or it may turn out you weren’t doing the right thing—that wasn’t quite what you wanted to do, so you changed the goals, or you change how you’re doing it. But when it’s a matter of performance, I still operate the same way. We did a really nice profiler in Smalltalk, and then Squeak, that gave you good feedback that way.

Part of that is about performance but part of it is about just structure and architecture. You may find that some things are hardly ever used and maybe you could just get rid of them by doing things differently. It’s just a different perspective on the thing.

Seibel: It seems that virtually every programmer has a copy of Knuth’s The Art of Computer Programming. Some people have it and it’s just on their shelf. Some people have it and use it as a reference. And some people have it and really read it cover-to-cover. You actually studied with Knuth at Stanford; how much of it have you read?

Ingalls: I loved working with Don and I taught his MIX course for one quarter at Stanford, too, which was also enlightening. I think I’m pretty different from Don, but what I like about him is he’s got a great mathematical mind but also loves to go deep into the bits—the pragmatic parts of things. I, too, love to get into the pragmatic side of things but I’m not as rigorous as Don.

I was trained in physics and to me the problems I work on, or how I work on them, is really much more a physical thing. When I’m talking about other perspectives on programs, I’m really thinking that there’s a thing there that you can touch and feel it vibrate.

If you take the way he worked on TeX, it was very mathematical and beautiful and elegant. Compare that with, say, the first Smalltalk engines: they were very ad hoc. I just put together what was needed. It may be that after a few go-rounds, I started to get some sort of mathematical picture of it, or we did, but it’s different in that regard.

So the truth is, I read a fair amount of his basic data structures stuff, but I’m not a big reader—I’m very much of a doer. If I have a flaw, it’s that I will often do my own of X, Y, or Z rather than reading the literature and knowing about it. It’s usually worked to my advantage I think, but who knows?

Seibel: How much math do you think programmers need to know? Dijkstra claimed that computer science is just a branch of mathematics. And understanding The Art of Computer Programming requires a fair bit of math.

Ingalls: You’ve got to have a logical mind. But I spent a lot of time in the country in Virginia while learning about computers. I always thought that if I wanted to start a computer company in the mountains of Virginia, I’d go find the mechanics. Except in certain fairly esoteric parts, the math isn’t near as important as logic and intuition.

I think of a lot of it as being more architectural: the way the graphics work together with the models; the way things need to be updated or cached. That’s not esoteric mathematics. That said, I do view it as being very much a part of the field of mathematics. To me, the really exciting thing about computers is they allowed mathematics to become a synthetic, not just an analytic art. What I have so much fun doing day to day is a mathematical kind of thing, but it’s creative, generative, synthetic.

Seibel: You say you’re not a big reader. Are there any books you’d recommend?

Ingalls: No. And I’m sure I’m in the minority this way. I was not a big reader as a kid. I would occasionally read things thoroughly and not be interrupted until I was done. There are some papers, absolutely, and I guess with them come some books. Val Schorre’s paper on META II is one of them. There is the LISP 1.5 book. There’s APL, but I didn’t find Iverson’s book to be at all a good way to learn it. A mathematician probably would have. I can’t even remember what I read to learn about it from. But I loved it. So I think spending a bit of time in that language would be like a book to read. Likewise, Smalltalk.

Seibel: So do you still enjoy programming as much as you used to when you started?

Ingalls: Yeah, the programming itself. The last couple of years have been interesting because I’ve been taken away from the environment that I got so used to—Smalltalk and then Squeak—where the tools are just really great. I’ve had to step back a little bit, working with JavaScript in browsers and conventional development environments. It sometimes takes me longer to debug stuff than it used to, but the basic process of getting an idea and making it happen I still really enjoy.

Seibel: Do you feel at all that programming is a young person’s game?

Ingalls: Not really, no. There’s something about being able to survey all the stuff that’s going on, and some of that endless energy that I don’t feel I have the way I used to. But I still love to just take a problem and sit down and pore over it until it’s right. There’s an analogy here: I tried to learn to play piano fairly late in life. People said, “Oh, you should learn when you’re young. You learn so much quicker.” Although I didn’t go very far, my conclusion was that it isn’t that young people learn that much faster; it’s just they have more time. When I would put time in, I made progress.

I feel a bit the same thing with programming. When I look back on earlier times in my life, I had all the time I wanted. I would just work and work. Now there are other things going on in my life and I’ve got responsibilities that aren’t just programming. That undermines a bit of that intense focus.

Seibel: Leaving aside the amount of time you get to spend on it, doesn’t programming require a certain intensity and focus? People talk about flow and how if you get interrupted every 15 minutes, you never get anything done because it takes that long to even start getting the stuff in your brain sorted out.

Ingalls: That reminds me of something I said to somebody way back at PARC. I was starting to have some other responsibilities besides just hacking Smalltalk, but we were also making a lot of progress in making it a really productive system. I kidded that I was racing to improve the Smalltalk environment so that I could continue to get reasonable work done in increasingly short amounts of time. So I’d gotten to where in 15 minutes I could sit down and actually do something useful.

The other part of it is that you work with other people. I work with younger people and it’s great—maybe I spend a bit more time thinking at the level of goals and politics and arranging to make things happen, and they’re making up for what I lack in available time for that deep, deep dive.

Seibel: You have a reputation of being a great guy to work for, when you’re leading a project. How do you lead a team that makes people productive and happy?

Ingalls: I love what I do. And it’s fun to share with other people. These activities can go arbitrarily deep or wide, so it’s easy to find things for various people to work on. I’ve just always enjoyed doing that with other people. There have been times when it’s worked better or not—there are very different phases to this kind of work. There are times when you see everything that needs to be done and it’s just a matter of getting people to do it. And there are other times when you don’t really know what needs to be done and you’re trying to find out. Those are really different phases.

Seibel: Do you have any tips on how to be a good technical leader?

Ingalls: The first thing is being clear about what you’re trying to do. The job is to get a clear vision. If you’ve been around, you can see actually how you’re going to implement that, so you can start to see how that would work out in terms of what various people can do and how it would all fit together.

There have been times when I’ve been working on a project where I could see everything. It felt really powerful because whenever anybody was stuck I could tell them immediately what the next step was, or how to get around it. And people feel that, too, if you know where you’re headed. They can immediately sense it’s all there—he’s got it. And that’s empowering for the team as well.

Seibel: Does having too clear a picture of what you want ever disempower people—since you’ve got everything in your head, there’s nothing fun for them to do?

Ingalls: Well, you can leave it open how they do their part of it and you maybe only step in with micromanagement where it’s needed. And often things turn out better. I was lucky to work with a great crew of people for a long time whom I trusted. Trust is part of it, trust for the people that you’re working with. The other thing is just confidence. When the picture’s clear, it’s easy to be confident about it. I think the kind of thing that makes for bad micromanagement is you’re worried and you’re insecure, and so you’re feeling like you have to nail everything down.

Seibel: Have you ever had a really great team leader when you were a worker bee?

Ingalls: The best boss in my life has been Alan Kay. I worked under him at Xerox for some very formative years, and that was an interesting combination, because he knew what he wanted but he hardly ever said how I should do things. But he was technically savvy about all of it so he was a good critic. I and the guys who came to work with me were really productive so I think he felt enough progress that he didn’t have to interfere much. He made an umbrella for me, for us, and he really had a picture of what he wanted to do.

Seibel: When folks are working in a group, is it better for coders to each own a piece of a system? Where “This is my code and no one touches it” vs. the team owns the code and anybody can touch anything.

Ingalls: I don’t know. The way we work now on the Lively Kernel project is different people have different areas they work on, but there aren’t any fences. It’s more a matter of expertise, or focus, or goals. I’m trying to think of these periods that seemed really successful, how that worked. I’ve never worked in big teams, so it’s generally been that people pretty much worked solely on a piece of code.

Seibel: Another topic, debugging: what’s the worst bug you’ve ever had to track down?

Ingalls: It was a garbage-collection bug. Garbage collection is the worst thing because the manifestation of the problem is long after the cause has come and gone. Being able to track down an obscure bug like that makes me think of breaking codes. My father was in the Office of Strategic Services, and they worked in teams, and a lot of what they did was just gathering information, just trying to be up on things. Then a code would come in with a fragment of something they had seen in a newspaper and they would put it together that way.

It was the same thing with being able to track this down. What I brought to it was just having all this intuition of what can cause what to happen in these situations. This particular one, I was in it deep down for at least a day. When I finally got it done, I was elated, and my son, who was, I think, four at the time, made me a “Determined Debugger Award.”

Seibel: This was in Smalltalk, I assume. Did you have a symbolic debugger that you could use, or were you looking at hex dumps of memory?

Ingalls: This was lower level than the nice Smalltalk debugger. I really can’t tell you the details of this one, but the kind of thing is you get an error somewhere, which would actually take you to the low-level debuggers. So you’re looking at memory like a bunch of octal locations. Then you find things like one object pointing into another object in the way it shouldn’t. So you’re trying to think of, “How could that happen?” You have all these little clues and little patterns of this can cause that, this can cause that, and so then you try to figure them out.

Seibel: So that was at a very low level. When you’re developing in the nice Smalltalk environment, I assume you use symbolic debuggers. Do you ever resort to print statements?

Ingalls: I don’t know of anybody who does that if they have the choice of using a good debugger. Because where do you put the print statement? You put it there. Well, wouldn’t you just like to be there, looking at everything, instead of just printing it? Now I do a fair amount of print statement–style debugging because it’s often the case I don’t have a good enough JavaScript debugger.

Seibel: What made the Smalltalk debugger so nice?

Ingalls: Well, you could stop anywhere in the program and you could actually look at all the bindings of all the variables. You could execute fragments, evaluate expressions right in the middle of the context.

Seibel: At any particular point in the stack frame?

Ingalls: Yep, and you could make significant changes and then proceed. And you could get to an error, have it on the screen, save the entire state of the system, ship it to somebody else who was on a Windows machine and not a Mac, and they could fire up that same image, be where you were, make a fix, and proceed. So just complete preservation of state across different machine representations.

Seibel: Invariants are another sort of debugging tool. Some people are very big on formal preconditions, and postconditions on all their methods and class invariants, and some people are more ad hoc about how they think about things. How do you think about them?

Ingalls: I’d probably go in the less formal camp. Mainly out of that original feeling of having things be as absolutely simple as possible. I feel the same kinds of things about types. Types are essentially assertions about a program. And I think it’s valuable to have things be as absolutely simple as possible, including not even saying what the types are. I think as you get more serious about a system, it’s nice to be able to add all that stuff, and there are ways of having your cake and eating it, too, such as inferring the types and not having to see them except when you want to see them.

And types are only one thing in a spectrum that includes units and all sorts of other assertions you can put on there. That’s part of the fascinating area we have to explore with this synthetic mathematics. I think increasingly we can take areas of computation and document them more and more with living documentation, real programming documentation, so there are assertions there that really help you that you don’t usually see, but if you’re stuck, you can start to bring them in and test various things about it.

Seibel: Do you have an opinion one way or the other on formally proving programs correct?

Ingalls: It’s never been an occupation of mine. I’m inclined to focus on the architectural part that makes it easier to make assertions about things. So if you are allowed to do all sorts of dangerous things in a program, then when you sit down to do the formal proof, it’s very hard because at every step you’ve got to say, “Well, this could happen, that could happen, that could happen.” If the architecture is clean, then the formal proof may almost be obvious just by reading the code. You’ll say, “Well, this could only come from there. We’re safe.”

Seibel: Have you ever used C++?

Ingalls: No. Nor C.

Seibel: But you did BCPL and assembly, so it’s not like you’ve never used low-level languages.

Ingalls: Right. And I actually have done some C to debug things generated by Squeak. But I remember when we did Squeak, part of my purpose was to have a system that you really could be master of without having to know anything but Squeak. So I made it my purpose to not ever learn that. John Maloney did the translator from Squeak to C in order to give us a practical implementation. The truth is, I would go in and look at that C code but I pretty much made sure that you didn’t need to do any of that.

Seibel: You must’ve looked at C++ when it came out, as you were part of the group that—other than perhaps the Simula folks—can best claim to have invented object-oriented programming.

Ingalls: I didn’t get that much into it. It seemed like a step forward in various ways from C, but it seemed to be not yet what the promise was, which we were already experiencing. If I had been forced to do another bottom-up implementation, instead of using machine code I would’ve maybe started with C++. And I know a couple of people who are masters of C++ and I love to see how they do things because I think they don’t rely on it for the stuff that it’s not really that good at but totally use it as almost a metaprogramming language.

Seibel: Let’s talk about code reading. How do you get into a new piece of code?

Ingalls: It’s hard for me to answer in the abstract. You start out knowing what it does or is supposed to do. I guess I go at it pretty much top-down—I just try to understand what the pieces are and how they work together. See what classes and methods are defined and what they’re doing. Then it depends on why we’re looking. It could be it’s just something new and we want to find out about it. It could be that it’s performing badly and then you do a profile of it and look at that.

Seibel: We talked about Knuth before. His other passion is literate programming. Have you ever written literate code or read any?

Ingalls: I like to work that way with something where I’ve got the time to finish it off. When I first write stuff, there are no comments. As soon as I have it working, I’ll write some comments. And if I like what I’ve done or it seems like it would be hard to figure out, I’ll write more comments. But I don’t believe in putting comments beside everything. And I kind of feel like the better a language is, the less you need comments. You use reasonable variable names. That’s why I liked the keyword parameters in Smalltalk. It really makes things pretty readable. There’s this wonderful little hack that you can do in various places in JavaScript. It’s a little bit expensive, but JavaScript has this curly bracket object notation, and so you can use keywords and they actually looks like Smalltalk keywords because they end with colons, so you can have your multiple arguments be in a curly brace expression. It actually makes nice-looking programs.

Seibel: Hmmm. That’s kind of beautiful and disgusting at the same time.

Ingalls: Yeah, right.

Seibel: Have you convinced anyone else to adopt that style?

Ingalls: The truth is I found somebody else doing that before I thought of it myself.

Seibel: Do you consider yourself a scientist, an engineer, an artist, or a craftsman?

Ingalls: Really, all of those. I think my education as a physicist was good for me. A lot of that just has to do with looking at problems like physical problems, trying to isolate the forces on a body. It’s the same kind of thing you use for looking at what all the ways are that something’s being used in the system, how it could be affected. And it’s a very physical feeling I have about stuff that’s also really spatial—how things work together and how things that might be different could be the same and how that would make a better architecture.

I remember one of the early talks I had to give about Smalltalk; I said, “What we do in this group is like the scientific method, which is you make an observation, you come up with a theory to explain it, and you perform an experiment to verify it.” And that’s very much what we did in the successive generations of Smalltalk. We had a theory for how to make something work. We built a system that worked that way. We used it for a while and we found out, “Oh, it’d be good if we did this and this and this differently,” and we built a new one. So we kept going around that circle, which is just like scientific research and progress.

I feel like an artist when I’m working because I have this idea in my head and I just want to make it real. I imagine a sculptor having the same feeling, bringing a piece to life.

In this context, I view engineer and craftsman as being almost identical. It’s just that an engineer is a craftsman in a technological field. There are times when I feel that way, too, but they are different times—a very different time. It’s when I’m doing something low-level. From my history, I worked on the deepest parts of BitBlt or the Smalltalk byte-code engine and those are very craftsman-like things. And I had the luxury to do those over again a couple of times to get them really right and that’s a craft.

Seibel: The difference I see between engineers and craftsmen is the engineers are the folks who say, “We should be like the guys who build bridges. Bridges don’t fall down. They have a repeatable engineering process.” The craftsmen say, “This is more like woodworking. The wood is unique every time and there are rules of thumb but no method that can guarantee certain results.”

Ingalls: So in that regard I may be less of an engineer. I think that the ways in which I stress systems are different. I know there are people who do serious enterprise programming systems. That’s not a focus or a passion of mine. Of the four you mentioned, the engineer is probably the least, then craftsman, and then this funny combination between artist and scientist at the top.

Seibel: You mentioned that you left industry for a while and then you came back. Were you tired of computers or was it just other things in life?

Ingalls: It was other things in my life. It was also a nice break, and I picked a good time for it, because when I came back, it didn’t seem to me like things had changed that much, except everything was a hundred times faster.

Seibel: Do you have any recommendations for people who want to be programmers?

Ingalls: Well, I think a decent course in computer science should be good. The way I would organize that is to learn several different languages that have various different strengths. Smalltalk’s got a lot of strengths but it’s not the answer to everything. There’s logic programming. There’s functional programming. Actually, you can do Smalltalk in a functional style, and so that’s covered there pretty much. But like what I said about Lotus 1-2-3 and translating English to pig Latin, I think it’s worth it to take several different computing environments and then pick a problem to solve in them, which either reveals the strength of the language or encourages you to somehow escape from it.

Seibel: Do you think programming—and therefore the kind of people who can succeed as programmers—has changed? Can you be a great programmer operating at a certain high level without ever learning assembly, or C, and maybe without ever learning the algorithms you would get from reading Knuth, because these days you’re using some high-level language that includes a lot of those algorithms in libraries?

Ingalls: Different people have different levels that they need to go to to feel good about what they’re working with. So I think somebody can be entirely confident maybe using a collections library without having programmed it themselves. It just means they’re operating at another level. Lord knows, I wouldn’t expect anybody who intends to work with graphics to have had to write BitBlt. You don’t have to do NAND gates; you can use assembly language. I think you can work at any of these levels. If the challenge calls on you for it, you’re going to have to go deeper, and if your interest is sparked, you will want to go deeper.

Seibel: So do you think most programmers today, who may be working at a fairly high level, in a different environment would have learned assembly and microcode? Or do you think the kind of talents that people need to be successful programmers are changing?

Ingalls: Yes and no. It is in a way the same up and down at any level and hopefully it will come to appear even more so. But there are areas right now where I think there’s more putting together according to formula and other areas where there’s dealing with things that are much more primitive.

I was a physicist; I had mathematician friends and I did not feel like I was at all the same kind of brain as they were. But we both did good things. I think that’s going to be the case in computers, too. The people who are working on program provers are different from the people who are working on graphics systems, I think. And so people are going to find their strengths and the place they want to work and the place that they’re not comfortable working. I think there’s some nature as well as nurture going on here, and there always will be.

It may be that some of these systems have enough levels and parts to them that a given person may be mainly comfortable and productive working in one kind of area rather than another, but I think it’s all the same stuff. There’s logical thought and there’s structural thought. And there’s human stuff and creativity. A given person has a given mix of that from their nature and their nurture, and to me, it hasn’t changed much. People are trying to do presumably bigger, better stuff, but it seems to me to still be pretty much the same.

Seibel: Related to that, as more and more fields rely on computing in more and more ad hoc ways, there are folks who want to find a way for “nonprogrammers” to program. Do you think that’ll happen, or will domain experts, say biologists, always have to team up with programmers to build custom software to solve their problems?

Ingalls: I think there will be that kind of collaboration because the biologist isn’t interested in programming it. He’s interested in finding out this or that. Then there’s somebody who understands how this stuff is being worked on on the computers who can help him do that. I think the thing that lets a nonprogrammer program is an application.

Seibel: I worked on a project that tried to provide a programming environment for biologists on the theory that the software they would need would always be ad hoc. You couldn’t build an application and be done with it because the biologists didn’t really know what they needed until they got down to some piece of biological data and said, “What I really want to know is X,” and the only way to extract X from that data was, essentially, to write a program.

Ingalls: Yeah, it would be nice if we could have some computing environment with all your information in it so you could somehow figure out how to get to it all just by its self-revealing nature. But I think that there are people who are going to be interested in that and people who aren’t.

Seibel: Is there anything I haven’t asked about that you thought I might?

Ingalls: Often, reading about famous people, the side of it that I’m interested in is, how do they make their life work? All the things that weren’t their passion, and how did they deal with that, and with their family, and with their finances, and balancing that. Or did they just hole up and say, “To hell with everything else,” and let it just come crumbling down until they had their work done?

Seibel: Do you feel like there were times in your life where your passion for programming ran amok to the detriment of other parts of your life?

Ingalls: Yeah, there are times when it’s been hard on others because I’m focused and need to stay focused. It’s a risk with anybody who’s got a passion for what they’re doing. I think either you learn to moderate it somewhat or the other thing you do is communicate it so that everybody around you knows that you’re dealing with this thing, and you’ll probably be done in a week, but until then Daddy’s somewhat inaccessible.

Seibel: And then you win your “Dad the Determined Debugger” award.

Ingalls: Exactly; right. The other thing is, the more you can reflect the satisfaction from progress back out to all the people who have dealt with you during that time, at least they have a sense that Daddy’s doing something good, and we’ll all be happy when it’s done.

Оглавление книги