> Yes, but who is still working with a text terminal?
For one thing, many people in my surroundings are. (Not a hardware terminal like the VT100, of course, but a terminal emulator.) Do we do this because we're dinosaurs, too set in our ways to adapt to a new workflow? I prefer to think it's because the shell has proven itself to be a tool of unparalleled power when dealing with unexpected situations. (GUIs are fine if input and output are within well-defined parameters.) There simply exists no GUI yet for this type of job that has the same versatility as the shell. [Bachelor students usually arrive with only a rudimentary knowledge of the GUI and the ability to start programs and browse directories with the file manager, and they have to be brought up to speed on using the command line. -- "Here's a tarball of the program you will be using. Adapt the configuration to your machine and compile it (and also fix all the stuff the compiler might complain about). And if there's no libfftw for your system, download and compile it yourself. You'll probably need the BLAS as well." -- There are many things that can go wrong in such a situation. How do others go about in dealing with such problems?] > In 1980, it wouldn't have been unusual, as you know, for a > VT-100 to be the user's single interface to the computer. > Any UI feature -- font style & variations, menus, multiple > applications, etc. -- had to be rendered on that one > screen. It's no wonder it became terrifically complex. They > developed programmable fonts, 132-column displays, alternate > screens. It's a testament to human ingenuity. > Today most of those features have been subsumed by the GUI. > Different applications have different windows, different > fonts, graphics, all resizable. We have a potpourri of UI > gadgetry barely imagined in those days. Yet the emulator > remains as muscular and complex as ever, Exactly. Things that are better handled by a GUI have been taken over by GUI programs, but practically all terminals nowadays essentially stick to the same established feature set. Sure, terminal emulator programs have added additional functionality, but those are usually GUI features (multiple tabs, screen splitting, searching in the output, etc.), not terminal capabilities. > just in case someone happens across an RS-232 cable and a > line driver. It's more than accessing old devices connected by a serial line. Think of the sysadmin out in the field alerted by the datacenter to a problem with a server. I imagine many of them will appreciate the ability to log on via ssh from their mobile phone to kill an errant process or restart a service. What are the alternatives? I often see people tending to equate "old" with "outmoded", something to be rid of at the next possible opportunity. But that's not how things work. If something is old but still in use, then it usually means it's at least as good as the alternatives (if any exist at all). It is still being used because it gets the job done. [And regarding the actual topic of this mailing list: it's also why I still prefer using an "old" text formatter such as groff over a "modern" office writing application. A programmable text-based system like groff or TeX allows for easy scriptability, it makes it much easier to achieve consistency and repeatability, and allows version comparison not only of the document text but also of the formatting settings.] Of course there's a certain momentum involved. No manufacturer is likely to single-handedly push (against user expectations) for a radically different interface, unless that interface is very obviously better for at least some of the customers (or the manufacturer has a quasi-monopoly). But cars still have steering wheels after a hundred years of automobile history, and keyboards still have a Qwerty layout (even soft-keyboards on mobile devices, where there is practically zero hardware cost of changing the layout). Why is this so? It seems that the steering wheel has established itself as a successful interface. It's not only used in mass-produced consumer cars but also in specialized vehicles (such as Formula-1 racing cars) where compatibility would be of minor importance. The keyboard layout, on the other hand, is probably driven mostly by momentum. The benefits of a layout different from Qwerty are apparently not significant enough to offset the costs of retraining (meaning that the layout is "good enough"), and without a sufficient user base there's little financial incentive for manufacturing different keyboards. (But much experimentation is going on these days with new text-entry methods for mobile phones and other miniature touchscreens.) Professional writers claim that the Dvorak layout reduces fatigue, but it's mostly used by the comparatively small fraction of users that make very extensive use of the keyboard. > Sadly, for all the advances, documentation has hardly budged, > if indeed it's advanced at all. Even though a good deal of > it is maintained in typeset form, the output predominately is > confined to the application with the poorest text rendering > capability: the VT-100 emulator. That's not entirely true. It's usually command-line tools that are documented by manpages, and that may be seen as a natural extension of their modus operandi (i.e., accessible from the shell). Many complex interactive GUI applications have no manpage at all (or only a short one listing the available command-line switches) -- but there may be a builtin help system or even entire websites with hundreds of html pages describing the program's operation. > Because of poverty owing to neglect -- that is, necessity > being the mother of invention -- the author of the article > I linked to decided he'd like color in his man pages. > Where did he turn? A style sheet in the groff framework, > perhaps? Any kind of improvement to the semantic-display > connection? No, he reached about as far down as possible, > and tweaked the control sequences emitted to the emulator. > Because he could. Because, in a way, he *had* to, insofar > as that strange bit of arcana gave him the most leverage. > So, yes, he's still working with a text terminal, after > a fashion. But the programmability of that text terminal > is an accident of history, its feature set long since made > obsolete -- not useless, but out-moded -- by graphical > displays and GUIs. That he reached for that particular > tool is a measure of how far we have come, and how far > we have not. Well said! (Although I have to disagree about the word "obsolete", which implies that better alternatives exist *and are available for use*. In this case, they were not. Should they have been? Because there's an urgent need for them, or just because it's technically possible? Does such a need actually exist? Do other issues have a higher priority?)
