Seibel: And where did you get the functional aspect?

Armstrong: Once you’ve added concurrency to Prolog you really just hadto make sure it didn’t backtrack after you’d done something. In Prolog youcould call something and then backtrack over the solution to basically undothe effect of calling it. So you had to realize if this statement says, “Fire themissiles,” and whoom, off they go, you can’t backtrack over it and reversethat. Pure Prolog programs are reversible. But when you’re interacting withthe real world, all the things you do are one way. Having said, fire themissiles, the missiles fire. Having said, “Change the traffic lights from red togreen,” they change from red to green and you can’t say, “Oh, that was abad decision; undo it.”

Now we’ve got a concurrent language and parallel processes and insidethese processes we’re doing full Prolog with backtracking and all that kind ofstuff. So the Prolog became very deterministic with cuts everywhere to stopit from backtracking.

Seibel: Where the irreversible things would be sending messages to otherprocesses?

Armstrong: Yes. But it’s just a function call and maybe not of the functionthat fires the rockets but one that calls something else that calls somethingelse that calls it so it’s just a pain kind of trying to keep these two worldsseparate. So the code you wrote inside a process became more and morefunctional, sort of a dialect of Prolog which was a functional subset. And soif it’s a functional subset, might as well make it completely functional.

Seibel: Yet Erlang is pretty different from most functional languages thesedays in being dynamically typed. Do you feel like part of the functionallanguage community?

Armstrong: Oh yes. When we go to functional programming conferences,I suppose we argue about our differences. We argue about eager evaluationand lazy evaluation. We argue about dynamic type systems and static typesystems. But despite everything the central core of functional programmingis the idea of nonmutable state—that x isn’t the name of a location inmemory; it’s a value. So it can’t change. We say x equals three and you can’tchange it thereafter. All these different communities say that has enormousbenefits for understanding your program and for parallelizing your programand for debugging your program. Then there are functional languages withdynamic type systems like Erlang and functional languages with static typesystems and they’ve both got their good and bad points.

It’d be really nice to have the benefits of a static type system in Erlang.Maybe in certain places we could annotate programs to make the typesmore explicit so the compiler can derive the types and generate muchbetter code.

Then the static type people say, “Well, we really rather like the benefits ofdynamic types when we’re marshaling data structures.” We can’t send anarbitrary program down a wire and reconstruct it at the other end becausewe need to know the type. And we have—Cardelli called it a system that’spermanently inconsistent. We have systems that are growing and changingall the time, where the parts may be temporarily inconsistent. And as Ichange the code in a system, it’s not atomic. Some of the nodes change,others don’t. They talk to each other—at certain times they’re consistent.At other times—when we go over a communication boundary—do wetrust that the boundary is correct? They might fib. So we need to checkcertain stuff.

Seibel: So early on you earned your beer by debugging other people’sprograms. Why do you think you were such a good debugger?

Armstrong: Well, I enjoyed debugging. At this point in the program youprint out a few variables and things to see what’s going on and they’re allaccording to what you expect. And at this point in the program it’s right.And somewhere later it’s wrong. So you look halfway in between—it’seither right or wrong and you just do this interval halving. Provided you canreproduce an error. Errors that are nonreproducible, that’s pretty difficultto debug. But they weren’t giving me that. They were giving mereproducible errors. So just carry on halving until you find it. You mustultimately find it.

Seibel: So do you think you just had a more systematic view?

Armstrong: Yeah, they gave up. I don’t know why—I couldn’t reallyunderstand why they couldn’t debug programs. I mean, do you thinkdebugging is difficult? I don’t. You just stop it and slow it down. I mean, I’mjust talking about batch Fortran.

OK, debugging real-time systems or garbage collectors—I remember onceErlang crashed—it was early days—and it crashed just after I’d started it. Iwas just typing something. It had built in sort of Emacsy commands into theshell. And I typed erl to start it and you get into a read-eval-print loop. AndI’d typed about four or five characters and made a spelling mistake. Andthen I backed the cursor a couple of times and corrected it and it crashedwith a garbage collection error. And I knew that’s a deep, deep, error. And Ithought, “Can I remember exactly what did I type in?” Because it was onlyabout 12 characters or something. I restarted and typed and it didn’t crash.And I sat there for like an hour and a half trying probably a hundreddifferent things. Then it crashed again! Then I wrote it down. Then I coulddebug it.

Seibel: What are the techniques that you use there? Print statements?

Armstrong: Print statements. The great gods of programming said, “Thoushalt put printf statements in your program at the point where you thinkit’s gone wrong, recompile, and run it.”

Then there’s—I don’t know if I read it somewhere or if I invented itmyself—Joe’s Law of Debugging, which is that all errors will be plus/minusthree statements of the place you last changed the program. When Iworked at the Swedish Space Corporation my boss was a hardware guy.We were up at Esrange, the rocket-launching site and satellite-trackingstation in the north. And one time he was banging his head, debugging somebug in the hardware, plugging in oscilloscopes, and changing things. And Isaid, “Oh, can I help?” And he said, “No Joe, you can’t help here—this ishardware.” And I said, “Yeah, but it must be like software—the bug will bepretty near to the last change you made to the hardware.” And he went, “Ichanged a capacitor. You’re a genius!” He’d replaced one capacitor with abigger capacitor and he unsoldered it and put the original one back and itworked. It’s the same everywhere. You fix your car and it goes wrong—it’sthe last thing you did. You changed something—you just have to rememberwhat it was. It’s true with everything.

Seibel: So have you ever proved any of your programs correct? Has thatkind of formalism ever appealed to you?

Armstrong: Yes and no. I’ve manipulated programs algebraically to justshow that they were equivalent. Haven’t really gone into theorem provingas such. I did a course in denotational semantics and things like that. Iremember giving up. The exercise was given: let x = 3 in let y = 4 in xplus y show that the eager evaluation scheme given by the equations fooand the lazy evaluation scheme given by the equations bar, both evaluate toseven.

Fourteen pages of lemmas and things later I thought, “Hang on—x is three,y is four, x plus y; yeah seven.” At the time I was writing the Erlangcompiler. If it took lots of pages to prove that three plus four is seven thenthe proof that my compiler was in any sense correct would have beenthousands and thousands of pages.

Seibel: Do you prefer to work alone or on a team?

Armstrong: I like a workplace of teams, if you see what I mean. I’m notantisocial. But I just like programming by myself. Certainly I likecollaborating with people in the sense of discussing problems with them. Ialways thought the coffee break that you have when you got to work andout came all the ideas that you’d had on your walk to work was veryvaluable. You get a lot of insights then. Good to thrash your ideas out infront of the crowd. You’re put in a position of explaining your ideas which,for me, moves them from one part of my brain to another part. Often whenyou explain things then you understand them better.