Peter Seibel - Coders at Work - Reflections on the craft of programming

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.