Armstrong: It’s for user guides. It sort of switches me into a differentmode of thinking. I just start, in order to do this, create a directory calledthat, put this file in there, rename this as that and that is guiding thestructure. I’ve sort of pondered the question. I bet Knuth would say, “Well,all programs are literate programs.” You don’t write the code and thenwrite the documentation. You write both at the same time, so it’s a literateprogram. I’m not there. I don’t think that. I don’t know if his view is becausehe publishes his programs.

I don’t know if it’s a left-brain/right-brain shift, or what it is, but when youwrite the documentation you think about the program differently to whenyou write the code. So I guess writing literate programs forces that shift asyou’re doing it. Which might be very productive. I did do some literateErlang though I haven’t actually used it for a very long time. So that’s aninteresting idea—perhaps I should wake it up again and write some stuffusing literate Erlang. I’m not against the idea but I’m sort of impatient andwanted to write the code and not the documentation. But if you really wantto understand it then I think writing the documentation is an essential step.

If I were programming Haskell, I would be forced to think about the typespretty early and document them and write them down. If you’reprogramming in Lisp or Erlang you can start writing the code and youhaven’t really thought about the types. And in a way, writing thedocumentation is thinking about the types in a way. I suppose you start offwith “is a”. You say, “A melody is a sequence of notes.” Right. OK. Amelody is a sequence of chords where each chord is a parallel compositionof notes of the same duration. Just by defining terms in yourdocumentation—a something is a something—you’re doing a sort of typeanalysis and you’re thinking declaratively about what the data structures are.

Seibel: Do you think overall programming languages are getting better?Are we on a trajectory where we learn enough lessons from the past andcome up with enough new ideas?

Armstrong: Yes. The new languages are good. Haskell and things like that.Erlang. Then there are some funny languages that should really be used.Prolog is a beautiful language but not widely used. It sort of peaked;Kowalski called it a solution looking for a problem.

Seibel: Dan Ingalls mentioned Prolog as an example of the kind of idea thatwe should really revisit now that we’ve had a couple decades of Moore’sLaw.

Armstrong: Prolog is so different to all the other programming languages.It’s just this amazing way of thinking. And it’s not appropriate to allproblems. But it is appropriate to an extremely large set of problems. It’snot widely used. And it’s a great shame because programs are incrediblyshort. I think I went into shock when I wrote my first Prolog program. It’s akind of shocking experience. You just walk around going, where’s theprogram—I haven’t written a program. You just told it a few facts about thesystem, about your problem. Here it is figuring out what to do. It’swonderful. I should go back to Prolog—drop Erlang.

Seibel: Are there other skills that are not directly related to programmingthat you feel have improved your programming or that are valuable to haveas a programmer?

Armstrong: Writing is. There’s some computer scientist that said, “Oh, ifyou’re no good at English you’ll never be a very good programmer.”

Seibel: I think Dijkstra had something about that.

Armstrong: I’ve occasionally been asked to advise people at universitieson choice of syllabus subjects for computer science courses, being as how Iwork for industry—what does industry want? And I say, “Well, turn ’em outbeing able to write and argue cogently.” Most graduates who come out, andthey’ve got degrees in computer science, writing’s not their strong point.

I think it’s actually very difficult to teach because it’s very individual.Somebody’s got to take your text and a red pen and explain to you whatyou did wrong. And that’s very time consuming. Have you ever readHamming’s advice to young researchers?

Seibel: “You and Your Research”?

Armstrong: He says things like, “Do good stuff.” He says, “If you don’t dogood stuff, in good areas, it doesn’t matter what you do.” And Hammingsaid, “I always spend a day a week learning new stuff. That means I spend 20percent more of my time than my colleagues learning new stuff. Now 20percent at compound interest means that after four and a half years I willknow twice as much as them. And because of compound interest, this 20percent extra, one day a week, after five years I will know three times asmuch,” or whatever the figures are. And I think that’s very true. Because Ido research I don’t spend 20 percent of my time thinking about new stuff, Ispend 40 percent of my time thinking about new stuff. And I’ve done it for30 years. So I’ve noticed that I know a lot of stuff. When I get pulled in as atroubleshooter, boom, do it that way, do it that way. You were askingearlier what should one do to become a better programmer? Spend 20percent of your time learning stuff—because it’s compounded. ReadHamming’s paper. It’s good. Very good.

Seibel: Do you find some code beautiful?

Armstrong: Yes. Why this is I don’t know. The funny thing is, if you givetwo programmers the same problem—it depends on the problem, butproblems of a more mathematical nature, they can often end up writing thesame code. Subject to just formatting issues and relabeling the variables andthe function names, it’s isomorphic—it’s exactly the same algorithms. Arewe creating these things or are we just pulling the cobwebs off? It’s like astatue that’s there and we’re pulling the cobwebs off and revealing thealgorithm that’s always been there. So are we inventing a new algorithm orare we inventing a structure that already exists? Some algorithms feel likethat. I think it’s more the mathematical algorithms. I don’t get that feelingwhen I’m implementing a telephony protocol or something. That’s not astatue that I’m pulling the cobwebs off.

Seibel: So that’s similar to the beauty of math, because it’s part of nature.Then there are other levels at which code sort of has an aesthetic.

Armstrong: Yeah. It’s kind of feng shui. I like minimalistic code, verybeautifully poised, structured code. If you start removing things, if you get tothe point where if you were to remove anything more it would not workany more—at this point it is beautiful. Where every change that you couldconceivably make, makes it a worse algorithm, at that point it becomesbeautiful.

Seibel: You mentioned that when you and Robert Virding were passing thecode back and forth how each of you changed the low-level details offormatting, stuff that programmers argue endlessly about.

Armstrong: That’s not affecting the beauty of the algorithm.

Seibel: But it’s part of the aesthetic. It’s people’s taste.

Armstrong: Yeah. But I wouldn’t say, “This is ugly code because there’s ablank after the comma.” Ugly is when it’s done with a linear search and itcould have been done with a binary interval halving. Or it could have donelogarithmically and it’s done linearly. For the wrong reasons. Sure do itlinearly if we know we’re searching through a list of ten elements, whocares? But if it’s a big data structure then it should have been done with abinary search. And so it’s really not very pretty to do it in a linear form. Themathematical algorithms—that’s like Platonic beauty. This is more likearchitecture. You admire a fine building—it’s not a mathematical object. Nota solid or a sphere or a prism—it’s a skyscraper. It looks nice.

Seibel: What makes a good programmer? If you are hiring programmers—what doyou look for?