Bloch: I agree with you that people who are both smart enough to copewith enormous complexity and lack empathy with the rest of us may fallprey to that. They think, “I can understand this and I can use it, so it has tobe good.”

Seibel: Is there something intrinsic in programming that’s always going todraw people with that kind of mentality?

Bloch: Absolutely. We love brainteasers. But we have to temper this lovewith the knowledge that we’re solving real problems for real people. And ifwe don’t do that we are, essentially, whacking off. I think that part of thefailure of the first company that I was involved in was due to the fact thatwe didn’t understand that what we were doing wasn’t pure engineering.

We weren’t really thinking that the most important thing we could do wassolve real problems for real customers. The moment you lose sight of thatand who your customers are, you’re dead meat. But I do think that it tendsto conflict with the sort of people who are attracted to programming, whoare the people who love brainteasers. But I think you can have your cakeand eat it too. Keep that empathy gene on when you’re designing your APIs,but then, in order to make them run bloody fast, you can freely descendinto the puzzle palace.

You’ll have plenty of opportunity to solve brainteasers when designing andoptimizing algorithms and data structures, especially concurrent ones. Youhave to be able to think with mathematical precision about stuff that is quitecomplex, and you have to be able to come up with creative ways ofcombining primitives to achieve the desired effect.

But you have to know where you can and should apply that kind of thinkingand where it will just produce a system that is unmaintainable or unusable.

Seibel: Are the opportunities for doing that kind of programming goingaway? A lot of this low-level stuff is implemented in the VM that you’reusing or the concurrency libraries that you’re using. So for a lot of people,anymore, programming is about gluing stuff together.

Bloch: I totally agree. Well, in relative terms it’s diminishing. Thepercentage of programmers who have to do this is way smaller than it usedto be. Back when you bought a machine and it didn’t even have an operatingsystem on it, nevermind a programming language or any ready-writtenapplications, yeah, everybody had to do that.

The world in which most programmers have to do this is vanishing orvanished. But in absolute terms there’s probably as much need as there everwas for that sort of people. We want to have our cake and eat it too—wewant to have the advantages of safe languages coupled with the speed ofhand-tuned assembly code, so we need people to write these virtualmachines and these garbage collectors and design these chips which arethemselves basically works of software, albeit realized in hardware.

I think there’s plenty of employment for people who like doing this stuff, butwe have to carefully target them. I think if you have people who are purepuzzle solvers you have to couple them with management who can makesure that they are using their skills in the organization’s best interests.

There’s this problem, which is, programming is so much of an intellectualmeritocracy and often these people are the smartest people in theorganization; therefore they figure they should be allowed to make all thedecisions. But merely the fact that they’re the smartest people in theorganization doesn’t mean they should be making all the decisions, becauseintelligence is not a scalar quantity; it’s a vector quantity. And if you lackempathy or emotional intelligence, then you shouldn’t be designing APIs orGUIs or languages.

What we’re doing is an aesthetic pursuit. It involves craftsmanship as well asmathematics and it involves people skills and prose skills—all of these thingsthat we don’t necessarily think of as engineering but without which I don’tthink you’ll ever be a really good engineer. So I think it’s just something thatwe have to remind ourselves of. But I think it’s one of the most fun jobs onthe planet. I think we’re really lucky to have grown up at the time that wedid when these skills led to these jobs. I don’t know what we would havebeen doing a few generations back.

Joe Armstrong is best known as the creator of the programming language Erlangand the Open Telecom Platform (OTP), a framework for building Erlangapplications.

In the modern language landscape, Erlang is a bit of an odd duck. It is both olderand younger than many popular languages: Armstrong started work on it in1986—a year before Perl appeared—but it was available only as a commercialproduct and used primarily within Ericsson until it was released as open source in1998, three years after Java and Ruby appeared. Its roots are in the logicprogramming language Prolog rather than some member of the Algol family. Andit was designed for a fairly specific kind of software: highly available, highly reliablesystems like telephone switches.

But the characteristics that made it good for building telephone switchesalso—and almost inadvertently—made it quite well suited to writing concurrentsoftware, something which has drawn notice as programmers have startedwrestling with the consequences of the multicore future.

Armstrong, too, is a bit of an odd duck. Originally a physicist, he switched tocomputer science when he ran out of money in the middle of his physics PhD andlanded a job as a researcher working for Donald Michie—one of the founders ofthe field of artificial intelligence in Britain. At Michie’s lab, Armstrong was exposedto the full range of AI goodies, becoming a founding member of the BritishRobotics Association and writing papers about robotic vision.

When funding for AI dried up as a result of the famous Lighthill report, it was back tophysics-related programming for more than half a decade, first at the EISCATscientific association and later the Swedish Space Corporation, before finally joiningthe Ericsson Computer Science Lab, where he invented Erlang.

In our several days of conversation over his kitchen table in Stockholm, we talkedabout, among other things, the Erlang approach to concurrency, the need forbetter and simpler ways of connecting programs, and the importance of openingup black boxes.

Seibel: How did you learn to program? When did it all start?

Armstrong: When I was at school. I was born in 1950 so there weren’tmany computers around then. The final year of school, I suppose I musthave been 17, the local council had a mainframe computer—probably anIBM. We could write Fortran on it. It was the usual thing—you wrote yourprograms on coding sheets and you sent them off. A week later the codingsheets and the punch cards came back and you had to approve them. Butthe people who made the punch cards would make mistakes. So it might gobackwards and forwards one or two times. And then it would finally go tothe computer center.

Then it went to the computer center and came back and the Fortrancompiler had stopped at the first syntactic error in the program. It didn’teven process the remainder of the program. It was something like threemonths to run your first program. I learned then, instead of sending oneprogram you had to develop every single subroutine in parallel and send thelot. I think I wrote a little program to display a chess board—it would plot achess board on the printer. But I had to write all the subroutines as paralleltasks because the turnaround time was so appallingly bad.

Seibel: So you would write a subroutine with, basically, a unit test so youwould see that it had, in fact, run?