Language Bindings for Erlang Again (Opinion)

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: Andrew Lentvorski [mailto:bsder@REDACTED] 
> Sent: den 9 juni 2006 03:12
> To: Joe Armstrong (AL/EAB)
> Cc: Gerd Flaig; erlang-questions@REDACTED
> 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>>
> 
> Ayup.
> 
> > 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.
> etc.
> 
> 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".

Example:

	- It was so obvious to me that "you need at least two computers
to make
	  a fault tolerant system"

	  That I never mentioned it.

	When I did start mentioning it the response was amazing (to me
at least)
	- many people had never really thought
	about this so they just assumed that somehow you could make
fault-tolerant systems
	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
	self-evident"

      Now if you think about distribution you will rapidly
      realise that shared data structures and dangling pointers become
very
	messy *when things start failing* so you'd better avoid them. <<
this
      realisation was incidentally the *start point* for Erlang, this
was about 20 years ago.
      By 1989 Robert Virding, Mike William were convinced that
fault-tolerance implied
      distribution, concurrency and no sharing. We argued this point at
a conference
	in Bournemouth, we kept going on and on and on and on about
making
	things work in the presence of failures - nobody else seemed
interested,
      many people *still* don't get it>>

      ... and once you don't have shared things you can parallelise them
on
	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
atc.
	is so difficult.

> -a
>