Armstrong: Really? I must try that.
Seibeclass="underline" Talk to your cats.
Armstrong: The cats—absolutely! I worked with this guy who was slightly older than me and very clever. And every time I’d go into his office and ask him a question, every single question, he would say, “A program is a black box. It has inputs and it has outputs. And there is a functional relationship between the inputs and the outputs. What are the inputs to your problem? What are the outputs to your problem? What is the functional relationship between the two?” And then somewhere in this dialog, you would say, “You’re a genius!” And you’d run out of the room and he would shake his head in amazement—“I wonder what the problem was, he never said.” So he’s your bear which you explain the problem to.
Seibeclass="underline" The doodling—is that writing little snippets of code or is it literally graphical doodles?
Armstrong: It’s more bubbles with arrows. You know when you explain things to people on a white board—you draw bubbles and arrows and equations and notations. Not code. Code fragments—piddly bits of code sometimes because that’s a compact way to express something. This is in the thinking period. Very occasional code experiments because I don’t know how long it takes to do something. So I’ll write ten lines of code and time something.
Seibeclass="underline" You mean how long it takes for the computer to do it?
Armstrong: Yeah. Does that take a millisecond or a microsecond—I don’t know. I can guess but I want to confirm that guess. And so I’m only looking at the bits I don’t really know. But I have a great stock of experience programming Erlang so I know pretty much what things are going to do. Problem solving was the same years ago. It was, identify the difficult bits, write the small prototypes, identify the areas of uncertainty, writing very small bits of code. Essentially I do the same thing now but I have less reason to do these small experiments. If it’s Erlang. If I’m doing Ruby or Java then I have to go back and do a lot of experiments because I don’t know what’s going to happen.
Seibeclass="underline" Then somewhere in this thinking process you get to the point where you know how to write the code?
Armstrong: Yeah, then all the bits fit together. But maybe I can’t explain it to anybody. I just get a very strong feeling that if I start writing the program now it’ll work. I don’t really know what the solution is. It’s like an egg. The chicken’s ready to lay the egg. Now I’m ready to lay the egg.
Seibeclass="underline" And that’s the point at which you need to go into flow and not be interrupted.
Armstrong: Yes, yes.
Seibeclass="underline" So there are still presumably a lot of details to be sorted out at the code level which requires your concentration.
Armstrong: Oh yes. But then there are two types of those things. The stuff that really needs the concentration is the stuff that is not automatic—you’ve got to think about it. You’ve got this really tricky garbage collection—exactly what needs to be marked and exactly where—you’ve got to think hard about that. You know you’ll find a solution because you’ve kind of bounded it in. And you know it’s in the right little black box.
Michelangelo is doing the roof of the Sistine Chapel or something and he’s got a whole team of painters helping him. So he would sketch the big picture first. These huge areas have got to be done in blue and green. So that’s rather like writing a program. The first sketch is this broad sketch where everything’s in the right place. Some of these places are going to be filled with uniform color and just can be filled in fairly rapidly—you don’t have to think.
And then you get to the details of the eyes—that’s tricky stuff. You know you can do it. And the eye is in the right place because the picture is OK. So you go and do the eye and the detail. That’s not to say that’s easy—that’s the difficult bit, actually. You’ve got to really concentrate while you’re doing the eye. You don’t have to really concentrate while you’re doing the forehead or the cheeks because they’re fairly uniform. A bit of stubble here so you pay a sort of half concentration.
Then type it all in and get the syntax errors out and run a few little tests to make sure it works. And that’s all rather relaxing. See a little compiler error there and you fix it. Once you’re experienced at a language you don’t even bother to read the diagnostic. It just says the line number—you don’t read what it says. That line—oh, yeah. That’s wrong, you retype it.
I gave a course in Erlang in Chicago. I was wandering around the class and I’d notice, there’s something wrong. Oh, there’s a comma missing there or that’ll crash before that happens and you’re not linked. My wife’s very good at proofreading and she says errors spring out of the page at you. A missing comma or a spelling mistake—they literally spring out of the page at her.
And programming errors just spring out of the page if I look at other people’s code, wandering around. It doesn’t feel like conscious thought is involved—it’s holistic. You see everything on the screen and there’s the error, bumpf. So it’s just a matter of correcting those surface errors.
One that’s tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won’t occur. If you’ve got a long variable like personName and you’ve got personNames with an “s” on the end, that’s a list of person names, that will be something that my eye will tend to read what I thought it should have been. And so I’d have personName and then listOfPeople. And I do that deliberately because I know that my eye will see what I thought I’d written. But punctuation, I do see that—I do see the commas and the brackets as being wrong. And of course Emacs colors everything and auto-indents and the brackets are different colors. So this is really easy.
Seibeclass="underline" At the point that you start typing code, do you code top-down or bottom-up or middle-out?
Armstrong: Bottom up. I write a little bit and test it, write a little bit and test it. I’ve gone over to this writing test cases first, now. Unit testing. Just write the test cases and then write the code. I feel fairly confident that it works.
Seibeclass="underline" Back to a bit of your history, it was after the Swedish Space Corporation that you went to Ericsson’s research lab?
Armstrong: Yes. And it was a very, very fortunate time to come, it must have been ’84. I think I had come to the lab something like two years after it had started. So we were very optimistic. Our view of the world was, yes we’ll solve problems and then we’ll push them into projects and we will improve Ericsson’s productivity. This view of the world wasn’t yet tinged by any contact with reality. So we thought it would be easy to discover new and useful stuff and we thought that once we had discovered new and useful stuff then the world would welcome us with open arms. What we learned later was, it wasn’t all that easy to discover new stuff. And it’s incredibly difficult to get people to use new and better stuff.
Seibeclass="underline" And Erlang was one of those new and useful things you expected them to use?
Armstrong: Yes. Absolutely. So what happened was, first of all it was just Prolog. I sort of made a little language and people started using it. And then Robert Virding came along and said, “Hey, this looks like fun.” And he’d been reading my Prolog and he said, “Can I modify it a bit?” That’s pretty dangerous because Robert says that and you end up with one comment at the top of the program that says, “Joe thought of this stuff and I’ve changed a bit,” and then it’s completely changed. So Robert and I just rewrote this stuff back and forth and we had great arguments—“Ahhh, I can’t read your code, it’s got blanks after all the commas.”