Language Bindings for Erlang Again (Opinion)
Joe Armstrong (AL/EAB)
Thu Jun 8 09:41:58 CEST 2006
> -----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
and C. Very few had a computer science background and only a few had
"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
who just didn't "get it" - he really didn't understand - and I could not
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,
relational ... when you know one you know them all. I've recently
programmed a lot of
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
Now recursion was only a problem IF YOU USED THE WORD RECURSION - it
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
that X can never be equal to X+1, so we had to "suspend our disbelief"
leant that now = dose not mean equals but something completely
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
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
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
If you do not understand the documentation then there are plenty of
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
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
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
> 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
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
converting all the Erlang documentation to a new format, which has to be
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
More information about the erlang-questions