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

[Richard A. O'Keefe]

On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote:

> Hello Richard,
> TL;DR: There's a lot of fine semantics regarding the things at stake here and I'm not arguing that "graphical beats textual", but that "'graphical' appeals to different parts of the brain than 'textual' and which one works better for an individual is a personal matter".

But note that the "personal matter" depends on training and experience
also.

> I don't believe there is something intrinsic to 'graphical' that makes it bad.

There are issues such as
 - density of relevant information
 - accessibility of information

I have begun using some annotations in my Smalltalk system.

	<compatibility: DIALECT>
	    Says that this method exists for compatibility
	    with another Smalltalk system.  Don't blame ME
	    for the interface.

	<supportFor: METHOD>
	    Says that this method exists in order to support
	    the construction of some other METHOD and should
	    not be considered as part of a stable interface.
	    (If METHOD is changed, this might change or go.)

	<compositionOf: FIRST and: SECOND>
	    Says that this method is semantically a composition
	    of two other methods but done a different way that
	    saves space or time or both or done when the
	    composition is legal but the parts would not be.

How does something like UML handle relationships like these?
By *textual* annotations on lines.
Or it would if UML were good at handling relationships between
methods...

I've only just begun exploring this space.  Already it is
clear that some refinement is possible.

<compatibility: _>
   When I look at other systems, I see
	A standard things
	B nonstandard things that seem like a good idea
	C nonstandard things that I don't really feel
	  any need for, but what the heck
	D nonstandard things that stink.
	E useful ideas which badly need redesign.
	  
For B and C I need to give credit where it's due.
There should be a distinction between B and C.
For D, it's hard to annotate something that's not
_there_, but I've been feeling the need to have
*something* that tools can trivially find to say
why a particular class or method is not there.
For an example of E, the way that Squeak and Pharo
handle joining a bunch of strings inspired me, but
it inspired me to do it quite differently.  So I want
to express a relationship between some methods I do NOT
have and some methods I DO have.

So now we have relationships like
	METHOD1 in this system solves the same
	problem that METHOD2 in SYSTEM2 does
	but better because REASON.
Text?  No worries.
Pictures?  Not so good.

<compositionOf: _ and: _>

What is the reason for the composition?
Is it #space (to avoid garbage creation),
   or #time  (to save time),
   or #legality (e.g. to avoid mutating a collection
                 while iterating over it)
   or #concurrency
   or what?

Like I said, I've only just begun exploring what I think
of as the "discourse structure" of code; I'm sure there
is a lot more to be found, and

	the freedom to think in terms of n-ary
	relationships rather than binary relations
	annotated with a <<sterotype>> is important.


> Also, "graphical" is not the same as "having a GUI"; I got them mixed up too in my message. A program can have a good (or bad) user interface regardless of this interface being textual or graphical.

If I understood him, Joe's point was not so much about how
information is displayed to a user but about how accessible
it is to lightweight *tools*.  If there is an easy to drive
programmable interface to the data model, I imagine Joe
has no objection if there is a graphical human interface as well
for those that want it.

Take as an example Microsoft Excel.

On Windows, you can control it programmatically using Visual
Basic for Applications, or could.  You can probably do it
through PowerShell, which is pretty capable.  In MacOS X,
you do it through AppleScript.  (You can probably do it
through FScript as well.)  But I can't get at it the *same*
way on both systems.

> Here is the first semantic point: you are absolutely right. Then why call Eclipse "graphical"? It still edits text!

So,
	% open -a Eclipse
After a l o n g time, I am staring at a window containing

	a circle containing picture of a desk globe
	a circle containing a 4-pointed star
	a circle containing a blue cube, a green pyramid,
	  and an orange ball
	a circle containing a notebook with a green tick
	a circle with a piece of ribbon in it.
	a purple disc with the word "eclipse" over it and
	  a white fuzzy penumbra.

Did someone actually think this was *clever*?

It turns out these things mean

	Overview
	What's new
	Samples
	Tutorial
	Workbench
	nothing whatever

respectively.  A picture is sometimes worth 0.001 words.

> If the thing with Eclipse is that it has a lot of graphical ornaments around the text,

