[erlang-questions] Erlang for youngsters

[Fred Hebert]

There's a lot to discuss in this thread (and Joe's one last week). This
is a bit of a rambling from me, but yeah. 

On 06/16, Torben Hoffmann wrote:
> Why is Erlang HardToLearn?
> 

We should ask newcomers. When I started, Erlang was hard to learn for
specific reasons: terminology, availability of information (we had the
series of blog posts about an Erlang bank in OTP and the trapexit
cookbooks, and that was most of it if you didn't feel like paying for a
book)

Since I've learned the language, the context changed in massive ways.
LYSE is available, Cowboy has gained docs, Chicagoboss has a manual,
more books have come around, more tutorials have been published, more
talks have been made available.

The problem isn't solved, but as a community, we shifted it to a new
different area. Newcomers will have had the difficult pressure point
somewhere else, and newcomers should therefore be able to tell us what
*they* found hard, without having more experienced people contradicting
them on many points -- We learned at a different time in a different
context.

We should ask people who have quit learning the language. Sometimes we
will disagree, sometimes it will be due to their background of areas of
interest, but there is a lot to for us to learn there.

We should ask people who don't feel like learning it. We have pieces of
data, such as people not liking the documentation, but we don't know
*why* that is. Fixing the doc without fixing what's wrong is a bad idea,
the same way premature optimization is.


>     how to think like an Erlanger.
> 
> 
> I think that a learning resource focused on teaching people the Erlang model from the
> ground up would be a great improvement. A clear narrative around how do we solve a
> problem the Erlang way. Teaching the basic constructs is not the problem.
> 

Architecture is a definitive place where that needs to happen. I
remember fumbling around wondering "but what do I make a process?" --
not sure if it's still an issue.

I remember (and still often encounter) the issue of algorithms and
datastructure. Everything you've learned before tends to assume O(1)
access to mutable memory and it's no longer true. But then again, the
relevance of this depends who you want to teach to. People who already
program, or people who don't program yet.

> My initial target for such a learning resources would be young people in the higher
> grades of elementary school, say 12-15 years. Why? Because I want to influence them
> before their minds are totally corrupted by other programming models.
> 

Ah, so you want to be the first one to corrupt their minds, then!

Snark aside, if we want to teach children, we should reach out to
organisms such as https://www.codeclub.org.uk/ (who do this *every
day*). We should look at what it is they do, ask them, see what they
recommend, and tell us what wouldn't work.

We can also look at How To Design Programs
(http://www.ccs.neu.edu/home/matthias/HtDP2e/), a book and site designed
to teach programming to new people. They show you how to animate rocket
ships in the first chapter. Erlang books (mine included) tell you what
an atom is and why you should care. That's okay, they're not meant for
newcomers.

Or we can try reinventing the wheel based on what we feel is really
important, but what we feel is really important likely doesn't overlap
super well to what is important to a teenager. There are people who
dedicate their lives to working on that problem, they're the ones from
whom we should be looking for for guidance.

Many of us know Erlang, but few of us know how to teach. A lot of us
have forgotten what it is like to not know how to program.

> 
> What is better about Elixir from a learning standpoint is, in my highly subjective
> opinion, that you can get started quite easily with the mix tool.
> 

If we want to reach out to crowds who aren't familiar with programming
at all, mix isn't gonna cut it either. Look at Scratch
(http://scratch.mit.edu/), look at Logo, look at Racket's graphical
language (http://docs.racket-lang.org/teachpack/2htdpimage-guide.html),
look at Arduino's documentation
(http://arduino.cc/en/Tutorial/HomePage). You've mentioned elm, which
looks like it has another great intro.

We have a long way to go, whether Elixir or Erlang is being used. Most
people still put Erlang's sweet spot into the 'server' area in Garrett's
data. Do we have to make the person we're gonna teach to care about
servers to have teaching Erlang worth their time? Because it looks like
otherwise, we might as well teach them a language more adapted to what
they care about, not one adapted to what we care about.

If we plan on reaching out to the already-programmign crowd, then yes, a
tool like Mix is useful. It would also be useful within Erlang for its
community. Rebar templates aren't even that far from allowing a lot of
that functionality, but the community hasn't banded together to do it.

There are probably deep-rooted reasons for it -- many of us adopted
Erlang when you managed dependencies by downloading them and checking
them in your repo, used makefiles all the time, and whatnot. The stuff
rebar or erlang.mk do is already convenient enough for a lot of us to
have felt the pain eased away, at least to the extent where we're not
compelled to help fix the problem anymore. The workarounds are nicer
than what we had before, so workarounds it will be. Forever.

The same is true for the documentation. They're mostly reference manuals,
which by definition are to be used as a reference -- it is expected you
know their content and are only looking up additional information, or
data to help you recall what you already learned. They won't be good to
learn (the tutorials are nicer, but who knows about them?), and none of
the regulars will have any incentive to fix it.

Anyway, that's a long rant enough.

Regards,
Fred.