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

Seibel:What languages have you used seriously? It must be a long list for you.

Steele:I earned my first money programming in COBOL. I was still a highschool student and subcontracted to someone who was doing a report-card generator system for another school system, so there wasn’t any conflict of interest there. I used Fortran, IBM 1130 assembly language, PDP-10 machine language, APL. I guess I can’t claim to have used SNOBOL seriously. Certainly C, C++, Bliss, the DECsystems implementation language that came out of Carnegie Mellon. GNAL, which is based on Red, I’ve used quite seriously.

Several different varieties of Lisp, including Common Lisp, Scheme, Maclisp. The version of Lisp that Dick Gabriel and I built for the S-1, S-1 Lisp, which was one of the four or five that merged to make Common Lisp. I developed Connection Machine Lisp but I’m not sure I could be said to have done serious coding in it. That was, I think, in turn implemented in *Lisp. *Lisp is not to be confused with Connection Machine Lisp; they are two distinct languages.

I did some serious coding in C *, which was another language we developed for the Connection Machine. Java, of course. And some scripting languages. I’ve done some extensive work in JavaScript, in Tcl. I’ve done serious programming in Haskell, taking “serious” to mean I’ve worked with a language for more than a month and tried to write a substantial piece of code in it. Oh, FOCAL, an early interactive language on the DEC computers, similar to… a little bit like BASIC, a little bit like JOSS. I’ve done substantial coding in BASIC, now that I think about it. And TECO, the Text Editor and Corrector, of course was used to program the first version of Emacs and I regard that as a programming language for that purpose. I wrote enormous amounts of TECO code. And TeX, also regarded as a programming language. Those would be the main ones, I guess.

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

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

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

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

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

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

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

Steele:Well, it’s much easier now to write the kinds of programs we were trying to write 30 years ago. But I think our ambitions have grown tremendously. So I think programming is probably a more difficult activity than 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 we had 30 years ago and they are being pushed to the limits of their abilities as people were 30 years ago—I’ve chosen 30 years ago as an arbitrary baseline because that’s when I got out of school. But the difference is that—as I remarked earlier—it’s not possible to understand everything that’s going on anymore. Or even to think you can. So I think that the programmers of today are up against a more difficult environment—still exercising the same amounts of ingenuity but in an environment that’s harder to understand. So we try to make more elaborate languages to help them deal with the uncertainty of those environments.

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

Steele:I think it’s important that a language be able to capture what the programmer wants to tell the computer, to be recorded and taken into account. Now different programmers have different styles and different ideas about what they want recorded. As I’ve progressed through my understanding of what ought to be recorded I think we want to say a lot more about data structures, we want to say a lot more about their invariants. The kinds of things we capture in Javadoc are the kinds of things that ought to be told to a compiler. If it’s worth telling another programmer, it’s worth telling the compiler, I think.

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

Steele:Some of it is. But some of it isn’t. Relationships between parameters are not well captured by Java code. For instance, here’s an array and here’s an integer and this integer ought to be a valid index into the array. That’s something you can’t easily say in Java. That’s an important concept 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 are trying to be able to capture those kinds of relationships. We talked about algebraic relationships earlier, the idea that some operation is associative. We want to be able to talk about that very explicitly in Fortress. And I don’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 if they’re going to use sophisticated implementation algorithms, the correctness of the algorithm hinges crucially on these properties. And so where it does depend crucially on those properties, we want a way to talk about them in a way the compiler can understand. I conjecture that that is an important approach to finding our way forward, to capture in the language important properties of programming.

Seibel:What about the role of the language in making it impossible to make mistakes? Some people say, “If we just lock this language down enough it’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 wide open and leave it to the programmers do be smart.” How do you find that balance?