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.