[erlang-questions] Erlang for youngsters
J David Eisenberg
Tue Jun 17 06:57:19 CEST 2014
On Mon, Jun 16, 2014 at 6:26 PM, <erlang-questions-request@REDACTED> wrote:
> Send erlang-questions mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of erlang-questions digest..."
> Today's Topics:
> Date: Mon, 16 Jun 2014 20:58:20 +0200
> From: Torben Hoffmann <torben.hoffmann@REDACTED>
> To: Lo?c Hoguin <essen@REDACTED>
> Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] Erlang for youngsters
> Message-ID: <m1zjhc3cmr.fsf@REDACTED>
> Content-Type: text/plain; charset=utf-8
> Lo?c Hoguin writes:
>> I don't think the problem is so much that these things are hard to
>> learn, but rather that you *have* to learn them. OO was hard to learn.
>> Pointers took me a while also. In comparison Erlang was very fast to get
>> started with as I started writing parsers for binary files immediately,
>> then later on making it parallel and eventually learnt OTP and did other
>> small things with the language.
>> At the time there was basically no resources. LYSE had about 5 chapters
>> so I didn't really use it. A few blog posts here and there helped a
>> little, but it was mostly Joe's book. Today we have tons of resources. I
>> do not think the docs problem shown by Garrett is the reason why Erlang
>> is hard to learn. I think it's just correlation. (Of course some of the
>> OTP docs are terrible, like sofs and bits of the common_test guide, but
>> the docs on erlang.org are impressive; only they do not help the Erlang
>> beginner, this is covered by Joe's book, LYSE and others.) If there is
>> causation then a link to the free version of LYSE from the erlang.org
>> docs page should be plenty enough to fix it.
>> What I think is that people say Erlang is hard to learn because they
>> expect to go from 0 knowledge to be able to use it for their job in a
>> few hours. This is plain crazy, nobody learnt OO in a day, and nobody
>> can learn concurrent/fault tolerant in a day. And it's even harder if
>> your mind is stuck on a particular paradigm.
> I think this is remarkably well put. It sort of hints the head on the nail for me.
> Respect for the learning curve. I too see a tendency of this from time to time.
This is true, but you want to provide beginners with a "success
experience" quickly, with the explicit statement that it *is* just a
beginning step. ("Don't try this at work!")
> Thanks for articulating that, Lo?c!
>> Learning takes time. In today's impatient world this is seen as a
>> weakness, but those who do take the time to learn Erlang get an
>> exponential reward for their troubles. This is unfortunately hard to
>> demonstrate to people who want everything immediately without the effort.
>> But to kids who have never done programming before? They'll learn Erlang
>> as easily as anything else. When you first start programming even "hello
>> world" is a magical moment. When you've programmed for years it's a very
>> boring moment and you want to skip ahead, which is impossible if you
>> have to learn a new paradigm entirely. Kids do not have that problem. So
>> stop worrying and teach them Erlang.
I tell my programming students: "You can either pay now or pay later;
pay later is almost always more expensive." That is, the time spent
in planning (pay now) is a much better use of your time than randomly
thrashing about trying things until you get something that seems to
work--until it doesn't, and you have to fix it (pay later). Or, more
cynically: "hours of programming can save you minutes of planning."
Erlang especially seems to be a language where "pay now" is far less
expensive. With functional programming in particular, programs written
at the keyboard look like it, and that is not a compliment. (A REPL is
great for testing hypothesis and small snippets, but certainly not for
composing an entire program.)
> A kinderd spirit.
> So this boils down to motivation to sustain through the learning curve and pureness
> of the fresh minds to avoid having to unlearn other paradigms.
Other thoughts about this:
1) Graphics: An absolute necessity. "Hey, kids, let's output Fibonacci
numbers!" falls flat. "Hey, kids, let's draw this cool spiral (which
happens to use Fibonacci numbers)!" is much more appealing. As for
Erlang and graphics, there's Wings 3D, and I'm not sure how easy that
is to get into
2) Elixir vs. Erlang: I'm going to vote for Erlang here. I like
Elixir, and I like its libraries that make general-purpose programming
easier. However, it *looks* like an imperative language, and that will
cause interference for those beginners who may have done some
of Erlang (or LFE or Clojure) is that it doesn't look anything like a
typical imperative language, so I'm not tempted to think in imperative
terms. Erlang's single assignment vs. Elixir's ability to rebind a
variable is another way that Erlang will "lead me not into
3) Existing materials for other languages: I'm very impressed by
4) What do you really want to teach/Erlang's problem space. Erlang is
designed for solving problems of "fault-tolerant, concurrent,
distributed programming" -- are you teaching Erlang for those
properties, in which case you need to map them into the problem space
that young programmers might be interested in, or are you teaching it
as a general functional programming language? That's not the same as a
general-purpose programming language, of course.
>> On 06/16/2014 12:20 PM, Anthony Ramine wrote:
>>> Did anyone ever wonder whether Erlang is truly hard to learn, or if it is just how fault-tolerant, concurrent, distributed programming is by definition?
> Torben Hoffmann
> Erlang Solutions Ltd.
> Tel: +45 25 14 05 38
More information about the erlang-questions