Armstrong: Choice of problem, I think. Are you driven by the problemsor by the solutions? I tend to favor the people who say, “I’ve got this reallyinteresting problem.” Then you ask, “What was the most fun project youever wrote; show me the code for this stuff. How would you solve thisproblem?” I’m not so hung up on what they know about language X or Y.From what I’ve seen of programmers, they’re either good at all languages orgood at none. The guy who’s a good C programmer will be good atErlang—it’s an incredibly good predictor. I have seen exceptions to that butthe mental skills necessary to be good at one language seem to convert toother languages.

Seibel: Some companies are famous for using logic puzzles duringinterviews. Do you ask people that kind of question in interviews?

Armstrong: No. Some very good programmers are kind of slow at thatkind of stuff. One of the guys who worked on Erlang, he got a PhD in math,and the only analogy I have of him, it’s like a diamond drill drilling a holethrough granite. I remember he had the flu so he took the Erlang listingshome. And then he came in and he wrote an atom in an Erlang program andhe said, “This will put the emulator into an infinite loop.” He found theinitial hash value of this atom was exactly zero and we took something modsomething to get the next value which also turned out to be zero. So hereverse engineered the hash algorithm for a pathological case. He didn’teven execute the programs to see if they were going to work; he read theprograms. But he didn’t do it quickly. He read them rather slowly. I don’tknow how good he would have been at these quick mental things.

Seibel: Are there any other characteristics of good programmers?

Armstrong: I read somewhere, that you have to have a good memory tobe a reasonable programmer. I believe that to be true.

Seibel: Bill Gates once claimed that he could still go to a blackboard andwrite out big chunks of the code to the BASIC that he written for theAltair, a decade or so after he had originally written it. Do you think youcan remember your old code that way?

Armstrong: Yeah. Well, I could reconstruct something. Sometimes I’vejust completely lost some old code and it doesn’t worry me in the slightest.I haven’t got a listing or anything; just type it in again. It would be logicallyequivalent. Some of the variable names would change and the ordering ofthe functions in the file would change and the names of the functions wouldchange. But it would be almost isomorphic. Or what I would type in wouldbe an improved version because my brain had worked at it.

Take the pattern matching in the compiler which I wrote ten years ago. Icould sit down and type that in. It would be different to the original versionbut it’d be an improved version if I did it from memory. Because it sort ofimproves itself while you’re not doing anything. But it’d probably have apretty similar structure.

I’m not worried about losing code or anything like that. It’s these patterns inyour head that you remember. Well, I can’t even say you remember them.You can do it again. It’s not so much remembering. When I say you canremember a program exactly, I don’t think that it’s actually remembering.But you can do it again. If Bill could remember the actual text, I can’t dothat. But I can certainly remember the structure for quite a long time.

Seibel: Is Erlang-style message passing a silver bullet for slaying the problemof concurrent programming?

Armstrong: Oh, it’s not. It’s an improvement. It’s a lot better than sharedmemory programming. I think that’s the one thing Erlang has done—it hasactually demonstrated that. When we first did Erlang and we went toconferences and said, “You should copy all your data.” And I think theyaccepted the arguments over fault tolerance—the reason you copy all yourdata is to make the system fault tolerant. They said, “It’ll be terriblyinefficient if you do that,” and we said, “Yeah, it will but it’ll be faulttolerant.”

The thing that is surprising is that it’s more efficient in certaincircumstances. What we did for the reasons of fault tolerance, turned outto be, in many circumstances, just as efficient or even more efficient thansharing.

Then we asked the question, “Why is that?” Because it increased theconcurrency. When you’re sharing, you’ve got to lock your data when youaccess it. And you’ve forgotten about the cost of the locks. And maybe theamount of data you’re copying isn’t that big. If the amount of data you’recopying is pretty small and if you’re doing lots of updates and accesses andlots of locks, suddenly it’s not so bad to copy everything. And then on themulticores, if you’ve got the old sharing model, the locks can stop all thecores. You’ve got a thousand-core CPU and one program does a globallock—all the thousand cores have got to stop.

I’m also very skeptical about implicit parallelism. Your programminglanguage can have parallel constructs but if it doesn’t map into hardwarethat’s parallel, if it’s just being emulated by your programming system, it’snot a benefit. So there are three types of hardware parallelism.

There’s pipeline parallelism—so you make a deeper pipeline in the chip soyou can do things in parallel. Well, that’s once and for all when you designthe chip. A normal programmer can’t do anything about the instructionlevelparallelism.

There’s data parallelism, which is not really parallelism but it has to do withcache behavior. If you want to make a C program go efficiently, if *p is on a16-byte boundary, if you access *p, then the access to *(p + 1) is free,basically, because the cache line pulls it in. Then you need to worry abouthow wide the cache lines are—how many bytes do you pull in in one cachetransfer? That’s data parallelism, which the programmer can use by beingvery careful about their structures and knowing exactly how it’s laid out inmemory. Messy stuff—you don’t really want to do that.

The other source of real concurrency in the chip are multicores. There’ll be32 cores by the end of the decade and a million cores by 2019 or whatever.So you have to take the granules of concurrency in your program and mapthem onto the cores of the computer. Of course that’s quite a heavyweightoperation. Starting a computation on a different core and getting the answerback is itself something that takes time. So if you’re just adding two numberstogether, it’s just not worth the effort—you’re spending more effort inmoving it to another core and doing it and getting the answer back than youare in doing it in place.

Erlang’s quite well suited there because the programmer has said, “I want aprocess, I want another process, I want another process.” Then we just putthem on the cores. And maybe we should be thinking about actuallyphysically placing them on cores. Probably a process that spawns anotherprocess talks to that process. So if we put it on a core that’s physically near,that’s a good place to put it, not on one that’s a long way away. And maybeif we know it’s not going to talk to it a lot maybe we can put it a long wayaway. And maybe processes that do I/O should be near the edge of thechip—the ones that talk to the I/O processes. As the chips get bigger we’regoing to have to think about how getting data to the middle of the chip isgoing to cost more than getting it to the edge of the chip. Maybe you’ve gottwo or three servers and a database and maybe you’re going to map thisonto the cores so we’ll put the database in the middle of the chip and theseones talk to the client so we’ll put them near the edge of the chip. I don’tknow—this is research.

Seibel: You care a lot about the idea of Erlang’s way of doing concurrency.Do you care more about that idea—the message-passing shared-nothingconcurrency—or Erlang the language?