[erlang-questions] Erlang and the learning curve

[Attila Rajmund Nohl]

2011/1/4, Robert Raschke <rtrlists@REDACTED>:
[...]
> You usually do not have nice high-level data structures, pattern matching
> and functions as first-class citizens. This leads to loads of code for
> unpacking/accessing, checking and repacking of data.

Unpacking/accessing is complicated in every language, if the data
structure is deep enough. Pattern matching helps here, but you can't
do pattern matching on e.g. a dict object, have to use wrapper
functions - just like you'd do in Java too. Not to mention that the
pattern matching on record fields is seriously confusing at the first
(thousand) glance.

[...]
> My point is that while it is probably possible to write a similarly poorly
> structured piece of code in a functional language, it would be much much
> harder to do. This is because you do not have the luxury of simply stashing
> some random value in the "global" space (I count inheritance as part of
> global!) because you're going to need it in a completely different part of
> your code later on.

In my experience it's the contrary. A call of a method of a class in
e.g. Java is a single piece of code, but in Erlang the classes are
usually mapped to gen_servers and usually there are three functions
for every method:
 - an interface method: exported, executing in the calling process,
usually only doing a gen_server:call
- a handle_call clause usually only calling an implementation function
- and the actual implementing function, executing in the gen_server process.

These functions are usually in the same file, so when I'm looking at
the code, I have to keep in mind that which function is executing in
which process, to know that which values can be available from the
state.