There's Joe's issue and my issue.
I think Joe's issue was availability or not of a simple text-based
*alternative* that can be used by mortals.
From my perspective, Eclipse is about two decimal orders of
magnitude harder to use than Emacs.

> then my point was that Emacs has toolbars and status bars and such too.

No it doesn't, not unless you want it to.
Just verified: it uses one line at the bottom for the minibuffer
and one line above that for the status line.  In an 80 column by
60 line window I can easily spare 2 lines.

> The (first edition of) the book that explains how to *use*
> Eclipse is bigger than the listing of my emacs-like editor
> PLUS the listing of the C compiler I originally used to
> write it PLUS the listing of the UNIX kernel it originally
> ran on PLUS the manuals.
> 
> I'm not sure why that would be relevant.

The relevance is that
 - Eclipse *looks* dauntingly complex when you sit down in
   front of it,
 - when you turn to the reference book for help, it turns
   out that it really *is* dauntingly complex.
   Eclipse all by itself is more complex to understand than
   the *whole* of the software stack I used when doing my
   PhD, and
 - it is hard to approach that complexity incrementally
   because there are *lots* of things you apparently have
   to do to do anything.

I *was* able to learn everything I needed to know about XCode
from a book and from the Apple documentation.  I'm able to
use -- even to extend -- Smalltalk IDEs and I still have
fond memories of using and extending Interlisp-D.  I was at
one time familiar with the sources of three Emacs clones.
But Eclipse has utterly defeated me.  I am never going to be
able to learn it by myself.

> Just because Eclipse might be difficult to understand/explain doesn't make all possible similar tools bad.

Agreed.  I can at least do basic things in NetBeans, but even then,
I'd much rather not.

> Also, I don't know how large a book about using emacs is/would be (at the same detail level as in the Eclipse book).

It's not hard to find out.  The Emacs manuals are free.  The Emacs
user manual is considerably smaller than the Eclipse user book.

> There's a lot of functionality in both, it has to take some place to describe and explain it.

For me the daunting complexity is not "a lot of functionality",
it's the complexity of the interface for *getting started*.
>  
>> In my opinion, what a programming environment brings to the table is multiple ways to look at the code, to quickly see what is going on.
> I think Joe agrees with you, except that Joe places a heavy
> emphasis on
>  - something that has precise definition
>  - explicit and straightforward semantics
>  - that he can understand.
> 
> I think so too. Only the last point has the potential to signify that pure text beats a GUI, and it's a personal thing.

Potential?  The question is not the *potential* but the
*present actuality*, which is that textual systems _do_
(by and large) have more explicit definitions.  Too many
GUI designers seem to take the view "It's a GUI.  How can
it be hard?"

> 
> The one that's actually _useful_ is the text file, because
> there doesn't seem to be any good way to display nearly
> 800 classes in one diagram.  Heck, the collection hierarchy
> alone has 176 classes; try getting just _that_ in one display.
> 
> And there is a good way to display this hierarchy in textual form on a single page? That would be the equivalent... 

No, it's *not* the equivalent.  The equivalent of a picture
that needs to be scrolled around a large wall is a text file
that needs scrolling in one direction only.  For a human
being.  For a program, the important thing is that

 - it is trivial to generate the picture from the text
 - but not the other way around.
> 
> 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.

Sorry, that just does not work in this case.  The things I need
to see together are not close in that sense.

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

It doesn't mean that a more complex diagram is any good either.
In this case, for my purposes, it isn't.

Remember, the goal is not "DISPLAY SOMETHING", it is
"EXTRACT INFORMATION FROM SOMETHING".

Data visualisation is actually one of my interests.
I have seen *way* too many really cute "infographics"
that turned out to be incomprehensible or inaccurate.
(I have a copy of Gephi and had serious difficulties
with its user interface.)

There are some superb data visualisations, but it isn't
_easy_ to design them.

> Now, visualising the process structure would be nice, except
> that someone *did* this using UbiGraph and the result was
> as dismaying as it was cool.  Erlang lets you have *lots* of
> processes, and that's just what doesn't suit a diagram.
> 
> See above. The breakthrough would be to be able to detect which processes are important to show and when.

Yes, that would be nice.  Do you have some idea of how to do that?

> See for example https://code.google.com/p/gource/ on how a project's VCS history can be visualized

