<div dir="ltr">Hello Richard,<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for the long and interesting answer. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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. <br>
<br><div class="gmail_quote">On Mon, Feb 3, 2014 at 3:08 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">
<div style="word-wrap:break-word"><div><br>On 31/01/2014, at 11:40 PM, Vlad Dumitrescu wrote:<br><blockquote type="cite">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.</blockquote>
<div>gVim is still a textual interface.<br></div></div><div>XEmacs is not "Emacs using X11" but a fork of Emacs;</div><div>the latest stable release of XEmacs appears to be 2009.</div><div><br></div><div>The fact that emacs uses a GUI does not make the thing that</div>
<div>is being edited "graphical".</div></div></blockquote><div><br></div><div>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. </div>
<div> <br></div><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"><div style="word-wrap:break-word"><div>The (first edition of) the book that explains how to *use*</div>
<div>Eclipse is bigger than the listing of my emacs-like editor</div><div>PLUS the listing of the C compiler I originally used to</div><div>write it PLUS the listing of the UNIX kernel it originally</div><div>ran on PLUS the manuals.</div>
</div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>[[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.]]</div>
<div> </div><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"><div style="word-wrap:break-word"><div>
<blockquote type="cite">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></blockquote></div><div><div>I think Joe agrees with you, except that Joe places a heavy<br>
</div></div><div>emphasis on</div><div> - something that has precise definition</div><div> - explicit and straightforward semantics</div><div> - that he can understand.</div>
</div></blockquote><div><br></div><div>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. </div><div> </div><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">
<div style="word-wrap:break-word"><div><div><blockquote type="cite">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?</blockquote>
<div><br></div></div><div>Let's take a form of diagram that is widely agreed</div><div>to be straightforward. A box represents a class;</div><div>an arrow from X to Y represents "X inherits directly</div><div>from Y".</div>
<div><br></div><div>I have a Smalltalk system of my own. When you compile</div><div>a program, it spits out a "map" file, which includes a</div><div>list of classes at the top using indentation to show</div><div>
inheritance. This can be turned automatically into a ".dot"</div><div>file for display using GraphViz or any of several other</div><div>programs that read ".dot" files.</div><div><br></div><div>The one that's actually _useful_ is the text file, because</div>
<div>there doesn't seem to be any good way to display nearly</div><div>800 classes in one diagram. Heck, the collection hierarchy</div><div>alone has 176 classes; try getting just _that_ in one display.</div></div></div>
</blockquote><div><br></div><div>And there is a good way to display this hierarchy in textual form on a single page? That would be the equivalent... </div><div><br></div><div>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 <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. </div>
<div> </div><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"><div style="word-wrap:break-word"><div><div></div>
<div>Now, visualising the process structure would be nice, except<br></div><div>that someone *did* this using UbiGraph and the result was</div><div>as dismaying as it was cool. Erlang lets you have *lots* of</div><div>processes, and that's just what doesn't suit a diagram.</div>
</div></div></blockquote><div><br></div><div>See above. The breakthrough would be to be able to detect which processes are important to show and when. 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 -- 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..</div>
<div> </div><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"><div style="word-wrap:break-word"><div>
<blockquote type="cite">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).</blockquote><div><span style="color:rgb(34,34,34)">We can measure the complexity of an environment in itself</span><br>
</div></div><div>without reference to what we are accustomed to.</div><div>The text editor I normally use takes less than 15 000 raw</div><div>lines of C (less than 8 000 SLOC); executables and help</div><div>files come to 173 kB on disc.</div>
<div>That _has_ to be less complex than Emacs.app, which is<br></div><div>161 MB on disc.</div><div>And that _has_ to be less complex than Eclipse for C/C++<br></div><div>where the smallest download seems to be 141 MB compressed.</div>
<div>And the really annoying thing is that the actual text</div><div>editing support in Eclipse is far more limited than that</div><div>in the 173 kB program!</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><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"><div style="word-wrap:break-word"><div><div>
<div></div><blockquote type="cite"> 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.<br>
</blockquote><div><span style="color:rgb(34,34,34)">In one sense, what makes things worse is indeed not having</span><br></div></div><div>an IDE, but _having_ to have an IDE.</div></div></div></blockquote><div><br></div>
<div>
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.</div>
<div> </div><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"><div style="word-wrap:break-word"><div><div></div>
<div>In another sense, using an IDE can indeed result in worse</div><div>code. <...snip...> An IDE _can_ do this, and in fact Smalltalk</div><div>systems are especially good at that. But the more screen</div><div>
space the IDE takes up for _being_ an IDE (in Smalltalk,</div><div>about 50%; in Eclipse, it's worse) the harder it is to actually</div><div>do this.</div></div></div></blockquote><div><br></div><div>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.</div>
<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">
<div style="word-wrap:break-word"><div><div><blockquote type="cite">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?</blockquote>
<div>Yes. And those things were only made *possible* by the existence of<br></div></div></div><div>the stable core.</div></div></blockquote><div><br></div><div> 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.</div>
<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"><div style="word-wrap:break-word"><div></div><div><div><blockquote type="cite">
Would it have been possible to keep the bug levels as low if these extensions and improvements had been part of the core TeX? <br></blockquote><div>You are right: that is an excellent argument for keeping a small<br></div>
</div></div>
<div>stable core. But weren't you just arguing _against_ that?</div></div></blockquote><div><br></div><div>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. </div>
<div> </div><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"><div style="word-wrap:break-word"><div></div>
<div>
For some reason text interfaces seem to be better specified and</div><div>more stable than GUI interfaces. Every release of Word I have</div>
<div>to relearn the interface; while I have LaTeX documents from 1984</div><div>I can still use.</div></div></blockquote><div><br></div><div>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 :-)</div>
<div><br></div><div>best regards,</div><div>Vlad</div><div> </div></div>
</div></div>