[erlang-questions] Erlang for youngsters

[Torben Hoffmann]

J David Eisenberg writes:

> On Mon, Jun 16, 2014 at 6:26 PM,  <erlang-questions-request@REDACTED> wrote:
<snip>

>> 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
>
The graphics toolkit does not have to be in Erlang - as long as we can control it
from Erlang then it is fine.

> 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
> JavaScript or Python (i.e., Raspberry Pi programmers). One advantage
> 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
> temptation."
>
Tricky - familiarity can work both ways.

As I think more deeply about it, the traits of Erlang that really matter are
concurrency and pattern matching - not the full functional programming paradigm.

We can talk about reassignment as being Evil™, but since it is only for variables the
damage is constrained. From the imperative bag of evilness I find that shared
variables and objects are way more polluting for the mind.

Erlang and Elixir structure programs around two things: modules and processes.
The processes hold some state and it is easy to protect that state with a good API.
Modules can abstract out the inner details of data structures and since functions
do not have shared data it is easy to understand what is going on.

Syntax does not make a language imperative.

> 3) Existing materials for other languages: I'm very impressed by
> http://www.bootstrapworld.org/
>
I think that the style and theme of BootstrapWorld is spot on - lots to steal there! 

> 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.
I have hinted at this before: I think there is an underlying programming style
in Erlang which is more about concurrency and fail-fast that has a lot of mileage.
That and the functional aspects can solve a lot of problems in an elegant manner.

That's where I think the focus should be.

Cheers,
Torben
-- 
Torben Hoffmann
CTO
Erlang Solutions Ltd.
Tel: +45 25 14 05 38
http://www.erlang-solutions.com