I have seen that before.
To me, it's a textbook example of "cute, but what actual
GOOD does it do me?"
If I want to learn something from version control logs,
I'm *not* going to look at a Gource movie,
I'm going to analyse the logs in textual form.

Not idle chatter.  I have a project of my own for which I
*have* analysed the logs to spot patterns.  Plain old
black and white 2D graphs displayed what I had found
perfectly well.  The trick was to GET ACCESS TO THE DATA
in such a way that A SIMPLE PROGRAM CAN PROCESS IT.

> -- imagine a similar thing where the focus is on processes that are active, they are kept in the middle and larger, the links light up when messages are sent, all dynamically as one goes back and forth in time..

If it's just like the one I saw a while back using Ubigraph,
or if it's like Gource, the answer is that it will be as cute
as a basket of kittens in party hats, but won't actually be
any use for analysis.

I am reminded of a prominent secular theologian (that's one of
those strange people who says there is no god THEREFORE let us
do religion).  My father went to one of his lectures, and
afterwards me one of his own students who had also gone.
	Student.  Wasn't X a *wonderful* speaker?
	Dad.      Yes.  But what did he *say*?
	Student.  (Silence.)

>  
>> As a user, one shouldn't need to understand how the environment works (you think Eclipse is complex, I think Emacs is; it's a matter of what we are accustomed to).
> We can measure the complexity of an environment in itself
> without reference to what we are accustomed to.
> The text editor I normally use takes less than 15 000 raw
> lines of C (less than 8 000 SLOC); executables and help
> files come to 173 kB on disc.
> That _has_ to be less complex than Emacs.app, which is
> 161 MB on disc.
> And that _has_ to be less complex than Eclipse for C/C++
> where the smallest download seems to be 141 MB compressed.
> And the really annoying thing is that the actual text
> editing support in Eclipse is far more limited than that
> in the 173 kB program!
> 
> Why is the size or complexity of the code relevant?

(a) Because a small program *can't* have as a dauntingly
    complex an interface as a large one.
(b) Because a small program *can't* have as many
    internal interactions as a large one (the user's
    mental model of what the program is up to will be
    less inaccurate).
(c) Because a large program will, as a rule, have more
    bugs than a small one, and the relationship is
    non-linear.

> I can have short and simple code that implements a program with very weird commands and interaction patterns. I can have a huge complex program with a nice and understandable or discoverable way to use it.

You *can*, but as a rule you *don't*.
>> 
> I understand what you mean. If I use Emacs and I customize it with fancy commands that help my workflow and become dependent on them -- isn't that the same problem as with depending on Eclipse?

No, the question is not "what do *I* depend on" but
"what am I requiring *OTHER* people to depend on".

> Emacs _is_ an IDE.

This really does miss the point, which is that software
developed *using* Emacs is textual.  If Joe develops something
using Emacs, I can read *ALL* of it using TextEdit or pico or
whatever.

Now I've never succeeded in building anything with Eclipse,
but I *can* say that if I build something with XCode, there's
information hidden in all sorts of strange places, and I've
had serious difficulty importing old projects into a newer
XCode.  Heck, I've had serious difficulty importing other
people's projects into the *same* version of XCode, thanks
to important information about the project that was only
accessible using the GUI.
> 
> 
>  What I mean is that implementing a bug-free core is much easier than implementing all the functionality on top of it just as bug-free.

Agreed, and getting the other functionality on top bug-free pretty
much *depends* on there being a small comprehensible core.

> No I'm not. I just don't think that the reason that TeX is practically bug-free has anything to do with it being a backend tool.

Let's be clear about causality here.
I think you are saying
	NOT BECAUSE(backend(TeX), reliable(TeX))
and I am saying
	BECAUSE(reliable(TeX), backend(TeX))

Let me put it this way.  There was a time when I was seriously
considering a move from (La)TeX to another document formatter
with simpler cleaner markup.  I read the manual cover to cover
several times, started playing with it, and found it produced
good-looking output.  But when I ran lint over it, a lot of the
lint warnings turned out to be genuine, and within a day I had
found a number of ways to crash it.  So I dropped the idea of
writing front end scripts to generate input for that processor.
For me,
	BECAUSE(NOT reliable(XXXX), NOT backend(XXXX))