Language Bindings for Erlang Again (Opinion)

[Andrew Lentvorski]

Joe Armstrong (AL/EAB) wrote:

>> The complete rearrangement to functional programming and 
>> message passing
>>   does not come easily for 99% of software developers.  Now, 
>> we can argue whether you should hire people like that, but if 
>> you ignore 99% of all developers, your language is unlikely 
>> to become very widespread.
> 
> What are you basing this number of 99.9% on?

Having lectured about different functional programming languages to 
audiences which were more oriented toward what I consider to be 
"average" programmers.

> The people attending our courses were regular Ericsson programmers - not
> computer scientists, most of them programmed in Plex (an Ericsson
> internal language)
> and C. Very few had a computer science background and only a few had
> every tried
> "esoteric languages" like lisp or Prolog.

What does "not computer scientists" mean?  What are the likely 
qualifications of a "regular" Ericsson programmer?

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".

That, at least, has been my experience with programmers who can do 
protocol stacks and heavy hardware programming.

> 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.

This is a problem even when teaching languages like Java and trying to 
explain regular expressions.

> 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.

-a