command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Peter T. Breuer on 18 Nov 2005 12:38 In comp.os.linux.misc notbob <notbob(a)nothome.com> wrote: > ["Followup-To:" header set to comp.os.linux.misc.] >> Grr .. I'll volunteer one: writing html. > ????? > Not sure what you mean, "writing" html. Well, you have two choices as to what to do with html: read it, or write it. When you eliminate one of those two, you should be on track. > Why would a gui be that much > better than a cli editor? Well, OK, let's see you take 5 images and put them on 5 distinct pages (with separate caption) all accessible from a single "contents" page, which contains a navigation bar at top and a commentary at left. One of the images should have 6 aligned equations under it, arranged in two groups of three. By the time you're three deep in framesets and 5 deep in tables, you should understand the problem. > I would agree for a wysiwyg gui like Dreamweaver, but for writing? That sentence no parse. Dreamweaver is a website maintenance tool, I've been told. Writing is what Dreamweaver does as a sideline, I expect. > I, myself, use quanta, a gui based writer (not wysiwyg), If it ain't wysiwyg then it's as useless for the task as the Bluefish I just had a look at. > I use it because I'm not very experienced at html and Yo - well, I am experienced enough to have taught (and forgotten) more than I would want to know about html. And I have as much intention of writing html by hand as I have of writing a applicative higher order program in assembler. Having just spent two days writing the html I described, by hand, in vim, I don't want to do that again. I am going to have to recompile mozilla with an editor that doesn't bazoink. > nb Peter
From: blmblm@myrealbox.com on 18 Nov 2005 12:40 In article <m2u0eax8w9.fsf(a)hugin.crs4.it>, Jacob Sparre Andersen <sparre(a)nbi.dk> wrote: >Reinder Verlinde wrote: [ snip ] >> I doubt one could design a shell for non-programmers that suited >> them better than a GUI. > >Having seen travel agents working in their shell, and having tried to >use the GUI's made available by the airlines on the web, I disagree >with that. I think what matters isn't programmers/non-programmers, as >much as how often you have to use the interface. It may though be >that programmers have lower patience with the UI's interfaces, and >thus are quicker to adopt the shell - especially if it actually is >scriptable and not just a TUI. Another way to say this (maybe -- or at least it's a point I'd make) is that GUIs tend to be novice-friendly, while CLIs tend to be expert-friendly. The travel agents might not be happy using a CLI to browse the Web at home, but my guess is that they regard that "shell" they use at work as worth the time it took to learn to use it. I strongly suspect that there are similar examples in other professions/jobs. Programmers might be somewhat more likely that other people to perceive the benefit of investing time in learning to use an expert-friendly tool, even if it's not very novice-friendly? [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Peter T. Breuer on 18 Nov 2005 12:40 In comp.os.linux.misc blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: > In article <o4d153-rna.ln1(a)news.it.uc3m.es> [ptb wrote], >>> line. I did say that GUIs are good for some purposes. Can you give >>> an example of a GUI you think is "state of the art" (whatever that >>> means)? >> >>Grr .. I'll volunteer one: writing html. > Say what? "Writing HTML" is a task/job, not a UI, no? I mean it's an example of a purpose for which GUIs are well suited, which I thought he was trying to ask. Peter
From: blmblm@myrealbox.com on 18 Nov 2005 13:25 In article <k8g153-rsl.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: >> In article <o4d153-rna.ln1(a)news.it.uc3m.es> [ptb wrote], >>>> line. I did say that GUIs are good for some purposes. Can you give >>>> an example of a GUI you think is "state of the art" (whatever that >>>> means)? >>> >>>Grr .. I'll volunteer one: writing html. > >> Say what? "Writing HTML" is a task/job, not a UI, no? > >I mean it's an example of a purpose for which GUIs are well suited, >which I thought he was trying to ask. s/he/you/ No, I was asking, in response to the previous poster's comment about not assuming that the stuff put out by Microsoft is "state of the art", for an example of a "state of the art" GUI. I'm not sure anyone but the person I was responding to can really answer that, but anyone who wants to tell me about a program whose GUI is much, much better than run-of-the-mill .... sure, that would be interesting. Someone mentioned something from Apple that's scriptable, for example. (vim/CLI fanatic that I am, I actually usually write HTML with vim. Either that or I write LaTeX source -- with vim -- and run it through latex2html. :-) Tables are a pain, true, but this approach works well enough for simple HTML, which is generally what I want to produce anyway.) -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Robert Heller on 18 Nov 2005 16:34
blmblm(a)myrealbox.com (blmblm(a)myrealbox.com), In a message on 17 Nov 2005 20:04:00 GMT, wrote : b> It's not the internals that would be hidden -- I like and use the b> "find" command, but I have no particular interest in knowing the b> details of how it turns those admittedly cryptic parameters into b> the desired output. What might be hidden, or at least made more b> difficult to use, is the full range of options. The input that b> controls what files are found can be almost arbitrarily complex, b> and building up arbitrarily complex expressions doesn't seem like b> a task for which a GUI is well suited. (I could be wrong about that, b> though.) It is possible to write a fully featured GUI front end for find. Whether it would be "well suited" is a subjective measure. Part of the problem happens when you want to use the output of find for something more than just displaying it. Then you have to deal (somehow) with the zillions of possible command strings that might follow after the find command. It is like writing a natural language paragraph. Yes, you could create a GUI with drop down menus of all possible successor words, given some word, but would that GUI be really useful or 'well suited' for say, an author? Probably not. *Any* author would be better off with a plain old keyboard. \/ Robert Heller ||InterNet: heller(a)deepsoft.com http://www.deepsoft.com/ ||FidoNet: 1:321/153 http://www.deepsoft.com/~heller /\ |