[erlang-questions] Erlang for youngsters

Torben Hoffmann torben.hoffmann@REDACTED
Mon Jun 30 10:32:43 CEST 2014


Robots are always cool.

There is this KERL (Kent Erlang Robotics Library):
http://kerl.sourceforge.net

It does not seem to have been updated for years :-(

But a connection to Player/Stage could be good for teaching.

Cheers,
Torben

Leonard Boyce writes:

> I remember using Rur-ple http://rur-ple.sourceforge.net/ to get my
> daughter interested in programming. She seemed to find it fairly
> entertaining and I was quite impressed at how quickly she progressed.
>
> Something similar for Erlang may work quite well.
>
> Leonard
> --
>
> On Mon, Jun 16, 2014 at 1:30 PM, Ferenc Holzhauser
> <ferenc.holzhauser@REDACTED> wrote:
>> Robotics is really nice but in this case accessibility is even nicer. It is
>> great if kids can play after class too with interesting things without
>> having to put items of fairly significant value (for some) on their
>> <whatever present giving thing comes up next> wishlist. These days a
>> computer with internet access can be a fascinatingly accessible way of
>> creativity. An idea could be to make a simple game backend to compete with
>> their friends and fellow students (e.g. a 2d tank shooting game or
>> something). Eventually with chat and similar functions to add. Then the
>> teacher could make things go wrong on the server(s) that they'd need to fix
>> (distribute/scale/fail over) depending on their progress. You could lure
>> them into AI like things too if you fancy. I'm sure someone with the skills
>> (e.g. SVG/ezwebframe) and time could make some simple client "building
>> blocks" work for something like this.
>>
>>
>> On 16 June 2014 18:12, Tony Rogvall <tony@REDACTED> wrote:
>>>
>>>
>>> On 16 jun 2014, at 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 ;)
>>>
>>> You program drone in Erlang of course :-)
>>>
>>> https://github.com/tonyrog/edrone
>>>
>>> /Tony
>>>
>>> -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
>>>> That tall bald Indian guy..
>>>> Google+  | Blog   | Twitter  | LinkedIn
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>>
>>>
>>> --
>>> Mark Nijhof
>>> t:   @MarkNijhof
>>> s:  marknijhof
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>> "Installing applications can lead to corruption over time. Applications
>>> gradually write over each other's libraries, partial upgrades occur, user
>>> and system errors happen, and minute changes may be unnoticeable and
>>> difficult to fix"
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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



More information about the erlang-questions mailing list