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

Seibel: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.

Seibel: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.”

Then we found somebody inside Ericsson who wanted a new programming language or wanted a better way of programming telephony. We met up with them once a week for about, I can’t remember, six months, nine months. And the general idea was we would teach them how to program and they would teach us about telephony—what the problem was. I remember it was both frustrating and very stimulating. That changed the language because we had real people using it and that resulted in a study where they thought, “Yeah, this would be OK but it’s far too slow”—they measure the performance of it and said, “It’s gotta be 70 times faster.” So then we said, “This phase is now over. We’ll make it go 70 times faster and they’ll carry on programming it and we have to do this in two years or something.”

We had several false starts. And we had several really embarrassing moments. Big mistake: don’t tell people how fast something is going to be before you’ve implemented it. But ultimately we figured out how to do it. I wrote a compiler in Prolog. And Rob was doing the libraries and things. We’re now kind of two years in. Then I thought I could implement this abstract machine in C so I started writing my first-ever C. And Mike Williams came along and looked at my C and said, “This is the worst C I’ve ever seen in my entire life. This is appallingly bad.” I didn’t think it was that bad but Mike didn’t like it. So then Mike did the virtual machine in C and I did the compiler in Prolog. Then the compiler compiled itself and produced byte-code and you put it in the machine and then we changed the grammar and the syntax and compiled the compiler in itself and came out with an image that would bootstrap and then we’re flying. We’ve lost our Prolog roots and we’re now a language.

Seibel:Has there ever been anything that you’ve found difficult to work into the Erlang model?

Armstrong:Yeah. We abstract away from memory, completely. If you were turning a JPEG image into a bitmap data, which depends on the placement of the data in a very exact sense, that doesn’t work very well. Algorithms that depend on destructively upgrading state—they don’t work well.

Seibel:So if you were writing a big image processing work-flow system, then would you write the actual image transformations in some other language?

Armstrong:I’d write them in C or assembler or something. Or I might actually write them in a dialect of Erlang and then cross-compile the Erlang to C. Make a dialect—this kind of domain-specific language kind of idea. Or I might write Erlang programs which generate C programs rather than writing the C programs by hand. But the target language would be C or assembler or something. Whether I wrote them by hand or generated them would be the interesting question. I’m tending toward automatically generating C rather than writing it by hand because it’s just easier.

But I’d use an Erlang structure. I’ve got some stuff that does my family images and things. So I use ImageMagik with some shell scripts. But I control it all from Erlang. So I just write wrappers around it and call os:commandand then the ImageMagik command. So it’s quite nice to wrap up things in. Wouldn’t want to do the actual image processing in Erlang. It’d be foolish to write that in Erlang. C’s just going to be a lot better.

Seibel:Plus, ImageMagik is already written.

Armstrong:That doesn’t worry me in the slightest. I think if I was doing it in OCaml then I would go down and do it because OCaml can do that kind of efficiency. But Erlang can’t. So if I was an OCaml programmer: “OK, what do I have to do? Reimplement ImageMagik? Right, off we go.”

Seibel:Just because it’s fun?

Armstrong:I like programming. Why not? You know, I’ve always been saying that Erlang is bad for image processing—I’ve never actually tried. I feel it would be bad but that might be false. I should try. Hmmm, interesting. You shouldn’t tempt me.

The really good programmers spend a lot of time programming. I haven’t seen very good programmers who don’t spend a lot of time programming. If I don’t program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly.

Seibel:Is there anything that you have done specifically to improve your skill as a programmer?

Armstrong:No, I don’t think so. I learned new programming languages but not with the goal of becoming a better programmer. With the goal of being a better language designer, maybe.

I like to figure out how things work. And a good test of that is to implement it yourself. To me programming isn’t about typing code into a machine. Programming is about understanding. I like understanding things. So why would I implement a JPEG thing like we talked about earlier? It’s because I’d like to understand wavelet transforms. So the programming is a vehicle to understand wavelet transformations. Or why do I try to do an interface to X Windows? Because I wanted to understand how the X protocol worked.

It’s a motivating force to implement something; I really recommend it. If you want to understand C, write a C compiler. If you want to understand Lisp, write a Lisp compiler or a Lisp interpreter. I’ve had people say, “Oh, wow, it’s really difficult writing a compiler.” It’s not. It’s quite easy. There are a lot of little things you have to learn about, none of which is difficult. You have to know about data structures. You need to know about hash tables, you need to know about parsing. You need to know about code generation. You need to know about interpretation techniques. Each one of these is not particularly difficult. I think if you’re a beginner you think it’s big and complicated so you don’t do it. Things you don’t do are difficult and things you’ve done are easy. So you don’t even try. And I think that’s a mistake.