[erlang-questions] Erlang for youngsters

[Torben Hoffmann]

Fred Hebert writes:

> 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. 
>
The more the merrier! ;-)

> 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.
>
Good points.

As we wander here in the darkness of the valley of Erlang teaching, it might be wise
to take a more Lean Start-up like approach to solving the problem, i.e., build it
incrementally and measure what works.

I wonder if anyone has approached the creation of learning experiences this way?!?! 
>
>>     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 think that is the first thing to put into the learning - and focus on a working
process for figuring out what the right amount of processes. As Robert Virding often
says, we tend to make too few processes in our designs, so teaching people that they
are cheap is probably the way to go.
> 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.
>
+1 on that. Very few resources on how to really design with functions and perhaps
even fewer on how to do concurrency, especially the Erlang style.
>> 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!
>
Yup, not ashamed of that!

> 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.
Horses for courses!

They make use of DrRacket, which has the upside that it can produce geometric figures
quite easily, while still mixing in traditional operations on numbers and Booleans.

Would be cool to do this with Erlang/Elixir and processing.org.
>
> 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.
>
True. Again, an iterative approach seems favourable from a risk standpoint. 
>> 
>> 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 could definitely do Logo and Racket with Elixir by using a port.

The Scratch approach is a different challenge. Until today the only graphical
notation that has come close Erlang for me has been SDL, but a search revealed this:
http://drakon-editor.sourceforge.net/drakon-erlang/intro.html

It looks a lot like SDL, but it should be Turing-complete, so this might provide a
visual way into the world of Erlang. 

> 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.
>
I think the Erlang programming model can be used for many things, so I think it is
bestowed upon us to show that is is applicable to what they 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.
>
Mix has taken one very sane decision: the configuration is written in Elixir!

If make is not enough for a build problem the only sane thing is to step up the
latter, i.e., go to a real programming language. Inventing a DSL (the rebar approach)
is a step in the wrong direction.

If Mix works for youngsters depends on how much command line they can accept.
If they need the visual environment, Mix is not a good thing.

> 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.
>
Good observations. Not sure how they relate to teaching.
Elixir's library takes a stab at more consistency, so that is probably better for
beginners. 

> Anyway, that's a long rant enough.
>
A good rant if you ask me!

Cheers,
Torben

> Regards,
> Fred.


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