<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>On 31/01/2014, at 11:40 PM, Vlad Dumitrescu wrote:<br><blockquote type="cite">---<br>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><br></div>gVim is still a textual interface.<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><br><blockquote type="cite">Whether we want it or not, to the human brain images are lower level than text or speech.</blockquote><div><br></div>If you mean that recognising a line is lower level than</div><div>recognising "a line", that's true, but it's hardly relevant.</div><div><br></div><div>Have you ever seen Penrose's notation?</div><div>(<a href="http://en.wikipedia.org/wiki/Penrose_graphical_notation">http://en.wikipedia.org/wiki/Penrose_graphical_notation</a>)</div><div>A diagram like this</div><div><img alt="" width="120" height="138" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/3/3e/Penrose_bianchi_identity.svg/180px-Penrose_bianchi_identity.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/3/3e/Penrose_bianchi_identity.svg/240px-Penrose_bianchi_identity.svg.png 2x" id="daf2baf8-8979-415f-966e-79b3649ee6ca" apple-width="yes" apple-height="yes" src="cid:731BCA78-B537-4BBA-B5FC-1CBD5521DBA9@otago.ac.nz"></div><div>is composed from shapes recognised by our low level visual</div><div>processing systems, but the meaning of the diagram is *not*</div><div>immediate. It takes rather more training and practice than</div><div>I've had to be able to read these things; at my present</div><div>stage of understanding I would find a page of text _easier_</div><div>to read.</div><div><br></div><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><br><blockquote type="cite"> We can't read text files directly, we interpret the graphical representation of that text, be it on a console or a window. Some people can handle abstractions in their heads more easily than others. The latter category will need help, possibly in the form of tools to visualize the code (or whatever).</blockquote><div><br></div><div>Diagrams are *also* abstractions. In fact they are even *more*</div><div>abstract than text. </div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font>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.</blockquote><div><br></div><div>I think Joe agrees with you, except that Joe places a heavy</div><div>emphasis on</div><div> - something that has precise definition</div><div> - explicit and straightforward semantics</div><div> - that he can understand.</div><blockquote type="cite"> colleague or two to look at it. <br><br>Taking a TeX example, wouldn't you find it helpful to have a window alongside your editor that show in real time how the document is rendered, without the need to run "tex mydoc.tex | pdfview&" (or whatever) yourself once in a while? </blockquote><div><br></div><div>Actually, we _have_ that. It's called TeXShop.</div><blockquote type="cite"><br>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>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><br></div><div>One of the other Smalltalk systems I use has a "show the</div><div>hierarchy of the class I'm browsing" button that actually</div><div>generates UML. It is a pain in the posterior, because you</div><div>can't actually *see* very much, and that's even with your</div><div>attention limited to something with only a handful of</div><div>ancestors and/or descendants.</div><div><br></div><div>There is a beautiful little paper by Alan Blackwell,</div><div>"Correction: a picture is worth 84.1 words"</div><div>(<a href="http://www.cl.cam.ac.uk/~afb21/publications/Student-ESP.html">http://www.cl.cam.ac.uk/~afb21/publications/Student-ESP.html</a>)</div><div>The references of that paper are pretty good.</div><div><br></div><div>Now, visualising the process structure would be nice, except</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><br><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><br></div><div>We can measure the complexity of an environment in itself</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><br></div><div>That _has_ to be less complex than Emacs.app, which is</div><div>161 MB on disc.</div><div><br></div><div>And that _has_ to be less complex than Eclipse for C/C++</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><br></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><br></div><div>In one sense, what makes things worse is indeed not having</div><div>an IDE, but _having_ to have an IDE.</div><div><br></div><div>In another sense, using an IDE can indeed result in worse</div><div>code. It's actually quite easy to write a component correctly.</div><div>The problem is interfaces. Nancy Leveson has a very nice</div><div>little avionics example (FLAPS-EXTENDED) where the machine-</div><div>checked interface remains exactly the same but the semantics</div><div>on one side changes. The only way I know to deal with this</div><div>is to frequently put *both* some clients *and* some suppliers</div><div>of an interface on screen *at the same time* so that I can</div><div>review them. 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><br></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><br></div>Yes. And those things were only made *possible* by the existence of</div><div>the stable core.</div><div><br></div><div>When Knuth wrote TeX, PDF did not yet exist. In fact, Postscript</div><div>did not yet exist. When Knuth wrote TeX, Unicode did not yet exist.</div><div>LaTeX is basically a set of macros sitting on top of TeX that depends</div><div>utterly on TeX underneath, and it's clearly not "needed". (ConTeXt</div><div><a href="http://en.wikipedia.org/wiki/ConTeXt">http://en.wikipedia.org/wiki/ConTeXt</a> would be LaTeX's principal rival.)</div><div><br></div><div>This is rather like saying "if having a C++ standard was a good idea,</div><div>why would TBB or MCSTL exist?" And the answer is that TBB and MCSTL</div><div>wouldn't be any _use_ if there weren't a stable C++ underneath.</div><div><br><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><br></div>You are right: that is an excellent argument for keeping a small</div><div>stable core. But weren't you just arguing _against_ that?</div><div><br></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><br></div><div>From my own experience of the TeX family, it's a lot easier to get</div><div>an everyday understanding of HTML+CSS than it is TeX, but every</div><div>time I've needed something less quotidian, I have found the</div><div>*documentation* of the TeX family to be better than the *documentation*</div><div>of say CSS. (For example, when I read the book about CSS by its</div><div>inventors <a href="http://www.amazon.com/Cascading-Style-Sheets-Designing-Web/dp/020141998X">http://www.amazon.com/Cascading-Style-Sheets-Designing-Web/dp/020141998X</a></div><div>I was frustrated to find no more semantics than was in the W3C</div><div>specifications, which was to say, not enough to let me figure out</div><div>how to get what I wanted.</div><div><br></div><div><br></div></body></html>