Ingalls: I’d probably go in the less formal camp. Mainly out of that original feeling of having things be as absolutely simple as possible. I feel the same kinds of things about types. Types are essentially assertions about a program. And I think it’s valuable to have things be as absolutely simple as possible, including not even saying what the types are. I think as you get more serious about a system, it’s nice to be able to add all that stuff, and there are ways of having your cake and eating it, too, such as inferring the types and not having to see them except when you want to see them.

And types are only one thing in a spectrum that includes units and all sorts of other assertions you can put on there. That’s part of the fascinating area we have to explore with this synthetic mathematics. I think increasingly we can take areas of computation and document them more and more with living documentation, real programming documentation, so there are assertions there that really help you that you don’t usually see, but if you’re stuck, you can start to bring them in and test various things about it.

Seibel: Do you have an opinion one way or the other on formally proving programs correct?

Ingalls: It’s never been an occupation of mine. I’m inclined to focus on the architectural part that makes it easier to make assertions about things. So if you are allowed to do all sorts of dangerous things in a program, then when you sit down to do the formal proof, it’s very hard because at every step you’ve got to say, “Well, this could happen, that could happen, that could happen.” If the architecture is clean, then the formal proof may almost be obvious just by reading the code. You’ll say, “Well, this could only come from there. We’re safe.”

Seibel: Have you ever used C++?

Ingalls: No. Nor C.

Seibel: But you did BCPL and assembly, so it’s not like you’ve never used low-level languages.

Ingalls: Right. And I actually have done some C to debug things generated by Squeak. But I remember when we did Squeak, part of my purpose was to have a system that you really could be master of without having to know anything but Squeak. So I made it my purpose to not ever learn that. John Maloney did the translator from Squeak to C in order to give us a practical implementation. The truth is, I would go in and look at that C code but I pretty much made sure that you didn’t need to do any of that.

Seibel: You must’ve looked at C++ when it came out, as you were part of the group that—other than perhaps the Simula folks—can best claim to have invented object-oriented programming.

Ingalls: I didn’t get that much into it. It seemed like a step forward in various ways from C, but it seemed to be not yet what the promise was, which we were already experiencing. If I had been forced to do another bottom-up implementation, instead of using machine code I would’ve maybe started with C++. And I know a couple of people who are masters of C++ and I love to see how they do things because I think they don’t rely on it for the stuff that it’s not really that good at but totally use it as almost a metaprogramming language.

Seibel: Let’s talk about code reading. How do you get into a new piece of code?

Ingalls: It’s hard for me to answer in the abstract. You start out knowing what it does or is supposed to do. I guess I go at it pretty much top-down—I just try to understand what the pieces are and how they work together. See what classes and methods are defined and what they’re doing. Then it depends on why we’re looking. It could be it’s just something new and we want to find out about it. It could be that it’s performing badly and then you do a profile of it and look at that.

Seibel: We talked about Knuth before. His other passion is literate programming. Have you ever written literate code or read any?

Ingalls: I like to work that way with something where I’ve got the time to finish it off. When I first write stuff, there are no comments. As soon as I have it working, I’ll write some comments. And if I like what I’ve done or it seems like it would be hard to figure out, I’ll write more comments. But I don’t believe in putting comments beside everything. And I kind of feel like the better a language is, the less you need comments. You use reasonable variable names. That’s why I liked the keyword parameters in Smalltalk. It really makes things pretty readable. There’s this wonderful little hack that you can do in various places in JavaScript. It’s a little bit expensive, but JavaScript has this curly bracket object notation, and so you can use keywords and they actually looks like Smalltalk keywords because they end with colons, so you can have your multiple arguments be in a curly brace expression. It actually makes nice-looking programs.

Seibel: Hmmm. That’s kind of beautiful and disgusting at the same time.

Ingalls: Yeah, right.

Seibel: Have you convinced anyone else to adopt that style?

Ingalls: The truth is I found somebody else doing that before I thought of it myself.

Seibel: Do you consider yourself a scientist, an engineer, an artist, or a craftsman?

Ingalls: Really, all of those. I think my education as a physicist was good for me. A lot of that just has to do with looking at problems like physical problems, trying to isolate the forces on a body. It’s the same kind of thing you use for looking at what all the ways are that something’s being used in the system, how it could be affected. And it’s a very physical feeling I have about stuff that’s also really spatial—how things work together and how things that might be different could be the same and how that would make a better architecture.

I remember one of the early talks I had to give about Smalltalk; I said, “What we do in this group is like the scientific method, which is you make an observation, you come up with a theory to explain it, and you perform an experiment to verify it.” And that’s very much what we did in the successive generations of Smalltalk. We had a theory for how to make something work. We built a system that worked that way. We used it for a while and we found out, “Oh, it’d be good if we did this and this and this differently,” and we built a new one. So we kept going around that circle, which is just like scientific research and progress.

I feel like an artist when I’m working because I have this idea in my head and I just want to make it real. I imagine a sculptor having the same feeling, bringing a piece to life.

In this context, I view engineer and craftsman as being almost identical. It’s just that an engineer is a craftsman in a technological field. There are times when I feel that way, too, but they are different times—a very different time. It’s when I’m doing something low-level. From my history, I worked on the deepest parts of BitBlt or the Smalltalk byte-code engine and those are very craftsman-like things. And I had the luxury to do those over again a couple of times to get them really right and that’s a craft.

Seibel: The difference I see between engineers and craftsmen is the engineers are the folks who say, “We should be like the guys who build bridges. Bridges don’t fall down. They have a repeatable engineering process.” The craftsmen say, “This is more like woodworking. The wood is unique every time and there are rules of thumb but no method that can guarantee certain results.”

Ingalls: So in that regard I may be less of an engineer. I think that the ways in which I stress systems are different. I know there are people who do serious enterprise programming systems. That’s not a focus or a passion of mine. Of the four you mentioned, the engineer is probably the least, then craftsman, and then this funny combination between artist and scientist at the top.