I was forced, by trying to come up with something that would run withoutinstallation, in a browser, to take what was in the browser. What’s in thebrowser? 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 arelanguage kernels, there are graphics kernels, and then there’s this other kindof self-supporting user-interface environment kernel.”

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

Ingalls: Right.

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

Ingalls: Yup. This is another of those double-edged swords. I don’t thinkthere’s a simple answer. At the very bottom, it’s a wonderful thing thatwe’ve built computers that totally allow for change. It’s all random-accessmemory; 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 andchangeable, it’s much easier to then draw boundaries and say, “You can’tchange stuff inside of here” than it is to start out with something that’s notdynamic and changeable and then try to make it that way.

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

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

Ingalls: I suppose that’s true. But it’s easier for someone to put a layer, likeHTML, on top of that. I think it’s better to have the underlying systems beas dynamic as possible. Then you can put on syntax or type restrictions, orthis, that, and the other that make it into a fixed thing. Absolutely there aresituations when people are just using a system—you want things to be fixedthat don’t need to be flexible. And yes it does seem that if people perceivethat it’s flexible, it’s scary to them. If you take the Lively Kernel as it is rightnow, it’s not at all something that an end user would want. Nobody wantsto 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 togo that direction. It’s also very simple so somebody could put in a layer thatwould make it usable and not changeable in those various weird ways. Butyeah, there’s a real trade-off between having things be flexible and generaland having things be codified and able to be used as a cookbook and alwaysdo what you expect.

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

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

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

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

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

Ingalls: I just started typing in code. I think the first thing was to validatethe execution model. There were just a couple of basic structures that wereneeded, the equivalent of a stack frame. So I just made, it must have been anarray, in BASIC, to do that and put together enough that would execute apiece 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 inplace that’s the structure you think you’re going to want to interpret andthen try to make it work. I remember the first thing we got to run was sixfactorial. It’s a really simple example but it involves the process of dynamiclookup and creating new stack frames. And then once you’ve got thatworking, you come to understand how things are going to go and you findout what’s difficult.

Eventually you figure out where the time’s going and so you improve allthose things. Then, in this particular case, once that worked there was theproblem of putting a layer on it which is essentially a parser so you can typetext into it and get it to go into that structure that you breadboarded. Thenyou’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 assemblycode,” or whatever else. Then you suddenly realize, “Oh, yeah, we needautomatic storage management. So how are we going to do that?” It’s onething after another.

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

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

In the spectrum of implementers, I probably err on the side of just makingthings happen. A lot of that is because I get so much of a thrill bringingthings 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 storagemanagement completely differently, but the really important things you’relearning have nothing to do with that. The first Smalltalks I did usedreference counting for garbage collection; probably it would have beenbetter to use something else. For a while there was a certain amount of painassociated with reference counts. But that didn’t matter—the point was thesystem was up and alive and running and we were learning all this othergreat stuff about how you put together things with objects, what it’s like todo 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 leastamong the people I’ve talked to for this book. Though Don Knuth did writeTeX in pencil in a notebook for six months before he typed in a line of codeand he said he saved time because he didn’t have to bother writingscaffolding to test all the code he was developing because he just wrote thewhole thing.