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

[Vance Shipley]

On Mon, Feb 03, 2014 at 01:29:56PM +0100, Joe Armstrong wrote:
}  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. 

The staff we onboard from school universally expect to be able to
spend almost all of their time with a mouse in their hands, or at
least reaching for it quite frequently.  They expect the environment
to present them with options at any juncture, all they have to do is
answer the multiple choice questions correctly.  They don't want to
have to read too much nor have to search around for things.  Everything
should be found on the desktop.  They have never read a technical book.

As someone who started programming on remote Unix systems over 1200 
baud modems I have developed a different set of expectations.  The
first thing I learned was 'man man' and then found everything else 
by RTFM.  As someone else pointed out the fact that 'make' is still
with us decades on demonstrates that it solves real world problems
quite adequately.  The same is true of sed, awk, grep, vim, etc, etc.
If modern tools spare you from ever having to learn how to construct
command pipelines as part of your workflow are you really better off?

However the kids aren't wrong either.  There should be progress and
maybe workflows based around autotools, make and vim/emacs haven't
delivered advancements in pace with the rest of the world (although
they work a helluva lot better now than the 90s).  It is a reasonable
expectation to have contextual help and code visualizations.  While I
don't find Eclipse or IDEA adding much value for myself there are
graphical tools I do want.  Real graphical tools.

I do a lot of work with communicating finite state machines.  I like
to see these as state diagrams.  Message sequence charts (MSC) are another
viewpoint we use a lot.  I have over the years developed some techniques
to generate these graphical representations from my own Erlang programs.
In 2001 I experimented with parsing my modules into Abstract Forms and
wrote a program which found the state transitions in gen_fsm behaviours.
It output Graphviz DOT files which could then be viewed and manipulated
in other tools.  OTP ships with the 'et' tool which can create MSCs from
executing programs.  The 'observer' presents supervision trees on a 
running system as a directed graph.  These are all actual graphical tools
which I find add to my understanding of my work in significant ways.

Unfortunately these tools are "assembly required".  What I would really
like, and in fact have been working on lately, is an editable version
of the supervision tree and state diagram viewpoints.  If I click on the
blue box symbol I use for a supervisor I should be able to set it's
properties (restart stategy, MaxR, MaxT, etc.) directly.  If I double
click on it a text editor is opened allowing me to change the code.  It
should be possible to drag supervisor, gen_server, gen_fsm, etc. objects
from the palette onto the canvas and construct a new project quickly as
a supervision tree.  It would create the project with all of the template
modules.

I don't see any IDEs doing these sort of things for me in any language,
but there are probably some aspects of this someone will hold up.  Even
so I don't think these are the things the new generation are actually
using.

Having said all that another observation is that real graphical Service
Creation Environment (SCE) type tools have historically never delivered
on expectations.  The reason for this is that the people whose hopes and
dreams were dashed after investing in SCE were under the impression that
with a fully graphical environment they wouldn't need programmers.  The
reality is that even if you take away all the text it's still programming.


-- 
	-Vance