[erlang-questions] Erlang for youngsters

Ferenc Holzhauser ferenc.holzhauser@REDACTED
Mon Jun 16 14:33:48 CEST 2014


+1
Yes indeed, "simple" is key here. Probably the attention span in this age
is still fairly short so quick results are very important. Actually in any
age: quick results make learning more fun.
Easy to use building blocks (functions) that make things more "spectacular"
but allowing to stay focused on the key areas/ideas sound like a really
good idea.


On 16 June 2014 13:55, Mark Nijhof <mark.nijhof@REDACTED> wrote:

> +1 on this, this rings very true to home. But I also believe that it needs
> to return results quickly. I.e. building a game is great, but if they have
> to "code" for days before they see something happen then they loose
> interest (assumption). So preparing "building blocks" might be a good
> approach and have them first implement higher level stuff and then step by
> step dig deeper and implement the building blocks you prepared.
>
> An other exercise I planned is to program a drone (not sure about the
> language there yet) to fly an obstacle course. So they see it is not just
> something that happens on their iPads ;)
>
> -Mark
>
>
> On Mon, Jun 16, 2014 at 1:36 PM, 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 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.
>>
>> 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.   .... Yogi Berra
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>>
>> --
>>
>> * 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
>>
>>
>
>
> --
> Mark Nijhof
> t:   @MarkNijhof <https://twitter.com/MarkNijhof>
> s:  marknijhof
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140616/57da3e0d/attachment.htm>


More information about the erlang-questions mailing list