[erlang-questions] Erlang for youngsters

Torben Hoffmann torben.hoffmann@REDACTED
Mon Jun 16 12:20:45 CEST 2014


Garrett Smith writes:

> On Mon, Jun 16, 2014 at 9:51 AM, Torben Hoffmann
> <torben.hoffmann@REDACTED> wrote:
>
> -snip-
>
>> 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.
>>
>> 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.
>>
>> I don't think we would have to dumb anything down in particular for this group - we
>> just have to find a cool example and organise the learning around how to become so
>> good that one can solve such a problem.
>> Some sort of game will probably be the best candidate, say, some sort of Transport
>> Tycoon clone?!?!
>
> I don't have enough experience teaching programming to this age group
> to provide anything more than a hunch. But I suspect that the Erlang
> way, which is hard enough for very seasoned programmers to grok, might
> be a bit ambitious for these young learners.
>
> I'm speaking in particular about the model that emerges when you
> isolate processes. It changes everything: your approach to building
> software (move from state oriented to activity oriented), error
> handling (move from defensive measures to assertive/let-it-crash),
> program structure (from monolith to system), and so on. The benefits
> of this shift are hard to get across, in my experience anyway. I wish
> it wasn't, or I wish I was better at communicating.
>
Interesting.

I have no data or experiments to back this yet, but I think that if you have not been
exposed to the "traditional" way of programming you will have a easier time learning
a concurrent, functional programming model.

Some people insist on telling people that recursion is hard before they teach them
about it - weirdly enough those people find recursion hard.

This is why I want to target untainted minds. Before they are corrupted by other
models.
Once you have a particular model in your head you tend to use that as a reference
point for everything you learn after that.

I grew up on Basic and then Pascal, before trying to learn C during my sabbatical
year before university. I started to cry 25 pages into Kernighan and Richie, returned
it to the library and hope for a miracle. The miracle arrived: my first language
(amongst a dozen or so) at university was Standard ML. That was easy to learn and
taught me how to think.

Explaining let-it-crash to people that are used to dealing with defensive code is
very, very hard - I have the scars to prove it.
Being a bit of a mathematician I'm lazy, so I am trying to find a way to avoid this
problem!!

> I think maybe just teaching a new language might be enough ambition
> for this group. I don't mean to throw cold water on this. Just
> thinking out loud.
>
I want the cold wash down!

If not, I would not have asked for feedback.

The more we know about the pitfalls the easier it would be to fix the problem.

>> And now for the controversial part of my idea: this should probably be done using
>> Elixir plus something for the GUI.
>> Yes, I said the other E word, so I'm ready to be stoned ;-) [1]
>>
>> Why Elixir?
>>
>> Programming Elixir requires the same understanding of the Erlang concurrency model in
>> order to program well. Otherwise you are just doing Ruby-on-BEAM, which is kinda lame
>> and misses the boat totally.
>>
>> So using Elixir would allow us to expose people to the Erlang model, which I think is
>> the main point. The more people that uses the BEAM, the better for the
>> FindingDevelopers problem.
>>
>> 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.
>>
>> Furthermore, the Elixir syntax is more familiar to youngsters. I asked my 12 year old
>> son to have a look in the "Introducing Elixir" book and his initial reaction was
>> "That's easy to read, it looks like lua." Minimising the amount of surprise is a good
>> thing!
>
> All of these points are true -- Elixir has a huge advantage here.
> Which is why I'm afraid you must be stoned.
>
You just wrote Elixir...

>> Given that I think games are awesome for teaching there needs to be some sort of GUI
>> element at some point and here I'm leaning towards Elm (http://elm-lang.org) since it
>> is functional, but other suggestions are most welcome.
>
> All I can say for sure is that if you can create a simple developer
> experience around building anything related to *Minecraft* you have a
> chance at capturing the minds of an entire generation of programmers.
>
>> Am I on the right track to anything with this?
>> Is there a need for such a learning resource?
>> Is Concurrent, Functional Programming relevant enough to warrant putting some energy into?
>
> What does the 12 year old say?
He just wants to learn how to program mods for Mindcraft, but he finds Java very hard
to get into. He has code Lua for the ComputerCraft mod in Minecraft, so he likes that
approach to programming.

The main problem he has is how to think about solving a problem, so we have started
with learn.code.org and now we need to find the next step on the latter.

But I think your point about Minecraft is spot on. I have one data point to back
that!

The problem with Minecraft is that it requires 3D graphics - even if it is just
horrible to look at and that is, regardless of language, somewhat hard to teach
people. If there was a simple library out there with an API one could control from
Erlang then it would be interesting to see how far one could take it.

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



More information about the erlang-questions mailing list