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

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.