

Erlang for Skeptics - mace
http://erlangforsceptics.com/book/

======
lukevenediger
Hi Guys,

My name is Luke Venediger, I'm the author of Erlang for Skeptics. Thanks for
visiting my book and for the comments. It's very much a work in progress and
has a long way to go, but I'm excited about getting the community involved
early on. I'm working on a public feedback mechanism, but for now please post
feedback below this comment.

I've been using Google Wave to build the plot and outline, together with my
friends TheColonial (<http://buffered.io/>) and StackingIt
(<http://www.blog.stackingit.com/>). Wave rocks as a real-time review system,
and has definitely improved the quality of my book.

I'll have a more substantial website up in the next week or so that will have
a comments section and an RSS feed for updates. In the mean time you can
follow @erlangforskeptics or myself @lukevenediger on twitter.

Thanks again, Luke Venediger

------
zephjc
I only have some familiarity with Erlang, Does anyone know the rational behind
not being able to change a variable's value? Is it simply historical?

It seems you have to call f() to 'forget' a variable before assigning a new
value to it - what a maddening name for a built-in function ;-)

~~~
tmountain
The rationale behind immutable (a.k.a. unchangeable) variables is rooted in
Erlang being designed as a concurrent functional programming language from the
bottom up. Whenever you have multiple operations manipulating a single value,
you're immediately responsible for synchronizing access to that value and
ensuring it always exists in a consistent state.

Rather than deal with the complexities of synchronization, some languages opt
to make all their data immutable and encourage the programmer to write code in
a functional style. The fact that the f() function seems unintuitive is
because that's not how code is written in Erlang. f() is merely a convenience
function for unbinding a value from the Erlang shell, and it is not used in
the real world. Rather, you setup initial bindings and then use recursive
functions to yield new values as needed.

This requires a shift in your thinking about programming, but it offers huge
advantages when working within a concurrent model. For more info on the
dangers of mutable state in concurrent systems, I suggest the following
article:

<http://www.artima.com/articles/hickey_on_time.html>

~~~
KevinMS
I've done some programming in Erlang and I found the immutable variables to be
a total pain in the ass that gave no benefit. Your code ends up littered with
var=1 var2=var+1 type idioms.

Also, the immutable variable have nothing to do with concurrency. Since
threads cant touch each others data, and they can only talk to each other
through messages, immutability only applies to a local scope, where its really
no big deal.

Last time I checked somebody was making a scripting language built on top of
the erlang runtime and he says that immutable variables are nonsense.

~~~
iamaleksey
If your code ends up littered with Var2 = Var1 + 1 type "idioms", then you are
probably doing it wrong. I hardly ever write code like that (or see other's
Erlang code like that). It's by no means an idiom.

~~~
KevinMS
From programming erlang by Joe Armstrong:

At this point you might be wondering how it’s possible to program with- out
variables. How can you express something like X = X + 1 in Erlang? The answer
is easy. Invent a new variable whose name hasn’t been used before (say X1),
and write X1 = X + 1.

    
    
      X=#todo{}.
      X1 = #todo{status=urgent, text="Fix errata in book"}.
      X2 = X1#todo{status=done}.
    

From Armstrongs thesis

    
    
      X = 5; X1 = X + 10;
    

I found those just by searching on "X1". There are more X1 examples in the
erlang otp sources. Who knows what else is in there.

~~~
iamaleksey
I'm not saying this _never_ happens.

It does, but you'll _rarely_ see this pattern in any real Erlang code base.
And when you see it, it will not be "littered". It's an exception, not an
idiom.

And those samples from Joe's book and thesis are just snippets with no
context. BTW, O'Reilly's "Erlang Programming" doesn't even provide such an
example.

Edit: One example when I _do_ use this pattern is constructing proplists for
some function calls.

~~~
silentbicycle
Erlang's style was _very_ strongly influenced by Prolog, and in Prolog code,
it's quite common to see e.g. "X1 = X + 1", but having X2, X3, etc. as well is
rare - there's usually not a succession of modified versions of a variable in
the same function (clause), because it's a sign that you could break things up
better. The same is true in Erlang - code with several such variables is
written with a strong Java accent (or whatever), not in idiomatic Erlang.

------
vorobei
You forgot to include Vim in the "Erlang Editors and IDEs" section.

------
knv
Why code listings are empty?

~~~
silentbicycle
It looks like a work-in-progress.

~~~
sketerpot
You've got to love the economy of words that the introduction displays. It's
only one sentence: "The introduction."

(That's a good way to do things. Write some meat first, _then_ you'll know
exactly what you've got to introduce.)

~~~
lukevenediger
In my first (now trashed) version of the book I had started writing an
introduction, but it got long-winded and verbose because I didn't know what I
was introducing! Better to add the introduction in at the end, as you've
mentioned :)

------
gcb
Cant see images on opera mobile or teashark.

