[erlang-questions] Erlang for youngsters

[Torben Hoffmann]

Fred Hebert writes:

> Answers inline (and better seen through fixed-width font)
>
> On 06/16, Torben Hoffmann wrote:
>> I think that fault-tolerant, distributed programming is hard because there is a big
>> context you need to address. The sheer about of things that can go wrong will make it
>> difficult to get into.
>> 
>> I think that concurrent programming is easy to learn:
>> 
>
> I'm injecting myself in here to put emphasis on that part. The objective
> here is to teach concurrent programming and fault tolerance, right?
>
To be precise: the objective would be to teach how processes and message passing can
be used to architect solutions.
I think that the underlying message passing is part of what leads to architectures
that are loosely coupled despite the fact that we always strive for using processes
through their API instead of sending messages directly.

In Visual Erlang I have notation for both calling a function and sending a message,
but calling an API function has the easiest arrow, namely a line with an arrow at the
end. That it looks like sending a message due to the arrow is fully intentional,
because that is how one talks about it. Or at least that's how I and those in my
neighbourhood talk about it. 

>> Here's a simple process that just acknowledges that it has received a message and
>> continues to do so over and over again:
>> 
>> echo() ->
>>   receive
>>     Msg ->
>>      io:format("I'm happy, 'cause I recevied: ~p~n", [Msg]
>>   end,
>>   echo().
>> 
>> The file example1.erl contains the echo function.
>> Open up the Erlang shell:
>> $ erl
>> 
>> c(example1).
>> 
>> (this compiles the code and now you can start an echo process)
>> 
>> Pid = spawn ( fun() -> echo() end ).
>> 
>> (you just stored the process identifier (Pid) for the process you spawn, so now you
>> can send it a message:)
>> 
>> Pid ! "Erlang is cool".
>> 
>> "I'm happy, 'cause I received: Erlang is cool"
>
>
> Here's what could be even nicer: have an IDE (or something like
> scratch). Every process is its own block on the screen, visual:
>
>
>  *-------------[echo]--------------------------* *----[ProcX]-----*
>  | echo() ->                                   | |  ...           |
>  |   receive                                   | *----------------*
>  |       Msg ->                                |
>  |         io:format("I'm happy, ...", [Msg])  | *---[Output]-----*
>  |   end,                                      | |                |
>  |   echo(),                                   | |                |
>  *---------------------------------------------* *----------------*
>
> Click 'run'. Click the process, and have a prompt that lets you write in
> a message: "Erlang is cool". See the box hilighted when code runs there:
>
>  *=============[echo]==========================*  *----[ProcX]-----*
>  || echo() ->                                  || |  ...           |
>  ||   receive                                  || *----------------*
>  ||       Msg ->                               ||
>  ||         io:format("I'm happy, ...", [Msg]) || *---[Output]-----*
>  ||   end,                                     || |                |
>  ||   echo(),                                  || |                |
>  *=============================================*  *----------------*
>
> see the output in another box:
>
>  *-------------[echo]--------------------------* *----[ProcX]-----*
>  | echo() ->                                   | |  ...           |
>  |   receive                                   | *----------------*
>  |       Msg ->                                |
>  |         io:format("I'm happy, ...", [Msg])  | *===[Output]=====*
>  |   end,                                      | || I'm happy,   ||
>  |   echo(),                                   | || 'cause I ... ||
>  *---------------------------------------------* *================*
>
> Hell, at this point it no longer needs to be Erlang, if you really want
> to teach the principles, and not the language. The question here really
> is: what's the objective?
>
> I mean, let people put colors on the boxes, even be able to change
> their shapes and brightness and events and they'll probably be able to
> create fancypants blinkenlight stuff, or want to use it as a monitoring
> dashboard for whatever.
>
> If the objective is to teach Erlang for them to learn the principles it
> stands for, teaching these principles should come before 'teaching
> Erlang' in how the educative environment is set up.
>
This is a very good idea. I wish I had gotten it first.

Creating an IDE where creating processes and functions without having to worry about
modules, compilation and what-have-you would be the ideal way of teaching concurrency
based on processes and message passing.

I think that Visual Erlang could be augmented to provide the visual part of the IDE.
After solving an exercise the resulting code could be shown like learn.code.org does
it - that would open up the door to the more complicated modules in an lenient
manner. Basically, there would be an ability to gradually move from visuals to actual
typing of code.

> If the objective is 'teach Erlang', then you'll have to make different
> assumptions entirely.
>
Totally. I had a hunch about what I thought might work, but this thread gives me a
lot of input regarding what the solution or solutions could be.

Cheers,
Torben

> Regards,
> Fred.


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