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

[Ulf Wiger]

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.

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.

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/7911bdab/attachment.htm>