[erlang-questions] Erlang for youngsters

Fri Jun 20 04:56:39 CEST 2014

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.

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

I must say that I find the first_to_upper example
at http://drakon-editor.sourceforge.net/drakon-erlang/seq.html
radically unconvincing.  Yes, the two-line version "requires
the reader to unpack the code in his head", but the "visual"
version is about 14 times the screen area and 9 times as many
words, and everything I know about reading says that this is
MORE effort for a human reader.  It is certainly a great deal
more work for a human *writer*, so non-trivial examples are
probably not going to happen.

Additionally, in the 21st century, the first_to_upper/1 example
is unconvincing because it is *wrong*.  A really convincing
example would be one that gets title-casing right for Unicode.

By the time I get to page 3, I'm going "oh NO, this is flawcharts!"

And the absolute stone killer example is the quicksort algorithm
on the 6th page,
http://drakon-editor.sourceforge.net/drakon-erlang/silh.html

It has 32 unreadable boxes and something that looks like a
loop but isn't one.  All to express

    qsort([]) -> [];
    qsort([X|Xs]) ->
      qsort([L||L <- Xs, L < X]) ++ [X] ++ qsort([H || H <- Xs, H >= X]).

(Oh, it turns out that there is a comparator argument as well,
which I hadn't noticed.  "unreadable boxes", remember?)

The proof of failure?  When you blow the diagram up, you discover
that the key partitioning step is a rather tricky bit of *verbatim*
plain old Erlang including a fun.

The recommended treatment of compound conditions in DRAKON-Erlang
is an open enemy of algebraic thinking and abstraction.

By the time you get to page 9, a deep irony strikes home.
Functional programming is criticised several times for not
having loops -- which is news to anyone who has used a
comprehension -- but it turns out that DRAKON-Erlang does
*nothing* to reveal the looping structure that *is* there
(arguably implicitly) in Erlang code.  The quicksort
example emphasises trivial matters and almost succeeds in
hiding the core recursions.  You can't *see* that it is an
instance of the divide-and-conquer paradigm.

Also damning: DRAKON-Erlang as presented at that site offers
nothing other than aggregation for structuring a module.

(I find it curious that UML does not normally show any
relationships between the methods of an object.  Yet these
relationships can be extremely important for understanding.)

Leon Sterling, writing about Prolog, came up with the idea
years ago that

 - you can often understand Prolog predicates as
   'enrichments' of an underlying 'skeleton'
 - the 'shape' of that skeleton is typically driven
   by the shape of the principal data structure it
   operates on
 - if you TEACH a an algorithm by SHOWING the underlying
   skeleton, students will be able to SEE the pattern,
   but you can't expect them all to figure it out for
   themselves.

The first insight there is precisely the "Why Functional
Programming Matters" insight about why higher-order programming
is useful, and the second insight is just Michael Jackson's
JSP idea applied in a declarative context.  The third insight
came from his experience of teaching Prolog, but is arguably
the later "teach Design Patterns" idea that was known as "teach
algorithm schemas" before "Design Pattern" became a buzzword.

The idea that "if you have a recursive data structure, then
OF COURSE you have a recursive predicate/function to compute
with it, and the structure of the code is usually easy to
derive from the structure of the data" removes pretty much
all of the mystery from recursion, should there be any and
what there is of it.

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

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?