command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: ynotssor on 17 Nov 2005 01:46 <news(a)absamail.co.za> wrote in message news:M4ydnR00v5Qwv-HeRVn-hA(a)is.co.za > If I'm doing an important/fascinating pencil & paper drawing, > [computing task] I don't want to be distracted by the details > to pencil-sharpening [the 'find' comand sysntax]. Any artist is so intimately involved with the tools of their expression that the pencil shaping ("sharpening" is for writers) is an important, loving component of same. Ones "computing task" will be as limited by the GUI programmer as ones own refusal to learn the find syntax.
From: Alan Connor on 17 Nov 2005 01:54 On comp.os.linux.misc, in <M4ydnR00v5Qwv-HeRVn-hA(a)is.co.za>, "news(a)absamail.co.za" wrote: <body not downloaded> This posts says Re: on the Subject line but has no References: header. Add that to the fact that they don't have a name in their From header and I think I'll just leave the article on the server, and the same for any responses to it. +++++++++++++++++++++++++++++++++++++++++++++++++ + + + TROLLS: Ignorant, motor-mouthed, and cowardly + + punks (often mentally ill) that run around + + the Usenet posting (usually abusive) garbage + + under multiple aliases. Usenet vermin. + + + + + +++++++++++++++++++++++++++++++++++++++++++++++++ AC -- http://home.earthlink.net/~alanconnor/contact.html URLs of possible interest in my headers. ~ ~
From: Guy Macon on 17 Nov 2005 03:03 news(a)absamail.co.za wrote: > >Chris F.A. Johnson wrote: > >>silicono2(a)yahoo.com wrote: >> >>Can we get the best of both worlds with an interface using >>charts/fields of text? >> >>There have been other attempts to do this, but there are good >>reasons they didn't catch on. >> >What are those "good reasons" ?! Look here: http://www.spack.org/wiki/InTheBeginningWasTheCommandLine
From: Lee Sau Dan on 17 Nov 2005 10:35 >>>>> "silicono2" == silicono2 <silicono2(a)yahoo.com> writes: silicono2> I've had a Unix-using acquaintance tell me that he much silicono2> preferred command lines over GUI, even when using silicono2> Windows. Well... yes, when you give me a bash under Cygwin. No No No when you give me the dumb COMMAND.COM or CMD.EXE. silicono2> For all the advantages of GUI I agree that it's much silicono2> easier to issue a series of commands in a command line silicono2> or do something like "copy *.* a:" as well. Can we get silicono2> the best of both worlds with an interface using silicono2> charts/fields of text? The only example I can think of silicono2> is BIOS config (also DOSshell a while ago), obviously silicono2> it hasn't caught on. There used to be such things on the PC. PCTools R5.1 was one of my favourites. This file manager is a TUI (text user interface), where you can do many things my a single keypress. It lists the files in a directory, and highlights one of them at any time. Press the hot key for delete, and it deletes that file. If you want to delete multiple files, you can first TAG (or MARK) those lines, and then press the hot key for delete to delete them all at once --- much easier and faster to operate than those confusing Shift-click or Ctrl-click. And there was Borland's text-based IDE for Turbo C/C++, Turbo Pascal, Turbo Prolog, etc. etc. etc. etc. Even nowadays, there are many, on Linux. Emacs's dir-ed resembles PCTools 5.1 in the mode of operation, but just more powerful and flexible. (e.g. it's allows different types of MARKS to exist a once, with some operations operating only on certain marks.) Emacs's Gnus news reader is also a very efficient TUI. And Emacs's PCL-CVS as well as psvn packages provide TUI frontends to CVS and SVN, repectively. Outside Emacs, there is 'aptitude' -- a TUI frontend for Debian's apt utility. If I remember correctly, Pine also has a menu-based TUI. silicono2> Of course you can argue that a fields/charts interface silicono2> is in fact a GUI, with "true" graphics simply replaced silicono2> by ASCII graphics? Then main difference of the CLI from TUI/GUI is that CLI accepts "sentences" conforming to certain grammar rules. The grammar is usually relatively (w.r.t. human languages) simple. But the vocabulary is very rich. This gives the richness of CLI's. That the grammar is recursive also generates lots of possibilities. TUI is much weaker in expressiveness. The vocabulary is only the set of keys available on the keyboard. (Of course, you can extend it using multi-keypress sequences.) This is more limited, but still suitable for a restricted number of tasks. And it is still pretty productive. A drawback is that the semantics of this vocabulary varies from context (screen) to context. Key "j" in this screen can perform a very different operation than key "j" in the next screen. (A good and consistent design should avoid this, like those in Emacs. But given the limited vocabulary, this is not an easy task.) GUI? The vocabulary is even smaller: point and click (and double-click, drag). So, this vocabulary is even more context-dependent than TUI, and is even harder to get it consistent. If you click the mouse button 1 pixel off the desired GUI buttons, you may be performing a very different operation. This is very difficult to learn and use efficiently. Of course, the above are about the expressive power of the input (from human to computer). In terms of output expressiveness, GUI is richer and more compact (when done appropriate -- which is seldom the case nowadays) than TUI, which is in turn richer and more compact than CLI. But CLI has its power by harnessing the fruits of the shell text utils -- making automation easier to program. So, all in all, I think CLI is the best, if you want power and you want to shift the tedious and repetitive work to the computer, leaving yourself more time for interesting matters. -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee
From: Lee Sau Dan on 17 Nov 2005 10:41
>>>>> "Chris" == Chris F A Johnson <cfajohnson(a)gmail.com> writes: Chris> In order to be a viable alternative to the command line, Chris> a menu system would have to be huge and unwieldly. Imagine Chris> writing a front-end to a command such as find without Chris> emasculating it. It's not hard to come up with a front-end to 'find'. e.g. Command: [find ] Arg 1: [/home/foo ] Arg 2: [-name ] Arg 3: [*.txt ] [Add More Args] [Go] But I bet you'll prefer the CLI to such a GUI, won't you? Designing a *usable* GUI for 'find' without castrating the power and expressiveness of it IS a big challenge. Similarly, a GUI for clicking up a C program, instead of an editor for typing in the C program, would be either more difficult and inefficient to use than an editor, or be very restrictive (such as giving you a menu of 100 most frequently wanted C programs, which are hard-coded into the GUI). -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee |