[erlang-questions] Erlang for youngsters

Mon Jun 30 09:47:25 CEST 2014

Richard A. O'Keefe writes:

> On 17/06/2014, at 8:17 PM, Torben Hoffmann wrote:
>> 
>> 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. 
>
> One thing on that page hit me in the eye:
>
> 	* Recursion is not immediately visible.
>
> This fits into my general "why can't I *see* the structure?" feeling
> about many programming languages, notably Java and Python, but Erlang
> too.  I often get the feeling that if you need diagrams to help you
> find your way around, there is something important missing from the
> textual notation.  Maybe one day I will be wise enough to see it.
>
I think one of the issues is that structure is inherently a visual thing - at least
to me - and that means that some sort of visualisation is necessary to get the full
picture.

The good thing about Erlang is that you can survive a lot longer without anything on
the visual side, but I think that in order to spread Erlang even further we need to
have some sort of visual notation to help communicate things better.

> One of the things I always liked about Scheme was
> named-let:
>
>    (let <name> ((<var-1> <init-1>) ... (<var-n> <init-n>))
>       <body>)
>
> Within the body, <name> is visible as a function of n arguments.
> It's equivalent to
>
>     (letrec ((<name> (lambda (<var-1> ... <var-n>) <body>)))
>       (<name> <init-1> ... <init-n>)
>
> So it's really just defining and calling a local recursive
> function.  The way it's normally used is as a loop, with calls
> to <name> being tail calls.  (Which in Scheme means it *is* a
> loop, with the tail calls just rebinding the arguments and jumping.)
>
> Perhaps some 'intention annotations' might help.
> Is a function
>  - not supposed to be recursive (directly or indirectly) at all?
>  - supposed to be tail recursive (directly or indirectly)?
>  - supposed to be generally recursive (directly or indirectly)?
>  - meant to terminate because some measure (which?) of some
>    argument or combination of argument (which?) strictly
>    decreases on each recursive call?
> If the compiler enforced such annotations, that could both help
> with debugging (if you meant something to be tail recursive but
> it wasn't, for example) and make it easier to read.
>
> Imagine something vaguely like
>   -recursion(sort(List, Comparator), {general, length(List)}).
>
This is a quite interesting idea.

I can see it working for really good programmers, but how it would fare with
beginners is unclear to me. I have a feeling (not hard data) that it is not the
easiest thing to teach

<snip of DRAKON analysis>

>
>> 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.
>
> Having looked at DRAKON, my opinion is that it has no ideas
> worth stealing.  
>
I appreciate that evaluation - on a second visit I can see the points you are making
and it would not help Visual Erlang by going down a route of adding more details in
the style of DRAKON.

> By the way, who says that an embedded system cannot do
> graphics?  These days, when I pay at a parking building, I'm
> using an *embedded* system that has a colour screen.
> See http://store.earthlcd.com/Home/ezLCD for an example of
> a company boasting that their touch LCD products
> 'work.. with any micro-controller, including Arduino'.
> The prices on that page are within the reach of even a school.
>
> Right now I'm looking at www.trademe.co.nz and I'm seeing
> "2014 New Android Jelly Bean4.2.2 10.1 inch 
> 1024*600 capacitive touch screen Dual Core Tablet
> 1G DDR3 RAM 16GB Flash BT WIFI Dual Cameras ... Mic Speaker"
> at "buy now, $180 + $15 shipping".  So that's USD 170, or
> 125 Euros.  I see that Erlang R14 is available for Android:
> http://www.burbas.se/artiklar/erlang-for-the-android-plattform/
> There's also
> http://code.google.com/p/erlang4android/downloads/detail?name=Erlang4AndroidR16B.apk
> which offers "a small version of Erlang" adequate for
> running OTP applications.
>
> So what would it be like to have pupils working on something
> that was plainly and visibly distributed across a bunch of
> cheap tablets?
I'm not saying that embedded systems cannot do graphics. I think embedded systems are
really cool and can do a lot of things.

What I fear - after playing with the Raspberry Pi myself - is that introducing an
embedded platform might take too much attention away from the programming. Hardware
has a way of stealing your time, so it is balance between coolness and not having to
deal with weird things.

At work we run an Erlang Embedded workshop and it is always quite "funny" to wrestle
with the Raspberry Pi's as preparation for the workshop. It just takes time.

But the ezLCD you mention has the benefit that it can be hooked directly up to a
computer via USB and then you are in business. So it might be a good route into
getting the cool factor of hardware involved.

Thanks for the good insights you have provided.

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