In article <>,
(Peter-Henry Mander) writes:
<Snip>
|> I have also found that Erlang scares people, in my case experienced C++
|> programmers, because they're stripped of all acquired knowledge and
|> tools; they must start to re-learn from scratch something they've grown
|> confident and capable in. It's _not_ like switching from C++ to Java,
<Snip>
Many years ago (:-) I held a lot of basic Erlang courses. Many people had trouble
with atoms, single assignment, scope of variables, recursion etc, but maybe as
many as one student in ten never grasped the idea of processes and concurrency.
It was as if they had some wierd mental block and I could do very little to
help them. It is a bit like riding a bicycle or learning to swim. Once you know
how to do it, it's very hard to comprehend that one once found it difficult.
Many people first experience concurrency in an extremely hard context, e.g. UNIX
sockets or pthreads. When you already have a concept which people initially find
it hard to grasp, obfuscating it with a bewildering barrage of system calls
(socket, bind, listen, accept, select etc) with obscure semantics rapidly turns
it into an area where people just use "cookbook" solutions to avoid having to
grasp the details of how it all hangs together (if is does so at all).
So it's not altogether suprising that Erlang wins ground only slowly. Not only
are people subjected to the monster of concurrency, they also have to contend
with a functional language at the same time. But once one has understood it, its
hard to see how anyone can tolerate the mind boggling difficulties of trying to
do concurrent programming in C++ combined with a wierd OS or middleware.
/mike