Erlang Book - again

[Richard Cameron]

On 29 Aug 2006, at 16:40, Joe Armstrong ((TN/EAB)) wrote:

> For those who are interested I have started writing a new book.
>
> It has proved to be difficult to find a publisher so I will be  
> using a print on demand service to print the book.

Has anyone pitched the idea of an Erlang book to O'Reilly recently?  
Of all the publishers I can think of, they seem to be the ones who  
continually dredge popular opinion to try to predict what the Next  
Big Thing(tm) is going to be. Whereas our beloved British government  
utilises focus groups and cappuccinos to decide future legislation,  
O'Reilly seem to trawl through blog posts and social bookmarking  
sites just to get down with the kids and see what they're "digging".  
They've even gone to the bother of setting up things like this  
<http://buzz.research.yahoo.com/>.

I've noticed there's been a glut of Erlang stories in the last few  
weeks, especially on <http://programming.reddit.com/>. It seems that  
anything to do with concurrency or Erlang becomes an instant hit.   
While this is obviously a great thing for the evangelical erlangers,  
all the articles (out of necessity - you can't fit a textbook in a  
blog post) are very "big picture". There's lots of very sensible  
advocacy of how one ought to think about concurrency both mentally  
and in code, lots of analogies with the real world, and it's  
obviously pulling in the crowds. The trouble is that there's no way  
of saying "If you liked the ideas in the article then buy the book  
and see how it *actually* works."

What seems to be an especially acute problem for us at the moment in  
our office is coverage of OTP. We find that it's pretty much trivial  
to get someone to pick up Erlang syntax and write code to spawn  
processes and send messages. Where everything tends to break down is  
when I try explaining what OTP even *is*. I really want a text which  
explains the ideas behind, say, gen_servers and shows why you'd even  
want to use something as abstruse as them in the first place.

The C++ brigade have that incredibly dry and dense "Design Patterns"  
text which they squabble over when they're trying to put a name to  
part of a UML diagram (a little like trying to name the  
constellations). While I'm not proposing that anyone writes anything  
like that for Erlang, I would like something which gives an idea of  
how you go about designing software by drawing little boxes on a  
piece of paper representing processes, and a whole bunch of arrows  
scribbled on top representing messages. There are certain motifs  
which crop up again and again - basically the standard OTP behaviours  
- and it would be nice if there were a text which explained what  
these patterns are, and how you can go about implementing them (or  
getting them for free from the standard behaviours).

I first learnt Erlang by reading up on all the ideas and realising  
that it was a rather strange (or, at least, different) way of  
programming to anything I'd done before and that it was probably  
quite powerful (although I didn't realise how powerful at the time).  
I then forgot about it for five years until I actually had a project  
which needed it. The first code I wrote in anger was a collection of  
horrible ad-hoc message passing protocols which re-implement a lot of  
stuff found in OTP. I didn't know about gen_server:reply/2, for  
example, and I still have the Heath Robinson code I wrote to try to  
reinvent the wheel running in my production system. I'm too scared to  
touch it at the moment, but I expect it'll eventually end up on the  
chopping block to be replaced with a much simpler and neater OTP  
implementation at some point.

Staring out, it felt like someone had handed me a very powerful but  
dangerous power-tool (Erlang), but not quite explained how to use it  
properly. As a result, I tore off writing software like a cowboy  
builder who had bought a bunch of tools off his mate in the pub and  
then decided to go into business building patios. What I wished I had  
at the time was a text explaining roughly how one ought to go about  
things sensibly, and in non-cowboy fashion. I eventually got that by  
going on one of Francesco's training courses. I'm glad I did, but  
only because there was no other realistic way of obtaining that  
information.

Paradoxically, since then I've found myself using progressively less  
and less of the standard OTP behaviours and more and more "pure  
Erlang" using sys and proc_lib. I couldn't have understood any of  
this if I hadn't picked up OTP on the way, and that's the big thing  
which is missing from any Erlang book (unless you happen to read  
French).

Richard.