[erlang-questions] Erlang for youngsters

Fri Jun 20 00:25:04 CEST 2014

Bob Ippolito writes:

> On Monday, June 16, 2014, Mahesh Paolini-Subramanya <
> mahesh@REDACTED> wrote:
>
>> The most important thing here I believe is to have a nice collection of
>>> simple tasks/problems that are appealing to the target audience and best
>>> (easiest/nicest) solved in Erlang.
>>
>> Amen!
>> The least relevant part of teaching kids programming is the syntax, or the
>> choice of language - they don't, and won't, give a s**t about it.
>>
>
> As someone who has been trying to teach programming, I find that syntax is
> important in that syntax can get in the way. This is one of the reasons why
> the current fashion is to use visual languages for beginners as the "Lego"
> approach makes it impossible to violate syntax rules.
>
> Erlang might be the better choice as it has a simpler syntax with fewer
> rules and surprises in store.
>
True, the language is simple. The difficulty lies in the tooling and the stuff around
making things work.

>
>> As a simple thought experiment, just look at how you raised your kids in a
>> multi-lingual environment (yes my American brethren, this is hard. Pretend
>> :-)  )  Notice how they - fluidly - bounce across languages, massacring
>> every grammar rule ever, but quite happily making sure that you understand
>> that "I amn't going to eat pea, ನಾನು ತಿನ್ನಲ್ಲ, ನಾನು ತಿನ್ನಲ್ಲ, odio odio
>> odio la piselli, i don't wanna, where is my red truck?"
>> Mind you, they will pick up the rules over time, but the key here is the
>> importance of the problem at hand ("How To Avoid Eating Peas") - the more
>> immediately relevant it is to the young 'uns, the more rapidly they will
>> pick up the tools, the specifics of the language be damned.
>>
>
>  Human languages are different in that people can understand syntactically
> invalid spoken word or even mixed languages (per your example). With code
> you either write something that follows the rules and the computer
> understands it, or you have to figure out which rules you violated. If the
> tools are good and the rules are simple or at least consistent it might not
> be so frustrating to pick them up over time by trial and error, but having
> a few simple rules that are taught up-front might be even less frustrating
> than that.
>
This sort of buries Java completely ;-)

But that's not going to save the day for Erlang/Elixir.

Simple, consistent rules are really important. On the consistency side the Elixir
libraries has the upper hand - has to play more with the build tools in Elixir to
gauge if it is easier to explain than Erlang's.

Cheers,
Torben

> Cheers
>>
>> On Mon, Jun 16, 2014 at 6:55 AM, Ferenc Holzhauser <
>> ferenc.holzhauser@REDACTED> wrote:
>>
>> The most important thing here I believe is to have a nice collection of
>> simple tasks/problems that are appealing to the target audience and best
>> (easiest/nicest) solved in Erlang. That's a bit of a challenge considering
>> that Erlang is created to solve problems that are rather "industrial" and
>> most people "from outside" can't really relate to. If the audience is not
>> comfortable with understanding the problem itself then it is tricky to make
>> them understand/like the solution too.
>>
>> This we can see with many new people getting into Erlang: The problems
>> they are given are new and difficult to understand. So they often just go
>> off and eagerly try to solve all sort of issues they are familiar with
>> (even when they are not relevant in the particular case) before even trying
>> to understand what the real challenge is. Then they start complaining that
>> Erlang is not very good for some/many of those issues they are busy with.
>>
>> And other way around: people coming to Erlang with the right understanding
>> of the problem area it is made for find it amazingly simple to learn.
>>
>> Coming from the wrong (or right ?) background my imagination fails to come
>> up with these appealing challenges for the youngster target group, but I'm
>> sure many of you can do much better.
>>
>> Ferenc
>>
>>
>> On 16 June 2014 11:31, Miles Fidelman <mfidelman@REDACTED> wrote:
>>
>> Garrett Smith wrote:
>>
>> 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.
>>
>>
>>
>> I'm with the folks who suggest that this group has fewer pre-conceptions
>> to unlearn.
>>
>> It strikes me that the actor model is far more natural for certain classes
>> of problems - network code, simulation, and gaming come to mind.  It's
>> simply conceptually easier to think in terms of LOTS of independent
>> processes.
>>
>> Miles Fidelman
>>
>>
>> --
>> In theory, there is no difference between theory and practice.
>> In practice, there is.
>>
>> --
>>
>> * Mahesh Paolini-Subramanya
>> <http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png> That
>> tall bald Indian guy..*
>> * Google+ <https://plus.google.com/u/0/108074935470209044442/posts>
>> | Blog <http://dieswaytoofast.blogspot.com/>   | Twitter
>> <https://twitter.com/dieswaytoofast>  | LinkedIn
>> <http://www.linkedin.com/in/dieswaytoofast> *
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

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