Erlang Book - again
Tue Aug 29 20:05:11 CEST 2006
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
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
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
More information about the erlang-questions