book ideas

[Michael Turner]

Not to get More Meta Than Thou, but Garrett's point here about the
usefulness of a Patterns-directed treatment of Erlang has a useful
generalization: most people are coming to Erlang *from somewhere*, and
it's inefficient to not consider their world of origin when explaining
where they've arrived with Erlang.  Software patterns were largely
motivated by the desire for a common vocabulary for talking about
recurring practices in coding and structuring programs.  Because
software patterns aren't language-specific, and are now much better
known than a decade ago, you could use them to structure an "aerial
view" tour of Erlang/OTP and realistically hope to gain a fairly wide
audience.

More concretely, someone could write, say, Erlang for the Java
Programmer. The narrative might largely recapitulate the typical
tutorial presentation order for Java, while developing an understanding
of Erlang in terms of similarities and differences between the two
languages, their standard libraries and tools, and the architectural
choices typically made in writing programs.

There's also room, I believe, for a bits&bytes/nuts&bolts bottom-up
treatment.  Because of how my brain works (or perhaps because of how it
doesn't), I often need things to be very concrete.  When I was first
learning C++, for example, I found myself deeply suspicious of most
explanations of member function calls (AKA "method dispatch" in some
other OO languages).  It wasn't until I could read a member function
invocation as a C expression evaluating to a function reference that I
felt I truly understood.  (Reading Cfront output was helpful in this.) 
I could compare C++'s way with how I'd "faked" OO myself in other
contexts, pre-C++, and to how Smalltalk did method dispatch, which I
understood pretty well from studying its VM.  The audience for some slim
volume about The Architecture of the Erlang VM might be relatively
small, but nevertheless influential all out of proportion to its numbers.

-michael turner

On 2/20/2010, "Garrett Smith" <g@REDACTED> wrote:

>On Fri, Feb 19, 2010 at 10:49 PM, Michael Turner <leap@REDACTED> wrote:
>>
>>
>> On 2/19/2010, "Geoff Biggs" <geoffrey.biggs@REDACTED> wrote:
>>
>>>8) A cookbook (I don't think any of the other options adequately covers
>>>this). The recipes books that O'Reilly produces for several languages
>>>are so immensely useful.
>>
>> I second that. ?There's a very useful level of conceptual granularity
>> that's "coarser" than that of "idiom", but still neither concretely
>> specific to an application domain nor quite as abstract as "software
>> pattern". ?Cookbooks cover that ground. ?This book might be an easy
>> one, since it's already mostly written, just scattered around in other
>> work.
>
>I'd love to see a software architecture "patterns" book that uses OTP
>- as much as possible anyway - as the illustration/implementation
>layer. This would not be a "functional patterns" (in contract to OO),
>but rather these elements:
>
>- Concurrency with message passing
>- Process definition/scoping (e.g. server behaviors)
>- Supervision and fault tolerance
>- System composition and management in OTP (i.e. applications and releases)
>
>This is the stuff one needs to thoroughly understand to build a
>non-trivial system in Erlang. I've found it challenging to piece this
>information together with the available online resources, lists,
>books, etc.
>
>I'm not a huge UML guy, but UML does provide a basic vocabulary for
>thinking about and communicating various aspects of a software system.
>I probably ever only use < 5% of the stuff, but even with that, it's
>very helpful to used a shared modeling language. A patterns book like
>this would codify a simple notation for modeling/describing Erlang/OTP
>systems, which would be a big benefit, IMO.
>
>The payoff for such a book is that it'd highlight how and why
>Erlang/OTP is well suited for highly concurrent, fault tolerant
>systems. The case studies show that anecdotally, but a good patterns
>book would provide the all important sign posts to help developers
>realize the goodness.
>
>Garrett
>
>________________________________________________________________
>erlang-questions (at) erlang.org mailing list.
>See http://www.erlang.org/faq.html
>To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>