[erlang-questions] What about making sense?
Fri Feb 19 09:30:16 CET 2010
I think we have a lot of cross-talk going on here.
Item: Some people believe that the Erlang docs as they are interfere with
comprehension, partially because of inconsistent and unusual use of
Item: Some people see no problem with the docs as they are.
The truth lies somewhere in the middle, I believe.
The docs are nowhere near as dire as some of the more vociferous
commentators are portraying them. Are they ideal? No. Are they even good?
Not really. They are about average for this industry (which is a
condemnation of the industry's standards, not of the writers). They are,
however, adequate. *As references*. If you already know what it is you're
looking for (or should be looking for) the docs as they stand are more than
What they are terrible for is learning tools. This is a problem in general
for Erlang, partially because it's a relatively new tool on the scene (the
public scene, that is -- I know it's been around for ages inside Ericcson)
and partially because it's a small community around it with only a very
small number of grognards who know it all.
On the learning front now we have two great tools (*Programming Erlang* and
*Erlang Programming*) with a third on the way (*Erlang and OTP in Action*)
for tutorial introductions. These first two have been great for my picking
up Erlang, for example, but now another barrier has crossed my path.
There's no documentation in between the "Erlang for Complete Newbs" stuff
and the "Reminders for the Grognards" stuff.
I think that is the failing of Erlang documentation at this point. It's not
in tutorial-level information -- there's plenty of that and of very high
quality indeed (courtesy of Armstrong and Cesarini & Thompson). There's
more of it on the way. It's not in the reference-level information. What's
there isn't ideal nor is it ideally organized but it's OK. Better than some
languages, worse than others. What's missing is information like overviews
of the available libraries (or "applications" in Erlang-speak), what they do
and a general idea of how to use them. What's missing is good sample code
for these "applications". Use case scenarios. Where they are well-applied.
Where they are not so well applied. There is a great deal of stuff in the
Erlang/OTP distribution. Here's a list of it:
That is a pretty intimidating list for a newcomer to be faced with and there
really isn't a good overview of what each is, where each might be applicable
and how they interact with each other. (No, a list on the left pane doesn't
qualify as guidance!) Grognards who have been working with Erlang since
forever, I think, are forgetting that newcomers to Erlang are faced with a
lot of hurdles all at once. Newcomers are often faced with their first
functional language. They're faced with their first actor-based concurrency
model. They're faced with an unfamiliar syntax that even old-timers have to
admit can be opaque and a bit strange. They're faced with libraries--Oops!
"Applications"!-- that don't play well together (edoc vs. typer vs.
dialyzer for example). They're faced with all of this and get little to no
guidance short of community legend and lore to navigate through it.
I can see how this can be frustrating and how it can lead to the increasing
levels of heat showing up in this thread. Unfortunately the heat is now
doing nothing but getting people on each side riled up, feeling embattled
and digging in as a result. I'd like to ask for two things to help calm
1. Grognards, please try and understand the position of a complete
newcomer. Imagine, for a moment, that you haven't been working with Erlang
for years. Look at the documentation that exists as if it were your first
time. Look at that list of "applications", the unusual terminology, the
language that is pretty much unlike anything else out there in common use
and ask (and answer) yourself honestly: is this sufficient for learning? Is
this helpful to a newcomer to the language? If, as I expect, you answer
"no" to these questions, ask yourself also what needs to change to make
these helpful and sufficient and, more importantly, what processes can be
put in place to speed along development of such tools by bringing in
2. Newbies (like me), please also try to understand the position the
grognards are in. Like you they are hired to be (or have made businesses to
be) productive with code. They're developers and not technical writers.
Further the fruits of their labour are being given you at no (fiscal) cost.
It is a bit unseemly to harshly criticize their (from their employers'
perspective) non-productive labour when they, too, face the real world of
software development with unrealistic schedules and deadlines, moving
requirements and feature creep. Be thankful for what is there already and
perhaps have a little patience as the rest gets released and the processes
get ironed out to have community input.
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
More information about the erlang-questions