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.