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

[Joe Armstrong]

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

I remember it well. The strange things was the almost uniform acceptance of
the idea that models had to manipulated
with some kind of GUI interface and have a graphical interface.  I'd always
viewed type descriptions as models - and UML
as a set of abstract types - but this view was not popular.

Text models are incredibly powerful.

Maxwell's equations describe classical electrodynamic in four textual
equations.

In some domains pictures are great - show me a photo of a rose, a plan of
house, or a set of equations describing the
motions of the planets. No one descriptive method is best.

/Joe


>
> 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
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140203/c0e1beba/attachment.htm>