[erlang-questions] The quest for the perfect programming language for massive concurrency.

[Vlad Dumitrescu]

On Mon, Feb 3, 2014 at 11:32 AM, Ulf Wiger <ulf@REDACTED> wrote:

>
> On 3 Feb 2014, at 10:01, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
>
> There are tools that can show large diagrams in a way that works much
> better (for example, by using a hyperbolic mapping where the current item
> is large and in the middle and the less related other items are to it, the
> smaller and more to the periphery they are. Panning in the diagram brings
> other items in focus). There's a lot of research on this, see for example
> http://www.visualcomplexity.com/vc/. Just because the simplest diagrams
> aren't good enough doesn't mean that any diagram is bad.
>
>
> I think this is the crux of the matter.
>
> It all comes down to abstractions, and also whether textual abstractions
> and graphical abstractions complement each other.
>
>
Yes, indeed. And also a matter of what purpose the respective
model/representation has.

As a matter of fact, one of the most useful examples of using a diagram in
my experience relies on it being messy! For a complex system where one
wants to see the dependencies between the different
classes/packages/objects/modules, the impact that the resulting messy
diagram is huge -- as is the comparison with a cleaner one after the
necessary refactorings. This is something that would be much more difficult
to represent as text.

When color coding a text, for example syntax highlighting or just
emphasizing the functions in a module, that isn't pure text anymore. Nor is
it really graphics either. Now if I annotate text with arrows, where do we
get?



> As an Erlang programmer, I got involved in the discussion about using
> graphical tools to aid Erlang development already in 1996. I was by no
> means the first: people had already been experimenting with Erlang and SDL.
> The finding with SDL was that it maps easily to Erlang, but didn't add that
> much value, as Erlang-as-text had roughly the same, if not greater,
> abstraction power.
>
>
Erlang programs where SDL would apply are naturally structured in small
units around each process. One has to make a special effort to write
spaghetti-like code, where the textual cross-references are hidden and
obfuscated and where SDL would help a little more (because it trims
irrelevant noise). For other languages, the norm leans towards spaghetti,
but that's not the tools' fault. They just fill an ecological niche. I
assume that the language creators didn't make it weird on purpose, so that
they can sell expensive tools later... but that's another discussion.

regards,
Vlad



> The question I was asked to answer was how we could use UML tools for
> Erlang development. The conclusion was that we shouldn't use them at all,
> since the ones we studied at the time mainly helped with automating the
> production of OO-specific boilerplate, which lacked a counterpart in
> Erlang. The things that would have been nice to visualize in Erlang, the
> UML tools could not help with. What they did bring that developers did
> *not* need, was the need to understand which parts of the visual model were
> useful and which should be avoided, and how to translate back and forth
> between different abstractions.
>
> Some years later, I found myself in the same kind of debate (it never
> really ended), but regarding another modeling tool. Surprisingly that time,
> the expert that the company sent to convince me turned out to be a closet
> Erlang fan, and agreed with me that the 'modeling language' actually had -
> at best - comparable expressive power to Erlang, but sufficiently different
> that using the tool would require an unnecessary lateral move, translating
> modeling code to Erlang that could have been written just as concisely in
> Erlang to begin with.
>
> In one of my previous jobs, I was later asked to participate in a debate
> about modeling. Joe and I were to represent the "anti-modeling side". We
> were both perplexed, since we didn't view ourselves as anti-modeling at
> all, but rather argued that we do *a great deal* of modeling - just not
> using a graphical modeling tool, and specifically not using UML.
>
> As an example of what I viewed as powerful modeling in textual form, I
> went through an example from Conal Eliot's FRAN [1], a handful of lines of
> Haskell code that described how to take a 3D model of a teapot, replicate
> the pot and animate each with individual parameters. I can't say that it
> drove my point home, but I still think it was a good example. The key point
> about models is not that they are graphical, but that they are well-defined
> and appropriate - and actually aid understanding rather than confound it!
>
> I also used as an example a page from a manual on Executable UML, where a
> one-line expression was modeled graphically - a diagram that took up the
> entire page! The one-liner was easy to understand; the graphical model was
> practically impossible to understand. Basically, the manual ilustrated that
> the pictorial language of UML, albeit both verbose and redundant, did not
> have the expressive power to concisely describe the semantics in question,
> so a text-based language was used to fill the gap.
>
> I have nothing against this. What I object to is the insistence to present
> the graphical model anyway, even if it brought nothing to the table but
> confusion. Of course, had the purpose been to illustrate this very fact, it
> would have been helpful. Perhaps it was and I just missed it?
>
> Of course, nothing either Joe or I said ended the debate - nor did
> anything the other side said.
>
> BR,
> Ulf W
>
> [1] http://haskell.cs.yale.edu/wp-content/uploads/2011/02/icfp97.pdf
>
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140203/d7ec19fd/attachment.htm>