[erlang-questions] Erlang for youngsters

[Torben Hoffmann]

Robert Raschke writes:

> On 30 June 2014 08:47, Torben Hoffmann <torben.hoffmann@REDACTED
>> wrote:
>
>>
>> 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 thing to remember is that different people "see it" differently. I find
> the visual clutter of diagrams tedious and very hard to read :-)
>
Horses for courses ;-)

If the diagrams does not read easily they are done wrong.
An interaction with processes from >=2 modules in Erlang should be possible to
communicate clearly in a diagram. It is a matter of having a visual notation that
fits the domain. 

> I think there must be both, textual and visual, in order to convey
> something to a wider audience, as some will prefer text, some diagrams, and
> some like both.
>
That's part of the reason why I am creating Visual Erlang with a dual textual and
visual notation. Each has it time and place.

> In a previous life, during the requirements gathering phase, I would
> capture business logic as a kind of textual "given-when-then" list of
> bullets, as well as draw a state chart diagram, in order to try my best at
> getting useful feedback from the client on the veracity of the designed
> logic.
>
> The ideal system allows you to move back and forth between textual and
> visual notation, with neither missing anything from the other. This is hard
> to achieve, though :-( And my fear is that such a system would only capture
> the intersection of what the two methods provide. Leading to a useless
> system, as each (text or visualisation) would provide benefits not nicely
> expressible in the other. Is there research in this area that can be tapped
> into?
>
It is truly a difficult balance and I am not aware of any research into this area.

What I have noticed is that in the UML world the main focus with diagrams seems to be
to be able to generate code from the diagrams. Not a route I fancy.

Basically, I think that having a textual-visual correspondence between code and
diagrams, so that one can freely manipulate either, is not going to work.
Better to separate the purpose of the visual notation from the executable nature of
the code.

Cheers,
Torben

> Regards,
> Robby


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