On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: > > The benefit is that Emacs is that its not constantly changing, and it > gives you some stability over the years. I like latex, for instance, for > the same reason. I can still access a 10 year old document and use it. >
First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as "640K ought to be enough for anybody". It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of normal menus and/or mouse support is going to blow up spectacularly when used with 1980s-vintage Unix (or MS-DOS) software, or at best will end up controlling the xterm/Command Prompt window instead of the underlying app. * Interoperation with other (non-operating-system) software. On Windows it won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting to paste into something else (web browser, calculator, etc.) is doomed to failure. This is a general problem with pre-window-system software, much like the stuff listed under Accessibility, with no easy solution. Terminal emulators tend to provide some way to copy from their display into the host-native clipboard, but it tends to be clunky (the Windows command prompt appears to require mouse use, with no keyboard shortcuts) and runs into the obvious difficulties as soon as you want to copy more than will fit on one screen. Ironically, really primitive stuff like ls and dir that just dump possibly-paginated noninteractive listings to the term are easier to make big copies from than text-mode, interactive applications like screen-oriented editors, because you can copy from the backscroll buffer of the terminal emulator in the first case. Pre-window-system *graphical* apps are the absolute worst, e.g. later, WYSIWYG word processor versions on MS-DOS, or pre-window-system X applications. No internal support for the host clipboard and, at the same time, nothing the emulator will recognize as text, meaning if you try to native copy and paste you'll end up with a PNG or something. OCR might work on that, if you can find cheap or free OCR software that's any good. Your better bet would be to save the document as some format that can be read by a native windowed app and then open the file in that, then copy, and at that point you might as well edit in the native windowed app and throw out the legacy cruft entirely, since you'll have to deal with the native app anyway, and the cost of switching between them constantly, reloading in the native app so it sees changes, and re-locating the places you want to copy from in the native app will quickly grow to outweigh any advantage the legacy app might somehow have due to some feature it has that you haven't found in any native app. Put more simply, there are giant costs to not playing well with others, and these are inevitably incurred by all applications developed prior to the advent of a) window systems with window managers, systemwide copy/paste, and etc. and b) widespread user-interface standards for common cross-domain tasks like save and paste. Ultimately, the costs incurred every time you or some data need to cross the boundary between the legacy application and the modern world are likely to vastly outweigh whatever few missing features you can find only in legacy applications and never in any of their modern counterparts, as moving anything across that boundary is likely to be fiddly at best (e.g., mark/copy from Command Prompt window) and require saving a file manually and manually opening it in another application at worst (e.g. copying text from a pre-Windows *graphical* version of WordPerfect into a Firefox form box to use in a blog comment or something.) Maintaining and learning virtual machine software is likely to be necessary as an additional overhead, for legacy applications that can't be run natively at all anymore (most pre-Windows graphical apps and anything that assumes it can talk directly to the hardware), and even terminal emulators add a smaller amount of such overhead for the user. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
