Seibel: I’m guessing from what you said earlier that the answer to thequestion of “What’s your favorite programming language?” would have tobe “mu.”

Steele: I’ve got three children; you might as well ask me which is myfavorite. They’re all great—they’ve got different skills and differentpersonalities.

Seibel: Are there any programming languages which you just don’t enjoyusing?

Steele: I get some kind of pleasure out of each language. But there arecertainly certain languages that I find more frustrating than others. I enjoyedTECO at the time; I don’t think I’d want to go back. It had quite a numberof difficulties—it was very difficult to come back in a month and read whatyou’d written.

I’m not sure that I’ve written enough Perl code to be taken seriously as adetractor, but I have not been attracted to the language. I have not beenattracted to C++. I have written some C++ code. Anything I think I mightwant to write in C++ now could be done about as well and more easily inJava. Unless efficiency were the primary concern.

But I don’t want to be seen as a detractor of Bjarne Stroustrup’s effort. Heset himself up a particular goal, which was to make an object-orientedlanguage that would be fully backwards-compatible with C. That was adifficult task to set himself. And given that constraint, I think he came upwith an admirable design and it has held up well. But given the kinds of goalsthat I have in programming, I think the decision to be backwards-compatiblewith C is a fatal flaw. It’s just a set of difficulties that can’t be overcome. Cfundamentally has a corrupt type system. It’s good enough to help you avoidsome difficulties but it’s not airtight and you can’t count on it.

Seibel: Do you think languages are getting better? You keep designingthem, so hopefully you think it’s a worthwhile pursuit. Is it easier to writesoftware now because of advances that we’ve made?

Steele: Well, it’s much easier now to write the kinds of programs we weretrying to write 30 years ago. But I think our ambitions have growntremendously. So I think programming is probably a more difficult activitythan it was 30 years ago.

Seibel: And what are the things that are making it more difficult?

Steele: I think we’ve got people now who are just as smart as the people wehad 30 years ago and they are being pushed to the limits of their abilities aspeople were 30 years ago—I’ve chosen 30 years ago as an arbitrary baselinebecause that’s when I got out of school. But the difference is that—as Iremarked earlier—it’s not possible to understand everything that’s going onanymore. Or even to think you can. So I think that the programmers of today areup against a more difficult environment—still exercising the same amounts ofingenuity but in an environment that’s harder to understand. So we try to makemore elaborate languages to help them deal with the uncertainty of thoseenvironments.

Seibel: It’s interesting that you say, “more elaborate languages.” There’s aschool of thought—one that you’re certainly aware of as it could be calledthe Scheme school of thought—that the only way to manage complexity isto keep things, including our programming languages, very simple.

Steele: I think it’s important that a language be able to capture what theprogrammer wants to tell the computer, to be recorded and taken intoaccount. Now different programmers have different styles and differentideas about what they want recorded. As I’ve progressed through myunderstanding of what ought to be recorded I think we want to say a lotmore about data structures, we want to say a lot more about theirinvariants. The kinds of things we capture in Javadoc are the kinds of thingsthat ought to be told to a compiler. If it’s worth telling anotherprogrammer, it’s worth telling the compiler, I think.

Seibel: Isn’t most of the stuff in Javadoc, other than the human-readableprose, actually derived from the code?

Steele: Some of it is. But some of it isn’t. Relationships betweenparameters are not well captured by Java code. For instance, here’s an arrayand here’s an integer and this integer ought to be a valid index into thearray. That’s something you can’t easily say in Java. That’s an importantconcept and in Fortress you are able to say such things.

Seibel: And they’re compiled into runtime asserts or statically checked?

Steele: Whatever is appropriate. Both. In the case of Fortress we aretrying to be able to capture those kinds of relationships. We talked aboutalgebraic relationships earlier, the idea that some operation is associative.We want to be able to talk about that very explicitly in Fortress. And Idon’t expect that every applications programmer is going to stop and think,“You know, this subroutine I just invented is associative.”

But library programmers really care about that a lot. Partly because ifthey’re going to use sophisticated implementation algorithms, thecorrectness of the algorithm hinges crucially on these properties. And sowhere it does depend crucially on those properties, we want a way to talkabout them in a way the compiler can understand. I conjecture that that isan important approach to finding our way forward, to capture in thelanguage important properties of programming.

Seibel: What about the role of the language in making it impossible tomake mistakes? Some people say, “If we just lock this language down enoughit’ll be impossible to write bad code.” Then other people say, “Forget it;that’s a doomed enterprise, so we might as well just leave everything wideopen and leave it to the programmers do be smart.” How do you find thatbalance?

Steele: The important thing is just to realize that it is a trade-off that youmake. And you can’t hope to eradicate all bad code. You can hope todiscourage certain kinds of likely errors by requiring “Mother, may I?” code;in order to do something difficult, you have to write something a little moreelaborate to say, “Yes, I really meant this.” Or you can purposely make itdifficult or impossible to say a certain thing, such as, for example, to corruptthe type system. Which has its pluses and minuses—it’s really hard to writedevice drivers for bare metal in a completely type-safe language just becausethe levels of abstraction are wrong for talking to the bare metal. Or you cantry to add in stuff that lets you say, “This variable really is this deviceregister at absolute address XXXX.” That in itself is a kind of unsafe feature.

Seibel: Have any of the newer languages provided any interesting surprises?

Steele: Python’s kind of nice in the way that it’s organized. I think Idisagreed with Guido’s decision not to use a garbage collector early on. Ithink he’s since recanted that decision—I could have predicted they wouldprobably want one eventually. They made some interesting syntactic choicesincluding the decision to rely on indentation, and the way they use colons atthe end of certain statements is kind of cute. And the specific ways in whichthey support objects and closures is kind of interesting.

Seibel: Most Lispers would think of the closures as being sort of deficient;the lambda is pretty limited.

Steele: Right. Well you know, he was making a certain set of compromisesbased on implementability and explainability and other things. And it was aninteresting set of choices. And it was not the set of choices I would havemade, but he was serving a particular user community and trying to getcertain things done and I can appreciate why he made the choices the wayhe did. Haskell is a beautiful language. I love Haskell. I don’t use it that much.

Seibel: So you’re in the midst of designing a language and you love Haskell,but Fortress isn’t a pure functional language?