Steele: On the other hand, now Haskell has discovered monads and theyhave dragged in the I/O monad and now the transactional-memory monad.There’s a theory that it’s functional and maybe that does give you a leg up.On the other hand it’s feeling more and more imperative. And I can’t resistthinking of the White Knight in Through the Looking Glass—“I was thinking ofa plan to dye one’s whiskers green, and always use so large a fan that theycould not be seen.” And in some ways, monads strike me as that fan, whereyou’re dragging in the I/O and trying to hide it again—are the side effectsreally there, or are they really not?

Although I will say that about once a month I get the feeling that I wish thatin designing Fortress we had started with Haskell and tried to move ittoward Fortran and Java, rather than starting with Fortran and Java andtrying to move it toward Haskell. We are finding ourselves taking more andmore of a functional approach as we design the Fortress libraries as weencounter the difficulties of trying to make efficient parallel data structures.

Seibel: You obviously write a lot in English and care about that craft aswell. Do you find writing prose and writing code to be similar mentalexercises?

Steele: Well, they feel different in that I’m very aware that the primaryreader for English prose has a very different kind of processor than acomputer. So I can’t use recursion in quite the same way, for example. Forsophisticated readers I can use it a little bit. But there’s a constantawareness of how a reader is going to process the text and understand it.

Something I worry about a lot when I write, that I’m less worried aboutwith a computer, is about the ways in which English is ambiguous. I’mconstantly worrying about ways in which the reader might misinterpretwhat I’ve written. So I’ve actually spent a lot of time consciously crafting themechanics of my prose style to use constructions that are less likely to bemisinterpreted.

My favorite Saturday Night Live sketch, even more than the bees or the wildand crazy guys, was a sketch where Ed Asner was on and he played themanager of a nuclear power plant going on vacation for two weeks. Hewalked out the door, saying, “Goodbye, everybody, I’m going. Remember,you can’t give too much coolant to the nuclear reactor.” And they spendthe next three minutes arguing over what he meant.

Seibel: So when you’re writing English, you’re obviously writing for ahuman reader and you seem to contrast that to writing software, which isfor a computer. But lots of people—such as Knuth—make a big point thatwhen you’re writing code you’re writing as much for human readers as forthe computer.

Steele: Oh, that’s true.

Seibel: So do the lessons of writing English for a human reader help youwith that aspect of code?

Steele: Well, sure. When I’m writing code, one of the foremost things inmy mind is, will this get the computer to do what I want? And so it’s amatter of, “Will it be understood even one way?” Rather than not at all.Then there’s the question of often there’s more than one way to writesomething correctly. And at that point I begin worrying about the humanreader. And I also worry about efficiency.

There’s a trade-off there, typically. If efficiency is important, I’ll often resortto a trick. And then I realize that will mislead a human. And you have tocomment it or do something to flag that, to make it more readable. But yes,very often in things like choices of variable names and the way code is laidout and so forth, the emphasis is more on the human reader, and you thinkabout how you can use details of the code formatting that don’t matter tothe computer to provide the necessary signals to the human reader.

Seibel: As our languages get better, or at least more programmer-friendly,compared to the days of assembly language on punch cards, it seems like it’seasier to write correct programs—you get a lot of help from compilers thatflag errors for you and so forth. Is it possible to allow the focus onreadability to come first, if only slightly ahead, of correctness? After all, asthe Haskell folks are fond of saying, “If your Haskell program type checks, itcan’t go wrong.”

Steele: I think that’s a terrible pitfall. There are so many ways for acompilable program to have errors in it that you really do need to worryabout correctness all the time. And if it’s not correct you’ll mislead not onlythe computer but your human readers, too.

Programming is a highly unnatural activity, I’m convinced, and it must becarefully learned. People are used to their listeners filling in the gaps. Isuppose we lean on compilers to do that in a little way—you say, “I need avariable named ‘foo’,” you don’t worry about exactly what register and soforth. But I think that most people are not used to being very precise andrigorous in their communications. But when we are describing processes tobe carried out, little details do matter because a change in a small detail canaffect the gross outcome of the process.

I think people are used to using recursion in a limited way—I think NoamChomsky demonstrated that. But in practice people rarely go even threedeep—and when they do it’s usually in a tail-recursive way. The discipline ofunderstanding recursion is actually a very difficult learned art. And yet thatis actually one of our most powerful programming tools, once you’velearned the discipline and wrapped your head around it. So I really think youcan’t afford to take your eye off the correctness ball.

Seibel: Yet lots of people have tried to come up with languages orprogramming systems that will allow “nonprogrammers” to program. I takeit you think that might be a doomed enterprise—the problem aboutprogramming is not that we haven’t found the right syntax for it but thatpeople have to learn this unnatural act.

Steele: Yeah. And I think that the other problem is that people like tofocus on the main thing they have in mind and not worry about the edgecases or the screw cases or things that are unlikely to happen. And yet it isprecisely in those cases where people are most likely to disagree what theright thing to do is.

Sometimes I’ll quiz a student, “What should happen in this case?” “Well,obviously it should do this.” And immediately someone else will jump in andsay, “No, no, it should do that.” And those are exactly the things that youneed to nail down in a programming specification of some process.

I think it’s not an accident that we often use the imagery of magic todescribe programming. We speak of computing wizards and we think ofthings happening by magic or automagically. And I think that’s because beingable to get a machine to do what you want is the closest thing we’ve got intechnology to adolescent wish-fulfillment.

And if you look at the fairy tales, people want to be able to just think intheir minds what they want, wave their hands, and it happens. And ofcourse the fairy tales are full of cautionary tales where you forgot to coverthe edge case and then something bad happens.

Seibel:Fantasia and the perils of recursion, for instance.

Steele:Fantasia and recursion, yes. Or, “I wish I was the richest man in thecountry”—well, that makes everybody else extremely poor and you’re thesame as you were before. That kind of thing happens in fairy tales becausepeople forget that there’s more than one way to do something. And if youjust think about your main wish and don’t think about the details, that leavesa lot not tied down.

Seibel: So the lesson from fairy tales is that the Gandalfs of the world gotthere by hard labor, learning the incantations, and there’s no shortcut tothat?

Steele: Yeah. I’ll give you another example—suppose I were to tell mysmart computer, “OK, I’ve got this address book and I want the addressesto always be in sorted order,” and it responds by throwing away everythingbut the first entry. Now the address book is sorted. But that’s not what youwanted. It turns out that just specifying something as simple as “a list is insorted order and I haven’t lost any of the data and nothing has beenduplicated” is actually a fairly tricky specification to write.