<div dir="ltr"><div>Hi Richard,<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There's a lot of interesting stuff in your post, as always, and most of it I agree 100% but I have this nagging feeling that there's a misunderstanding between us and we're not talking about the same things. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In short, the things you enumerate as advantages of a textual program and the drawbacks of the graphical ones aren't all related to the textual/graphical attribute of the program. That Excel can't be scripted in the same language in all environments has nothing to do with it having a GUI. That Eclipse starts with a "welcome" page that can be confusing, that has nothing to do with GUIs either. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Of course, if we are comparing (say) Emacs in console mode and Eclipse, then we can pick on this kind of detail. What I tried to compare was what could be done with one or other kind of interface. Most things can be done just as well with either; some things work better with one of them, depending of the way the user's brain is wired: I, for example, have easier to work with images/icons/color coding/visual structure. Others, like you, prefer plain text. Excellent! I'm not bashing textual interfaces just because I happen to have other ways that work better for me in certain cases.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Everyone I know draws pen-and-paper diagrams and sketches and charts and finds them useful. If they are useful when drawn by hand, they are useful when drawn by a program. If existing programs are drawing incomprehensible diagrams, it doesn't mean that the right diagram would be just as useless.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If more research was done on things that are actually helping people rather than on things that look good on resumes, then I think we would have much better tools. Likewise, if more thought went to creating a GUI that is actually helping people rather than cramming more cool features into that program, then we'd have much better GUIs. These shortcomings are not intrinsic to a kind of tool or program or interface, so I think we should try to keep them apart.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">best regards,<br></div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 6:48 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On 3/02/2014, at 10:01 PM, Vlad Dumitrescu wrote:<br>
<br>
> Hello Richard,<br>
<div class="im">> 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".<br>
<br>
</div>But note that the "personal matter" depends on training and experience<br>
also.<br>
<div class="im"><br>
> I don't believe there is something intrinsic to 'graphical' that makes it bad.<br>
<br>
</div>There are issues such as<br>
- density of relevant information<br>
- accessibility of information<br>
<br>
I have begun using some annotations in my Smalltalk system.<br>
<br>
<compatibility: DIALECT><br>
Says that this method exists for compatibility<br>
with another Smalltalk system. Don't blame ME<br>
for the interface.<br>
<br>
<supportFor: METHOD><br>
Says that this method exists in order to support<br>
the construction of some other METHOD and should<br>
not be considered as part of a stable interface.<br>
(If METHOD is changed, this might change or go.)<br>
<br>
<compositionOf: FIRST and: SECOND><br>
Says that this method is semantically a composition<br>
of two other methods but done a different way that<br>
saves space or time or both or done when the<br>
composition is legal but the parts would not be.<br>
<br>
How does something like UML handle relationships like these?<br>
By *textual* annotations on lines.<br>
Or it would if UML were good at handling relationships between<br>
methods...<br>
<br>
I've only just begun exploring this space. Already it is<br>
clear that some refinement is possible.<br>
<br>
<compatibility: _><br>
When I look at other systems, I see<br>
A standard things<br>
B nonstandard things that seem like a good idea<br>
C nonstandard things that I don't really feel<br>
any need for, but what the heck<br>
D nonstandard things that stink.<br>
E useful ideas which badly need redesign.<br>
<br>
For B and C I need to give credit where it's due.<br>
There should be a distinction between B and C.<br>
For D, it's hard to annotate something that's not<br>
_there_, but I've been feeling the need to have<br>
*something* that tools can trivially find to say<br>
why a particular class or method is not there.<br>
For an example of E, the way that Squeak and Pharo<br>
handle joining a bunch of strings inspired me, but<br>
it inspired me to do it quite differently. So I want<br>
to express a relationship between some methods I do NOT<br>
have and some methods I DO have.<br>
<br>
So now we have relationships like<br>
METHOD1 in this system solves the same<br>
problem that METHOD2 in SYSTEM2 does<br>
but better because REASON.<br>
Text? No worries.<br>
Pictures? Not so good.<br>
<br>
<compositionOf: _ and: _><br>
<br>
What is the reason for the composition?<br>
Is it #space (to avoid garbage creation),<br>
or #time (to save time),<br>
or #legality (e.g. to avoid mutating a collection<br>
while iterating over it)<br>
or #concurrency<br>
or what?<br>
<br>
Like I said, I've only just begun exploring what I think<br>
of as the "discourse structure" of code; I'm sure there<br>
is a lot more to be found, and<br>
<br>
the freedom to think in terms of n-ary<br>
relationships rather than binary relations<br>
annotated with a <<sterotype>> is important.<br>
<div class="im"><br>
<br>
> 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.<br>
<br>
</div>If I understood him, Joe's point was not so much about how<br>
information is displayed to a user but about how accessible<br>
it is to lightweight *tools*. If there is an easy to drive<br>
programmable interface to the data model, I imagine Joe<br>
has no objection if there is a graphical human interface as well<br>
for those that want it.<br>
<br>
Take as an example Microsoft Excel.<br>
<br>
On Windows, you can control it programmatically using Visual<br>
Basic for Applications, or could. You can probably do it<br>
through PowerShell, which is pretty capable. In MacOS X,<br>
you do it through AppleScript. (You can probably do it<br>
through FScript as well.) But I can't get at it the *same*<br>
way on both systems.<br>
<div class="im"><br>
> Here is the first semantic point: you are absolutely right. Then why call Eclipse "graphical"? It still edits text!<br>
<br>
</div>So,<br>
% open -a Eclipse<br>
After a l o n g time, I am staring at a window containing<br>
<br>
a circle containing picture of a desk globe<br>
a circle containing a 4-pointed star<br>
a circle containing a blue cube, a green pyramid,<br>
and an orange ball<br>
a circle containing a notebook with a green tick<br>
a circle with a piece of ribbon in it.<br>
a purple disc with the word "eclipse" over it and<br>
a white fuzzy penumbra.<br>
<br>
Did someone actually think this was *clever*?<br>
<br>
It turns out these things mean<br>
<br>
Overview<br>
What's new<br>
Samples<br>
Tutorial<br>
Workbench<br>
nothing whatever<br>
<br>
respectively. A picture is sometimes worth 0.001 words.<br>
<div class="im"><br>
> If the thing with Eclipse is that it has a lot of graphical ornaments around the text,<br>
<br>
</div>There's Joe's issue and my issue.<br>
I think Joe's issue was availability or not of a simple text-based<br>
*alternative* that can be used by mortals.<br>
>From my perspective, Eclipse is about two decimal orders of<br>
magnitude harder to use than Emacs.<br>
<div class="im"><br>
> then my point was that Emacs has toolbars and status bars and such too.<br>
<br>
</div>No it doesn't, not unless you want it to.<br>
Just verified: it uses one line at the bottom for the minibuffer<br>
and one line above that for the status line. In an 80 column by<br>
60 line window I can easily spare 2 lines.<br>
<div class="im"><br>
> The (first edition of) the book that explains how to *use*<br>
> Eclipse is bigger than the listing of my emacs-like editor<br>
> PLUS the listing of the C compiler I originally used to<br>
> write it PLUS the listing of the UNIX kernel it originally<br>
> ran on PLUS the manuals.<br>
><br>
> I'm not sure why that would be relevant.<br>
<br>
</div>The relevance is that<br>
- Eclipse *looks* dauntingly complex when you sit down in<br>
front of it,<br>
- when you turn to the reference book for help, it turns<br>
out that it really *is* dauntingly complex.<br>
Eclipse all by itself is more complex to understand than<br>
the *whole* of the software stack I used when doing my<br>
PhD, and<br>
- it is hard to approach that complexity incrementally<br>
because there are *lots* of things you apparently have<br>
to do to do anything.<br>
<br>
I *was* able to learn everything I needed to know about XCode<br>
from a book and from the Apple documentation. I'm able to<br>
use -- even to extend -- Smalltalk IDEs and I still have<br>
fond memories of using and extending Interlisp-D. I was at<br>
one time familiar with the sources of three Emacs clones.<br>
But Eclipse has utterly defeated me. I am never going to be<br>
able to learn it by myself.<br>
<div class="im"><br>
> Just because Eclipse might be difficult to understand/explain doesn't make all possible similar tools bad.<br>
<br>
</div>Agreed. I can at least do basic things in NetBeans, but even then,<br>
I'd much rather not.<br>
<div class="im"><br>
> 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).<br>
<br>
</div>It's not hard to find out. The Emacs manuals are free. The Emacs<br>
user manual is considerably smaller than the Eclipse user book.<br>
<div class="im"><br>
> There's a lot of functionality in both, it has to take some place to describe and explain it.<br>
<br>
</div>For me the daunting complexity is not "a lot of functionality",<br>
it's the complexity of the interface for *getting started*.<br>
<div class="im">><br>
>> 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.<br>
> I think Joe agrees with you, except that Joe places a heavy<br>
> emphasis on<br>
> - something that has precise definition<br>
> - explicit and straightforward semantics<br>
> - that he can understand.<br>
><br>
> 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.<br>
<br>
</div>Potential? The question is not the *potential* but the<br>
*present actuality*, which is that textual systems _do_<br>
(by and large) have more explicit definitions. Too many<br>
GUI designers seem to take the view "It's a GUI. How can<br>
it be hard?"<br>
<div class="im"><br>
><br>
> The one that's actually _useful_ is the text file, because<br>
> there doesn't seem to be any good way to display nearly<br>
> 800 classes in one diagram. Heck, the collection hierarchy<br>
> alone has 176 classes; try getting just _that_ in one display.<br>
><br>
> And there is a good way to display this hierarchy in textual form on a single page? That would be the equivalent...<br>
<br>
</div>No, it's *not* the equivalent. The equivalent of a picture<br>
that needs to be scrolled around a large wall is a text file<br>
that needs scrolling in one direction only. For a human<br>
being. For a program, the important thing is that<br>
<br>
- it is trivial to generate the picture from the text<br>
- but not the other way around.<br>
<div class="im">><br>
> 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.<br>
<br>
</div>Sorry, that just does not work in this case. The things I need<br>
to see together are not close in that sense.<br>
<div class="im"><br>
> Panning in the diagram brings other items in focus). There's a lot of research on this, see for example <a href="http://www.visualcomplexity.com/vc/" target="_blank">http://www.visualcomplexity.com/vc/</a>. Just because the simplest diagrams aren't good enough doesn't mean that any diagram is bad.<br>
<br>
</div>It doesn't mean that a more complex diagram is any good either.<br>
In this case, for my purposes, it isn't.<br>
<br>
Remember, the goal is not "DISPLAY SOMETHING", it is<br>
"EXTRACT INFORMATION FROM SOMETHING".<br>
<br>
Data visualisation is actually one of my interests.<br>
I have seen *way* too many really cute "infographics"<br>
that turned out to be incomprehensible or inaccurate.<br>
(I have a copy of Gephi and had serious difficulties<br>
with its user interface.)<br>
<br>
There are some superb data visualisations, but it isn't<br>
_easy_ to design them.<br>
<div class="im"><br>
> Now, visualising the process structure would be nice, except<br>
> that someone *did* this using UbiGraph and the result was<br>
> as dismaying as it was cool. Erlang lets you have *lots* of<br>
> processes, and that's just what doesn't suit a diagram.<br>
><br>
> See above. The breakthrough would be to be able to detect which processes are important to show and when.<br>
<br>
</div>Yes, that would be nice. Do you have some idea of how to do that?<br>
<div class="im"><br>
> See for example <a href="https://code.google.com/p/gource/" target="_blank">https://code.google.com/p/gource/</a> on how a project's VCS history can be visualized<br>
<br>
</div>I have seen that before.<br>
To me, it's a textbook example of "cute, but what actual<br>
GOOD does it do me?"<br>
If I want to learn something from version control logs,<br>
I'm *not* going to look at a Gource movie,<br>
I'm going to analyse the logs in textual form.<br>
<br>
Not idle chatter. I have a project of my own for which I<br>
*have* analysed the logs to spot patterns. Plain old<br>
black and white 2D graphs displayed what I had found<br>
perfectly well. The trick was to GET ACCESS TO THE DATA<br>
in such a way that A SIMPLE PROGRAM CAN PROCESS IT.<br>
<div class="im"><br>
> -- 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..<br>
<br>
</div>If it's just like the one I saw a while back using Ubigraph,<br>
or if it's like Gource, the answer is that it will be as cute<br>
as a basket of kittens in party hats, but won't actually be<br>
any use for analysis.<br>
<br>
I am reminded of a prominent secular theologian (that's one of<br>
those strange people who says there is no god THEREFORE let us<br>
do religion). My father went to one of his lectures, and<br>
afterwards me one of his own students who had also gone.<br>
Student. Wasn't X a *wonderful* speaker?<br>
Dad. Yes. But what did he *say*?<br>
Student. (Silence.)<br>
<div class="im"><br>
><br>
>> 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).<br>
> We can measure the complexity of an environment in itself<br>
> without reference to what we are accustomed to.<br>
> The text editor I normally use takes less than 15 000 raw<br>
> lines of C (less than 8 000 SLOC); executables and help<br>
> files come to 173 kB on disc.<br>
> That _has_ to be less complex than Emacs.app, which is<br>
> 161 MB on disc.<br>
> And that _has_ to be less complex than Eclipse for C/C++<br>
> where the smallest download seems to be 141 MB compressed.<br>
> And the really annoying thing is that the actual text<br>
> editing support in Eclipse is far more limited than that<br>
> in the 173 kB program!<br>
><br>
> Why is the size or complexity of the code relevant?<br>
<br>
</div>(a) Because a small program *can't* have as a dauntingly<br>
complex an interface as a large one.<br>
(b) Because a small program *can't* have as many<br>
internal interactions as a large one (the user's<br>
mental model of what the program is up to will be<br>
less inaccurate).<br>
(c) Because a large program will, as a rule, have more<br>
bugs than a small one, and the relationship is<br>
non-linear.<br>
<div class="im"><br>
> 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.<br>
<br>
</div>You *can*, but as a rule you *don't*.<br>
<div class="im">>><br>
> 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?<br>
<br>
</div>No, the question is not "what do *I* depend on" but<br>
"what am I requiring *OTHER* people to depend on".<br>
<br>
> Emacs _is_ an IDE.<br>
<br>
This really does miss the point, which is that software<br>
developed *using* Emacs is textual. If Joe develops something<br>
using Emacs, I can read *ALL* of it using TextEdit or pico or<br>
whatever.<br>
<br>
Now I've never succeeded in building anything with Eclipse,<br>
but I *can* say that if I build something with XCode, there's<br>
information hidden in all sorts of strange places, and I've<br>
had serious difficulty importing old projects into a newer<br>
XCode. Heck, I've had serious difficulty importing other<br>
people's projects into the *same* version of XCode, thanks<br>
to important information about the project that was only<br>
accessible using the GUI.<br>
<div class="im">><br>
><br>
> 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.<br>
<br>
</div>Agreed, and getting the other functionality on top bug-free pretty<br>
much *depends* on there being a small comprehensible core.<br>
<div class="im"><br>
> 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.<br>
<br>
</div>Let's be clear about causality here.<br>
I think you are saying<br>
NOT BECAUSE(backend(TeX), reliable(TeX))<br>
and I am saying<br>
BECAUSE(reliable(TeX), backend(TeX))<br>
<br>
Let me put it this way. There was a time when I was seriously<br>
considering a move from (La)TeX to another document formatter<br>
with simpler cleaner markup. I read the manual cover to cover<br>
several times, started playing with it, and found it produced<br>
good-looking output. But when I ran lint over it, a lot of the<br>
lint warnings turned out to be genuine, and within a day I had<br>
found a number of ways to crash it. So I dropped the idea of<br>
writing front end scripts to generate input for that processor.<br>
For me,<br>
BECAUSE(NOT reliable(XXXX), NOT backend(XXXX))<br>
<br>
<br>
</blockquote></div><br></div></div>