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

[Vlad Dumitrescu]

Hello Richard,

Thanks for the long and interesting answer.

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". I don't believe there is
something intrinsic to 'graphical' that makes it bad. 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.

On Mon, Feb 3, 2014 at 3:08 AM, Richard A. O'Keefe <ok@REDACTED>wrote:

>
> On 31/01/2014, at 11:40 PM, Vlad Dumitrescu wrote:
>
> Why does automating something have anything to do with that thing being
> textual or graphical? vim runs in a console, but also as gVim (graphical).
> The same can be said about emacs and XEmacs.
>
> gVim is still a textual interface.
> XEmacs is not "Emacs using X11" but a fork of Emacs;
> the latest stable release of XEmacs appears to be 2009.
>
> The fact that emacs uses a GUI does not make the thing that
> is being edited "graphical".
>

Here is the first semantic point: you are absolutely right. Then why call
Eclipse "graphical"? It still edits text! If the thing with Eclipse is that
it has a lot of graphical ornaments around the text, then my point was that
Emacs has toolbars and status bars and such too. The amount of it can be
trimmed in Eclipse and it can be increased in Emacs, if one wants to.


> 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. Just because Eclipse might be
difficult to understand/explain doesn't make all possible similar tools
bad. 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). There's a lot of
functionality in both, it has to take some place to describe and explain
it.

[[As an aside, books nowadays are way too thick and I believe it's because
authors get payed in proportion with the number of pages. I may be wrong,
but books were thinner and more to the point in the past. So maybe they
aren't a good comparison item.]]


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


> Or in Erlang (and doing some wishful thinking), wouldn't it be useful if
> one could actually _see_ in real time the network of processes in a node,
> how they are linked/monitoring each other, how they communicate, which ones
> are growing large or seem deadlocked, zoom out for a bird-eye view or in
> for details?
>
>
> Let's take a form of diagram that is widely agreed
> to be straightforward.  A box represents a class;
> an arrow from X to Y represents "X inherits directly
> from Y".
>
> I have a Smalltalk system of my own.  When you compile
> a program, it spits out a "map" file, which includes a
> list of classes at the top using indentation to show
> inheritance.  This can be turned automatically into a ".dot"
> file for display using GraphViz or any of several other
> programs that read ".dot" files.
>
> 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...

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.


> 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. See for example
https://code.google.com/p/gource/ on how a project's VCS history can be
visualized -- 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..


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


>  Of course, this changes when I need to do something that the
> environment doesn't support. But even so, there is always the fallback of
> doing it as if no IDE was available, so I don't think that having an IDE
> can make things worse.
>
> In one sense, what makes things worse is indeed not having
> an IDE, but _having_ to have an IDE.
>

 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? Emacs _is_ an IDE. One can
choose only to use the editor, but so can one do with Eclipse too.


> In another sense, using an IDE can indeed result in worse
> code.  <...snip...> An IDE _can_ do this, and in fact Smalltalk
> systems are especially good at that.  But the more screen
> space the IDE takes up for _being_ an IDE (in Smalltalk,
> about 50%; in Eclipse, it's worse) the harder it is to actually
> do this.
>

Again, many IDEs have ways to remove the toolbars and menus while editing
(usually called zen-mode). One doesn't have to have all the blinking
windows open at the same time. Soem IDEs are better at that than others, of
course.

> Knuth could do this amazing thing with TeX (practically no bugs) for all
> the reasons you stated, but also because he set very strict boundaries for
> what TeX is and can do. Basically, he not only froze the specifications, he
> set them in stone. If that would have been enough, would there have been a
> need for XeTeX, pdfTeX, laTeX and other tools that extend and improve the
> basic TeX?
>
> Yes.  And those things were only made *possible* by the existence of
> the stable core.
>

 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. There
might be other pieces of code around that are just as bug-free, only that
people didn't extract them as standalone entities. For example, core LISP
interpreters can fall in that category - I bet it's been a long time since
emacs had a bug related to the interpreter proper.

> Would it have been possible to keep the bug levels as low if these
> extensions and improvements had been part of the core TeX?
>
> You are right: that is an excellent argument for keeping a small
>  stable core.  But weren't you just arguing _against_ that?
>

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.


>  For some reason text interfaces seem to be better specified and
> more stable than GUI interfaces.  Every release of Word I have
> to relearn the interface; while I have LaTeX documents from 1984
> I can still use.
>

Unfortunately, new and shiny GUIs are used as selling points for new
versions of a software, partly to hide the fact that an upgrade might not
be necessary at all. This is not an inherent problem for the GUIs, I can
imagine that if Emacs was a Microsoft product, we would have new spelling
on the commands on each version :-)

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140203/a753ee76/attachment.htm>