Language Bindings for Erlang Again (Opinion)
Joe Armstrong (AL/EAB)
Mon Jun 12 11:45:56 CEST 2006
> -----Original Message-----
> From: Andrew Lentvorski [mailto:]
> Sent: den 9 juni 2006 03:12
> To: Joe Armstrong (AL/EAB)
> Cc: Gerd Flaig;
> Subject: Re: Language Bindings for Erlang Again (Opinion)
.. cut ..
> What does "not computer scientists" mean? What are the
> likely qualifications of a "regular" Ericsson programmer?
Not computer scientist means "not having a degree in computer science"
The most likely qualifications would have been 5-10 years
"on the job" experience.
> I find it unlikely that these programmers would qualify as
> average on any measure. I find it more likely that these
> programmers qualify closer to "excellent" than "good".
I disagree - very few programmers qualify as excellent -
They guys I taught were average almost be definition -
Ericsson is a huge (for Swedish standards) employer
of programmers - it almost *defines* average by virtue of
the fact that employs vast numbers of programmers.
> That, at least, has been my experience with programmers who
> can do protocol stacks and heavy hardware programming.
But a system has far more to it than stacks and drivers
> > In most cases I observed that "a good programmer in X" will
> become "a
> > good programmer in Y"
> > (for all X and Y) this appears to be universally true.
> No argument.
> > with dynamic hash tables - the only problem in switching
> languages is
> > learning the libraries>>
> > Our pupils had two minor problems.
> > - recursion, and
> > - write once variables
> > - processes
> > Now recursion was only a problem IF YOU USED THE WORD
> RECURSION - it
> > seemed like somewhere lurking at the back of their brains
> was the idea
> > that "recursion is difficult"
> > and the word "recursion" triggered an immune response - we
> tried never
> > to mention it.
> I'll keep that in mind about recursion. That's probably good
> advice no matter what the functional language is.
> You left out "pattern matching"--I find this to be a more
> fundamental problem. This tells me that your groups have
> selection bias. Folks working on protocol stacks understand
> finite state automata inside and out. "Average" programmers
> have no such background.
I've never met anybody who didn't understand pattern matching.
The only case that needs some explanation is
that X = X + 1
will always fail :-)
> This is a problem even when teaching languages like Java and
> trying to explain regular expressions.
But Erlang patterns and *far simpler* than regexps
> > Now I could write several pages here, since I wrote a lot of the
> > documentation I would find it rather helpful to know which part
> > "sucks" - please send me a list of errata or tell me exactly which
> > parts of the documentation you are having problems with.
> How, when and why to use gen_server should be in the documentation.
> How, when and why to use gen_fsm should be in the documentation.
> These aren't easy questions. They take lots of writing.
> They take motivating examples. I'm well aware that coming up
> with such docs is a pain in the butt (I wrote much of the
> tutorials on FFI calls in OpenMCL).
> However, they are really useful to those new people coming
> into the language for the first time.
Yup - the problem is that is extremely difficult to see the
world through other people's eyes. A couple of days ago
I played with Ruby on Rails - I hadn't the faintest idea
what all these funny file extensions (.rb, .yml, .rhtml) meant
- I guess I should try to remember this experience when writing Erlang
tutorials - and tell people what .beam, .erl, .yrl, .htr files are
unfortunately it's very difficult to remember to do this - since
*everybody knows this*
It takes years of explaining things before you realise that
people just don't know what you think is "obvious".
- It was so obvious to me that "you need at least two computers
a fault tolerant system"
That I never mentioned it.
When I did start mentioning it the response was amazing (to me
- many people had never really thought
about this so they just assumed that somehow you could make
with one computer. Then I'd ask "what happens if it crashes?"
Then I'd point out that "two computers = distributed
programming, concurrent etc."
So a consequence of "fault-tolerance" IS distribution and
concurrency (this is less
obvious - though after 20 years of working with this is seems to
me to be
Now if you think about distribution you will rapidly
realise that shared data structures and dangling pointers become
messy *when things start failing* so you'd better avoid them. <<
realisation was incidentally the *start point* for Erlang, this
was about 20 years ago.
By 1989 Robert Virding, Mike William were convinced that
distribution, concurrency and no sharing. We argued this point at
in Bournemouth, we kept going on and on and on and on about
things work in the presence of failures - nobody else seemed
many people *still* don't get it>>
... and once you don't have shared things you can parallelise them
a multi-core CPU ...
Now all of these are pretty "self-evident" - once you have seen
the light -
but it *is* very difficult (once you have seen the light) to
recall what it was
like before you had seen the light - which is why writing books
is so difficult.
More information about the erlang-questions