Language Bindings for Erlang Again (Opinion)

[Joe Armstrong (AL/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of 
> Andrew Lentvorski
> Sent: den 8 juni 2006 04:58
> To: Gerd Flaig
> Cc: erlang-questions@REDACTED
> Subject: Re: Language Bindings for Erlang Again (Opinion)
> 
> Gerd Flaig wrote:
> > as often as I hear that argument, I still don't understand 
> it. Anyone 
> > you would want to hire for software development can pick up 
> Erlang in 
> > a few days and OTP in four to eight weeks.
> 
> I disagree.
> 
> 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? 

What evidence do you have to support this figure?

Let me give you some facts here:

I have taught a large number of Erlang classes, I never kept any
records so I don't know exactly how many. These were four days
hand's on classes - with about 8 pupils/class. These were internal
Ericsson classes, in all about 400 programmers attended the courses, 
which makes about 50 classes.

Initially Robert Virding, Mike Williams and I held most of the courses,
later we got so fed up giving the courses that we persuaded other people
to take over the courses - the first ten times was fun, then it got to
be a drag.

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 was our experience of this? - almost without exception our pupils
had very few
problems converting to Erlang. I can only remember one case of a skilled
C programmer
who just didn't "get it" - he really didn't understand - and I could not
understand
what he didn't understand.

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.

<< I program in lots of languages, but in a sense they are "all the
same", or to be more
precise fall into one of a small number of categories, for example,
imperative, functional,
relational ... when you know one you know them all. I've recently
programmed a lot of
JavaScript (great fun) - after a brief tussle it just feels like any
other imperative language
with dynamic hash tables - the only problem in switching languages is
learning the libraries>> 

Back to teaching Erlang.

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.

The weird thing is that you learn recursion in school (at least I did)
but it was never
called that, I learnt that:

	sin(2X) = 2 sin(X) cos(A)

<< Wow they're taught me Erlang in school

	sin(X) -> 2 * sin(X/2)* cos(X/2)
>>
 

As for the write once variables - hey you can't say "X = X + 1"
you have to say X1 = X +1 in Erlang. Was this a problem? - not really

I remember when I first learnt Fortran, the teacher got to X = X + 1
and the class was highly upset "You can't do that", we all protested.

My old mathematics teacher would have been appalled - we had learnt in
school
that X can never be equal to X+1, so we had to "suspend our disbelief"
and
leant that now = dose not mean equals but something completely
different.

So what does it mean in Erlang - answer pattern matching.

Now processes - these were a problem. The pupils understood processes -
but they didn't use them enough. Even today this is probably the biggest
mistake people make - not using enough processes - why? probably because
using processes is made very difficult in languages like C - so
difficult
that many C programmers have *never* created a process.

> OTP cannot be picked up in 4 to 8 weeks because its 
> documentation sucks.

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.

If you do not understand the documentation then there are plenty of
people on
this list who can help you.

IHMO the *amazing* thing is the large number of people who have
understood the documentation
and built pretty impressive system *without ever asking any questions on
this list*

These are the people who's first question to this list is something like
"I have set up
a 20 machine cluster, and a fragmented mnesia table, and when two of the
machine crash
I need to ..." - and you wonder - how the heck did they get that far
*without* asking any 
questions - well done guys - at least *somebody* must have read the
manual. 

> 
> Why do I use OTP?  When do I use OTP?  When do I *not* use OTP?
> 
> A reference manual like we currently have is merely a first step. 
> Something on the list like "Guru of the Week" was for C++ 
> would be useful and wouldn't require the publication of a book.
> 

What would you like - what I am planning is an interactive version
of *all* the documentation - ie every document becomes a "forum"
where you can interact with the documents.

The idea is that you should be able to "ask a paragraph a question" - so
if you read
something that you don't understand or which "sucks" then you can click
on it and
"post a question to the paragraph" - this will get back to the person
who
wrote the text, moreover anybody else who is reading the document will
be able to
answer the question at this point. 

<<this will be part of Erlang on steroids --
aside: why is Erlang on steroids behind schedule? - answer because when
it is launched
it will come with thousands of pages of interactive documentation, I am
currently
converting all the Erlang documentation to a new format, which has to be
*beautiful*
and not loose information, when transforming from the old SGML base >>

> >> I'd like to see some good books on "modern erlang/otp"
> >> for example. 
> > 
> > Yes, something like Practical Common Lisp, only for Erlang.
> 
> Ayup.  That would be nice.

Books are in the pipeline

/Joe

> 
> -a
>