[erlang-questions] A new erlang book?

G Bulmer gbulmer@REDACTED
Thu Sep 20 04:05:40 CEST 2007

Fundamentally, I like books that I can use to get developers up the  
learning curve faster, or to give a base for fun weekend hacking.

I've lead development groups, and I've found it easier for staff to  
engage with bite-size pieces, which they could read and usefully  
experiment with in a week or two, part time.
Of course it had to be information-dense, and they had to be  
reasonably bright and interested (which may be too small a market to  
attract your publisher :-(
I really like books with relatively short, focused, chapters which  
can be used in 'reading circles' with developers every week or  
better. With plenty of working code snippets, so they can try this  
stuff, and not just leave it on the page. When a book and its  
technology supports engineers doing 5 minute experiments, they can  
really learn rapidly, and bring evidence to a debate. I think Joe's  
book demonstrates that Erlang is an excellent vehicle for this. Joe's  
use of the Erlang shell (and also Graham Hutton's Haskell  
Programming) got me typing along, which I think is a mark of a very  
good programming book based on a viable, potentially vibrant,  

Joshua Bloch's "Effective Java" was good for reading circles as each  
'tip' was quite short, and the group could assign 'lead' at a fine  
grain (over 100 tips), and pull everyone into really analysing,  
debating and understanding the information. One group got so  
interested that they met every day (instead of just twice/week) for a  
several weeks to cover the tips I asked them to analyse.

So, $0.01 of my $0.02 is for slimmer books in the style of Effective  
Java, or these "Practical Guides":
which are 128 and 180 pages.
While I accept the content could be improved, I liked them as a  
platform for fun hacking over a few weekends (I don't believe I just  
wrote that :-)

Whinge { I feel that a lot of the 600+ page books contain lots of  
stuff that I don't want, and more filler than a McD%~@<)& thick  
shake; they have very low information to paper content (sadly, IMHO,  
some of the other pragmatic programmers books suffer, and they are  
quite slim too :-( }

Areas I would have liked covered in Joe's book are mentioned in my  
review of the book at amazon.co.uk, but I will elaborate:

1. This may seem to be bit cynical, but compare and contrast Erlang/ 
OTP with the "Web application architecture" * of Java+Structs 
+Hibernate+...+Oracle/... MS.NET, 'LAMP' etc. I don't feel this is  
the sweetest spot for Erlang (but I am happy to be corrected). My aim  
would be to provide a way of understanding what OTP is good for, and  
a 'model' within which Erlang/OTP's benefits can be usefully  
identified and highlighted. It should build complete working systems.  
This should help astute developers to understand the breadth and  
depth of OTP, and how to use and deploy it appropriately.
I'd probably try to support "richer client's" too (e.g. AJAX, REST,  
etc, etc) as that should demonstrate a 'sexy hook' that developers  
seem to be interested in learning and trying out. If the publisher  
already has an AJAX book, maybe complement that with Erlang services?
This is likely too much work unless someone really wants to make  
Erlang 'the next Java'. So, maybe a collaborative community effort?

2. Some in-depth, larger scale, richer functionality, OTP apps.  
Maybe, an Erlang replacement for Skype, but using standards, would be  
fun. Maybe explore the ejabber code base, and build-out/highlight  
some interesting/useful/fun architecture and functionality?
Better still, just dig into chunks of OTP itself to highlight key  
issues and explore actual solutions. I'd like to see measurement and  
analysis as a major axes in here too. IMHO, there is premature  
optimisation, based on unsound basis, still going on. OTP provides a  
code base which is in production, and based on experience. So this  
book would be aimed at the aspiring 'architect'.

3. String and text processing in an Erlang context. FP books often  
cover parsing/transformation for good reason (IMHO, the OO 'visitor'  
pattern is not that cool when using a language that has pattern  
matching built in:-). This would be handy, as lots of raw data comes  
in textual form. I'd like to understand the idioms that experienced  
Erlang developers use. Maybe be very radical and compared to e.g.  
Haskell, or Ruby, or Java. Examples? Maybe several alternative SPAM  
filter techniques? This would let you exploit parallelism, data  
storage, etc too.

4. Finer-grained parallelism. Light-weight processes and messaging  
help, but I feel there needs to be more elaboration than Joe's book;  
there are issues around resource management, scaling, co-ordination,  
etc. which Joe's book highlights, but doesn't necessarily dig into in  
depth (this isn't a criticism, it already covers a lot of ground at a  
good level). I have no inspiration about the focus, but maybe all the  
other topic areas could benefit from a careful interweaving of these  

There is a plethora of other stuff **, but I have to decide if I  
might want to do those things myself ;-)

* - I accept that many developers seem to think 'Architecture' is  
just a bunch of old J2EE/.NET power point slides with the current  
customers logo attached, but I'm not one of them, I use 'web  
application architecture' as a shorthand for a broad range of stuff
** - That final tease is a bit naughty, but I'm like that at this  
time of night.

> Date: Wed, 19 Sep 2007 09:01:18 -0600
> From: "pat eyler" <pat.eyler@REDACTED>
> Subject: [erlang-questions] A new erlang book?
> The other day, a publisher asked me what I thought about the
> potential market for books on Functional Programming.  As we
> talked, it became obvious that they want to play in this space
> and are looking for some feedback.  It sounds like they want to
> put out a (some) book(s) that are a little bit more advanced than
> Joe's Programming Erlang, or the upcoming O'Reilly book on
> Haskell without doing yet another dry, academic tome.
> I'd love to collect some feedback about:
> Why Erlang is (or isn't) the right language.
> Who might be interested in/good at writing such a
> book?
> What topic(s) should be covered?
> Would it be better to write a traditional, big book or several
> smaller e-book/print books (in the 100-150 page range) about
> individual topics?

More information about the erlang-questions mailing list