On Tue, Nov 9, 2010 at 16:09, Robert Bonomi <bon...@mail.r-bonomi.com> wrote: > A GUI provids a _fixed_ set of predefined operations that it is possible to > perform. > > IF your needs are met =entirely= by the provided operations, great. If not, > you're dead in the water, without any way to accomplish the task.
How is this different from the command line? If I have a set of data and want to sort it in a way that "sort" doesn't have an argument for, I'm just as dead in the water as with the GUI. In fact, with the GUI I am probably better off because I can see that this is not supported within the program, without having to use the documentation. > > GUIs are great for the casual user, because they provide a consistent > 'look&feel' > acrross the spectrum of apps available under them, and, _generally_ what you > learn from using one application 'generalizes' to any other app that runs > under > the same GUI. > > OTOH, a GUI is the worst thing in the world for 'production' use. It > absolutely > _kills_ productivity for production tasks. Automation for productivity > _REQUIRES_ > a complete/comprehensive command language. > > With a command language, you can 'automate' a series of operations by simply > listing the commands in a file, and feeding that file to the command-processor > input. > > With a GUI there is no way to describe the series of mouse 'motions'/'clicks'/ > 'double-clicks'/'drags' and keypresses required to perform an operation. > 'screen coordinates' are meaningless when a window, or icon, or button, may be > 'repositioned' at will. > > An _individual_ application may allow scripting via an internal command > language, > but since it is internal to the app, and *not* part of the GUI, it doesn't > 'generalize' (no guarantee that similar capability is present in any other > app) > *AND* is utterly worthless for 'automating' annything that involves more than > the single app. The CLI doesn't generalize either. How many ways are there to get input into a program? Some can open files on their own and the file is listed as an argument (app input) Some have a flag for input, which of course isn't consistent (app -in input) Some have multiple flags for input, but which ones work depends on the platform/implementation (such as GNU long flags) Some need it provided to stdin Some can process multiple types of input and are smart enough to figure it out on their own while others need to be told what format they are being given Some can do multiple unrelated things in one instance (file a b) while others can't (date +"%H" +"%M") Some have historic idiosyncrasies, such as tar defaulting to a tape drive Some have other strangeness, like java using aaa.class as input but wanting you to list it without the .class extension, whilst javac needs the .java extension Some are just unusual for no obvious reason, like dd's xx=yy thing etc. On the other hand, 99% of GUI apps that handle files have a File > Open dialog that is provided via a toolkit and works the same everywhere. > > Years ago, I worked at a place that, among other things, produced a reference > manual of statistical data for our cusotmers. About 800 pages of tabular > data, > practically all of it updated on a staggered, monthly basis. In the 'early' > days (MS-DOS vintage, before 'windows'), each table was kept in a separate > spreadsheet, which _did_ require the redundant entry of a _small_ amount of > the data. OTOH two (or more) differnt people could be updatdin different paes > simultaneously, regardless of whether or not they were 'related'. And, at > the end of the week, when it was time to send out the weeks 'updates' to the > customers, we had a simple little '.BAT file, each line of which; (a) invoked > the spreadsheet (b) specified the spreadsheet file to use, and (c) invoked > a 'start-up macro' that printed the contents of the spreadseet, and exited > the program. Thus, on 'publication' day it was just type in the name of the > '.BAT file and everthing got printed. It took an hour or two -- of > _machine_time_ > that is, but _zero_ human intervention. > > Fast forward a few years, a new-hire analyist (in a senior capacity) felt > humiliated at having to use this 'old' technology (they had Windows at his > prior employer), and made a big enough stink about it that the shop upgraded > to Windows just to keep him happy. He proceeds to bundle all 'his' > spreadsheets > into a single workbook, so that only one person can be working on any of them > at any given time, and, on 'publication day', somebody had to sit there and > click on each relevant/changed sheet in the workbook, click on' file', click > on print, select the page to print, and click 'doit'. What a *wonderful* > productivity increase!! We've now got a system that requires a -human- to > play babysitttr the machine. For a couple of -hours- every week. all to save > the complainer from having to enter a few numbers redundantly. This isn't really a GUI problem, because the issue is the file format changing such that your .bat no longer worked. If you retained the original format or fixed the script, it would still work fine. However, it still points out one of the biggest problems with the CLI - there is a barrier to entry in knowing what commands to run with what arguments to make everything work the way you want. File > Print was easy for your office staff to figure out. The CLI equivalent apparently wasn't. I think many here are underestimating the value of GUIs, because they have been running many of these traditional UNIX commands for years (or decades) and are also technically oriented enough that learning them in the first place wasn't a big deal. -- Rob Farmer _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
