[erlang-questions] Erlang for youngsters

Tue Jun 17 10:17:06 CEST 2014

lloyd@REDACTED writes:

> Hello,
>
> So many great ideas. So many talented contributors.
Indeed!

> A fantasy---
>
> One or more of...
>
> - a website
> - hosting platform
> - an e-book - free for download
> - a hard-cover book - royalties kick back to help kids 
> - a hardware platform - profits kick back to help kids
>
> Projects
>
> - build your own website 
> - chat with friends
> - organize your collections
> - build a multi-player game
> - control a robot
> - control your house
> - build your own supercomputer
> ????
>
> Contest for project submissions
>
> Team
>
> - dedicated Erlang volunteers
> - perhaps formalize with a foundation ala Raspberry Pi
>
> Process
>
> - Dream
> - Brainstorm
> - Set goals
> - Organize
> - Delegate
> - Produce
>
I think the dreaming has started... but lets get the main direction in place before
we run into things.

I had a look at the CodeClub organisation that Fred mentioned.
Though it is targeted at 9-11 year old kids they - like many others - start with a
visual environment. They use Scratch - Fred outlined what it could look like for
Erlang/Elixir elsewhere in this thread
(http://erlang.org/pipermail/erlang-questions/2014-June/079563.html). 

I initially sat the target to be 12-15 year old kids, but I have a feeling that a
visual environment would still have a lot of mileage with that group.
Basically, it would be nice to have a one-stop installer that contains both the
environment and the Erlang/Elixir system. Simply no friction if at all possible.

So that is the first branching point: visual or text?

Staying on the visual track for a second; I had a look at the DRAKON editor
(http://drakon-editor.sourceforge.net/drakon-erlang/intro.html) which has
support for Erlang to generate code. Unfortunately it does not generate idiomatic
Erlang code and the Tcl UI feels a bit dated. 

Visual Erlang (https://github.com/esl/visual_erlang) is still in its infancy, but
adding extensions to fit the teaching purpose is not impossible. One can steal ideas
from DRAKON and other notations like SDL.

All of this is something that is non-trivial to do. The MIT team behind Scratch has
spent years getting their environment to work.

Second branching point: Erlang or Elixir?

The main objective should still be to introduce the Erlang way of approaching
programming which is the foundation of Elixir as well, so either language would work
for this. 

I think we need to device some sort of experiment that can gauge which is the right
choice. That, unfortunately, requires work on both of them, but it beats the
alternative of running down the wrong path only to realise it when it might be too
late. 

> Platform
>
> - Software projects can be done on Windows assuming easy peasy Erlang install
>
Erlang runs on every platform, but Windows is the one with the worst support.

> - How can we get youngsters into Linux?
>
> - A hardware platform would open up robotics and control applications:
>
> Cheap (under $100) ARM boards
>
> -- Arduino etc.
>
> -- Raspberry Pi
>
> -- I have an Odroid U3 on my desk. No time to fire it up yet; but very compact,
> quiet, low power, plenty of computing power, runs Linux. Total of $90 for board,
> pwr supply, HDMI cable, wi-fi module, and case. Would need an MicroSD card with
> Linux and Erlang installed.  
>
> Over the past year there have been a slew of such devices hitting the market and
> more coming. 
>
That hits the third branching point: computer or embedded?

At ESL we have some experience with the embedded side of things. It adds a lot of
extra variables to the equation, but it is arguably also a lot of fun.

We might be able to get Erlang to run on a thing like the Arduino Yun
(http://store.arduino.cc/index.php?main_page=product_info&cPath=11_12&products_id=313),
but only on the Linux side. Running on the micro controller is out of the question -
32KB RAM is not enough for Erlang. Raspberry Pi just works.

Going embedded means that doing things with graphics is impossible.
On a computer we could tap into graphical libraries, say Processing, and create a
very visual feedback.

Opinions on the branching points most welcome!

Cheers,
Torben

> Can we get /software/hardware cos to help sponsor the effort?
>
> Best,
>
> Lloyd
>
>  
>
>
>  
>
>
>
>
>
> -----Original Message-----
> From: "Ferenc Holzhauser" <ferenc.holzhauser@REDACTED>
> Sent: Monday, June 16, 2014 1:30pm
> To: "Tony Rogvall" <tony@REDACTED>
> Cc: "erlang-questions@REDACTED" <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] Erlang for youngsters
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 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
>>> <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
>>
>>
>> "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

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