On Wednesday 19 December 2001 15:24, Stuart D. Gathman wrote: [snip] > > GUIs are nice. Their benefit lies in making the abstract appear > concrete - visible and audible in todays technology, more in > tomorrows technology. > > However, GUIs have a serious drawback. They require a warm body to > operate them. All too often, I struggle with anger because some > utility is available in a GUI interface only. This means some poor > soul has to sit in front of a screen somewhere and click a mouse > and/or keyboard until the task is done, when they could be home > with their family. Countless hours are wasted with GUI chores that > could be automated if only a command line or other programmatic > interface was provided.
More than likely you encountered a GUI app written by a command line coder. Not too intutive and not mindful of standard mouseing rules. BTW, doesn't your 'warm body' operate the keyboard on the command line as you type in the utility name and parameters? :) I understand what you are saying, though.... gui-less utilities allow unattended batch processing, for example. I use that approach all the time. But, to my users, it is just another app activated by clicking a mouse. They don't write the scripts nor do they care about the utility. The job is what counts. For example, to replace Win98E running the Wildcat BBS, I wrote one bash script, one page long, and two python scripts, also one page each. The bash script is what is executed when the user logs into their account. and it restricts their activity to three tasks, or logging out. The two python scripts automate two repetative manual processes that the BBS admin does. Both python scripts are accessed via desktop icons that the BBS admin clicks on. Both scripts could have been coded as exposed methods of some resident object supplyling services and also triggered by a desktop gui, but the required processing and data movement was cut and dried. Sound familiar? I've been using commandline utilities since 1978. The biggest objection is that there are so many, they are obscure, and each have their own set of switches (parameters), and none are standardized as to what switches do what, except that either -h, --h, -help or --help calls up some form of help. Frankly, as I got older, I got tired of trying to remember parameters, switches, etc..., and inevitably one loses the manual, if there ever was one, that explains them all. When I got into Linux four years ago the most popular coding tool was emacs, or xemacs. I got O'Rilley's book and after a couple of chapters grasped the number of pluggins and switches that are associated with each one. I realized that, having only 5 to 10 activing coding years remaining ahead of me, there isn't enough time in life to endure such nonsense. GUI apps are standardized far better than commandline apps are, and the well designed ones are intuitive. The general user can move from app to app and never have to consult a manual on mouse clicks. Coders writing GUI apps who short-circuit this design principal are shooting their apps and themselves in the foot. A commandline app is never intuttive, unless you were the coder that wrote it. > > Microsoft's solution to this problem is a programmatic interface. > Good Windows programs include a DDE or COM interface which is > automatically available to Windows aware scripting languages. > (This is where the Windows term "automation" came from as in "OLE > automation".) The common unix solution to this problem is to > provide a command line interface to the program. The command line is not like Dynamic Data Exchange or Object Linking and Embedding, later expanded to become ActiveX, etc.... A script composing a shell program, ... maybe. Scripts are not event driven like GUI interfaces are. Part of the 'dynamic' is the user, for example, seeing clues in the data returned from, say, a remote server, that causes him to mouse a particular GUI control that triggers a particular event, out of many, causing the data to be moved, processed, returned, destroyed or what ever. Such dynamic interaction is not possible with commandline utilities unless the 'warm body' types commands that pipe data to files or does a screen capture, etc... Object linking was created to allow an object to reuse code present in exposed methods of other objects. GUI interfaces, of course, are not procedural, because the coder usually doesn't know in advance in what order events will be triggered, except in certain limited ways. > > Command line utilities are not valuable because they are "friendly" > to the casual user (they aren't). They are valuable because they > are easily integrated with other programs in a way that does not > require user intervention. That they are not 'friendly' is why they are dying, no matter how useful they've been in the past. When it was only academics and geeks using them, and they were the only game in town, there was no other choice. The number of people who are impressed by geek knowledge of utility apps and their parameters is rapidly dwindling. > > How does this relate to Sword? Well, Sword is currently available > to C++ programs. There should be alternate interfaces for other > tools. A simple command line tool to quote a verse by reference or > output a concordance like list of references given a search key > would be handy for a scripted web page or editor macros. A C > interface would be more easily wrapped for script languages like > Python or Perl. A command line tool would also let you search the > Scriptures on a 4Mb 386 in console mode (although an ncurses > frontend would be nicer for that). Diatheke does that. A curses version by Richard Holcombe also exists, but it has had less than 100 downloads in the last 9 months, which probably explains why Richard isn't too active right now. The last work was on 0.16 on 2-17-2001. I've noticed a lot of older geeks talk about the 4MB 386 as if there were a huge, unexploited market for software that would run on them. There isn't. If those boxes haven't been run the dialectrics in their capacitors have begun to or have dried out. If they are being run then their component MTBF limits have been passed and they are in need of constant repair from a pool of parts that are drying up. No one makes 386 stuff anymore. Few people write for it. Even third world countries won't settle for them. Would you be happy with a model T when everyone else is driving a 2001 Saturn? Even my brother, Dennis Malepi, in Botswanna is using Pentiums and acquiring them for the Christian school he is building there. That BBS box I told you about is a P200 with 64MB of RAM and two 1GB HDs, running SuSE 6.4. It replaced a P450 with 128MB running Wildcat because the higher ups didn't think Linux could do the job and they didn't want to waste a 'good' box on what they considered an experiment. That was 16 monhts and ZERO crashes ago. The WinXX 'solution' averaged a couple of crashes a day and couldn't be left on overnight to allow after hours downloads from electronic taxpayers. The clerk that runs it says it is easier to use than the WinXX setup and KDE1 is just as easy to use as WinXX. She says the P200 solution runs about twice as fast as the WinXX solution. Finally, if folks had to install Linux distros the way they did when Slackware first came out...... Only the GUI install programs are giving Linux a fighting chance in the desktop arena. GUI apps are rapidly taking over sever control too. With will designed GUI apps users do not have to give up power, either. The reign of the command line has come to an end.
