[erlang-questions] Erlang for youngsters

Lloyd R. Prentice lloyd@REDACTED
Tue Jun 17 16:50:45 CEST 2014 

Hi Torben,

Good thoughts. 

But note re:

> 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.

 Odroid U3 runs Ubuntu, has HD HDMI graphics with a fairly powerful graphic coprocessor.

It also has an active community and a very attractive magazine packed with interesting projects:

magazine.odroid.com

I don't want to overly pitch the case since I haven't fired it up and can't speak to warts. But based on printed specs and price/performance, this is a very interesting device.

Summary of specs

Hardkernel lists these specifications for the Odroid-U3:

Processor — Samsung Exynos 4412 Prime SoC:
CPU — Quad-core ARM Cortex-A9, clocked at 1.7GHz
GPU — 3D accelerator Mali-400 Quad Core 440MHz
RAM — 2GB LP-DDR2 SDRAM
Storage:
MicroSD card socket
eMMC module socket
HDMI video interface:
Supports 1080p (H.264+AAC based MP4 container format)
micro HDMI connector
Audio — 3.5mm headphone jack
LAN — 10/100Mb Ethernet (RJ-45 Jack)
USB:
3x USB2.0 Host ports (standard A type connectors)
1x USB2.0 OTG Device port (Micro USB)
8-pin I/O expansion header — UART, IRQ, I2C, GPIO, power
Power — 5VDC @ 2A
Operating system — Xubuntu 13.10; U-Boot 2010.12; Linux kernel 3.0.x; Android 4.x
Dimensions — 83 x 48 x 22mm (with heatsink)
Weight — 48g (with heatsink)

More here:

http://blog.hsc.com/android/technology-trends/raspberry-pi-vs-odroid-u3/

http://hardkernel.com/main/products/prdt_info.php

All the best,

Lloyd

Sent from my iPad

> On Jun 17, 2014, at 4:17 AM, Torben Hoffmann <torben.hoffmann@REDACTED> wrote:
> 
> 
> 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

More information about the erlang-questions mailing list