Also, I think today we’re kind of overburdened by choice. I mean, I just hadFortran. I don’t think we even had shell scripts. We just had batch files soyou could run things, a compiler, and Fortran. And assembler possibly, if youreally needed it. So there wasn’t this agony of choice. Being a youngprogrammer today must be awful—you can choose 20 differentprogramming languages, dozens of framework and operating systemsandyou’re paralyzed by choice. There was no paralysis of choice then. You juststart doing it because the decision as to which language and things is justmade—there’s no thinking about what you should do, you just go and do it.

Seibel: Another difference these days is that you can no longer understandthe whole system from top to bottom. So not only do you have lots ofchoices to make, they’re all about which black boxes you want to usewithout necessarily fully understanding how they work.

Armstrong: Yeah—if these big black boxes don’t work properly, and youhave to modify them, I reckon it’s easier just to start from scratch and justwrite everything yourself. The thing that really hasn’t worked is softwarereuse. It’s appallingly bad.

Seibel: Yet you’re the architect not only of Erlang but of an applicationframework, the Open Telecom Platform. Is it reusable?

Armstrong: To an extent it’s reusable. But the same problem will occur. Ifthat framework exactly solves your problem—if some programmer whodoesn’t know anything about the design criteria for OTP looks at it in a fewyears’ time and says, “Oh, that’s great; that’s exactly what I want to do,”then it’s fine and you get this measure of reusability. If it’s not, then you havea problem.

Fairly recently I’ve seen people say, “This is really kind of artificial, we’retwisting the code to fit into this OTP framework.” So I say, “Well, rewritethe OTP framework.” They don’t feel they can change the framework. Butthe framework’s just another program. It’s really rather easy. And I go intoit and then it does what they want. They look at it and they say, “Yeah, well,that’s easy.” They accept that it’s easy. But they say, “Well, our projectmanagement doesn’t want us messing around with the framework.” Well,give it a different name then or something.

Seibel: But do you think it’s really feasible to really open up all those blackboxes, look inside, see how they work, and decide how to tweak them toone’s own needs?

Armstrong: Over the years I’ve kind of made a generic mistake and thegeneric mistake is to not open the black box. To mentally think, this blackbox is so impenetrable and so difficult that I won’t open it. I’ve opened upone or two black boxes: I wanted to do a windowing system, a graphicssystem for Erlang, and I thought, “Well, let’s run this on X Windows.” Whatis X Windows? It’s a socket with a protocol on top of it. So you just openthe socket and squirt these messages down it. Why do you need libraries?Erlang is message based. The whole idea is you send messages to things andthey do things. Well, that’s the idea in X Windows—you’ve got a window,send it a message, it does something. If you do something in the window itsends you a message back. So that’s very much like Erlang. The way ofprogramming X Windows, however, is through callback libraries—thishappens and call this. That’s not the Erlang way of thinking. The Erlang wayof thinking is, send a message to something and do something. So, hang on,let’s get rid of all these libraries in between—let’s talk directly to thesocket.

And guess what? It’s really easy. The X protocol’s got, I don’t know, 100messages, 80 messages or something. Turns out you only need about 20 ofthem to do anything useful. And these 20 messages you just map ontoErlang terms and do a little bit of magic and then you can start sendingmessages to windows directly and they do things. And it’s efficient as well.It’s not very pretty because I haven’t put much effort into graphics andartistic criteria—there’s a lot of work there to make it look beautiful. Butit’s not actually difficult.

Another one is this typesetting system I did where the abstraction boundaryI opened up is Postscript. As you get to that boundary you think, “I don’twant to go through the boundary,” because what’s underneath is—youimagine—enormously complicated. But again, it turns out to be very easy.It’s a programming language. It’s a good programming language. Theabstraction boundary is easy to go through and once you’ve gone through,there’s a lot of benefit.

For my Erlang book, my publisher said, “We’ve got tools to make diagrams.”But the thing I don’t like about diagramming tools is it’s really difficult to getan arrow to meet exactly. And your hand hurts. I thought, “The amount oftime to write a program that spits out Postscript and then say, ‘I want acircle there and the arrow goes exactly there,’ and get the program right,isn’t long.” It takes a few hours. Doing diagrams with programs takes aboutthe same time as doing them in a WYSIWYG thing. Only there are twobenefits. Your hand doesn’t hurt at the end and even when you blow thething up to a magnification of 10,000, the arrow points exactly right.

I can’t say beginner programmers should open up all these abstractions. Butwhat I am saying is you should certainly consider the possibility of openingthem. Not completely reject the idea. It’s worthwhile seeing if the directroute is quicker than the packaged route. In general I think if you buysoftware, or if you use other people’s software, you have to reckon with anextremely long time to tailor it—it doesn’t do exactly what you want, itdoes something subtly different. And that difference can take a very longtime to solve.

Seibel: So you started out saying software reuse is “appallingly bad,” butopening up every black box and fiddling with it all hardly seems likemovement toward reusing software.

Armstrong: I think the lack of reusability comes in object-orientedlanguages, not in functional languages. Because the problem with object-orientedlanguages is they’ve got all this implicit environment that they carryaround with them. You wanted a banana but what you got was a gorillaholding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions—allthe data comes in its input arguments and everything goes out and leaves nostate behind—it’s incredibly reusable. You can just reuse it here, there, andeverywhere. When you want to use it in a different project, you just cut andpaste this code into your new project.

Programmers have been conned into using all these different programminglanguages and they’ve been conned into not using easy ways to connectprograms together. The Unix pipe mechanism—A pipe B pipe C—is triviallyeasy to connect things together. Is that how programmers connect thingstogether? No. They use APIs and they link them into the same memoryspace, which is appallingly difficult and isn’t cross-language. If the language isin the same family it’s OK—if they’re imperative languages, that’s fine. Butsuppose one is Prolog and the other is C. They have a completely differentview of the world, how you handle memory. So you can’t just link themtogether like that. You can’t reuse things. There must be big commercialinterests for whom it is very desirable that stuff won’t work together. Itcreates thousands of jobs for consultants. And thousands of tools to solveproblems that shouldn’t exist. Problems that were solved years ago.

I think it’s really weird that we have very few programming languages thatdescribe the interaction between things. I keep coming back to ways ofgluing things together and ways of describing protocols. We don’t have waysof describing this protocol in between things: if I send you one of them thenyou send me one of these. We have ways of describing packets and theirtypes but we have very restricted ways of describing the protocols.