Re: Should the Command Line Be Deep-Sixed?



In article <i9cqda$bdb$1@xxxxxxxxxxxxxxxxx>,
Keith F. Lynch <kfl@xxxxxxxxxxxxxx> wrote:
D. Glenn Arthur Jr. <dglenn@xxxxxxxxx> wrote:
... which is something I do a lot of as well (because *cough* a CLI
and a bunch of the standard Unix tools make it so very easy to do
that -- you're saying at least as much about the power of _your_
(my) CLI in particular, as about the usefulness of CLIs in general
... which in turn just makes it a stronger argument in favour of
_good_ CLIs).

True. There are certainly bad CLIs. For instance NOS/BE. The
question is whether there are good GUIs.

I'd say there are ... with the caveat that you still have to not
expect them to do the things that GUIs are inherently unsuited to.
But yeah, there are good GUIs. And bad ones.

I find the GUI for GIMP (and back when I last saw Photoshop,
lo these many versions ago, for that as well) pretty darned
good -- though it _does_ require spending some time _learning_
it for it to start feeling non-trivially useful. (Just as
most CLIs do.)

The UI for Audacity, I don't like quite as much, but it's
reasonable.

Opera, Safari, and Firefox have good UIs (especially with a
two-button mouse), though they don't have to do anywhere near
as much as Audacity or GIMP do. I've not spent enough time
with Chrome to say one way or t'other, and while there are
aspects of iCab that I like, its UI isn't as smooth as the
first three browsers I mentioned.

I find the Mac OS GUI to be very good, though I'm really glad
I don't have to try to do everything in it: it's great for
managing the apps I have running, including all those Terminal
(CLI) windows I tend to have open, and for _most_common_ cases
of "I need to tell the OS I want to do such-and-such to these
files". Of course, I consider it a good GUI because it does
_what_GUIs_are_good_for_ well, and I don't expect it to do
any _more_ than that -- I dunno, you might consider that to
disqualify it from the category of "good GUIs". (I did seriously
miss having a CLI under Classic MacOS, and was glad that the
shift to OS X meant getting a Unix shell. Well, a selection
of Unix shells. (I'd have been less happy if they'd only
supplied one, 'cause it probably would've been either bash or
ksh, and I like csh/tcsh.))

Watching my mother use it, I get the impression that the UI
for the Mac's Mail app might be a good GUI as well, but email
is one of the things that I am personally MUCH, MUCH more
comfortable deealing with using familiar CLI tools, so I'd
be the wrong person to judge it.

There may be GUIs that are
good at doing tasks that inherently involve selecting one of a small
number of images or icons, or zooming in on a particular point on a
map or the Mandelbrot set. But I've never heard of any GUIs that are
any good for tasks that involve relationships between ideas, i.e. that
require anything like grammar or syntax.

I suppose one could imagine using arrows to graphically link together
boxes, like in a flowchart or a circuit diagram. But I've never heard
of that being done as a substitute for a CLI. I have heard of it
being done as a way to design circuits or write flow charts for use
elsewhere, but not as a way to control the computer you're doing it on.

I've seen that done well for a DBMS, and I've seen it done badly.
In both cases, the GUI did try to handle a fair amount of complexity.

The first was some DBMS for Mac OS 7.mumble that advertised its ease
of use because you could do everything via the GUI and never write
a line of code. It was true that everything _that_application_
could do was done by dragging boxes around the screen and drawing
arrows between them, but for an RDBMS, the package was awfully
limited. It was good for really simple databases, but not for
anything complicated enough that ... well, that you'd want to hire
a programer for in the first place. I, my employer, and our client
rejected it.

The second was an RDBMS called 4th Dimension. I think it's still
around, but all I know about it is from version 1.something, back
some twenty years and gosknowshowmanyversions ago. It too was, at
that time, an old-MacOS application (I do know they later produced
a Windows version).

In old 4th Dimension, you created your tables and drew your relations
through the GUI, and even created most ordinary queries and reports
that way. Even some triggered events, IIRC. And the GUI was _good_:
it really did make doing those things much quicker (and I dare say
a smidgen easier), even for an old-school BASIC / ForTran / Pascal /
C / COBOL / dBaseII / dBaseIII / csh / Z80 / VAX / SPL programmer
like me! (I didn't know SQL yet at the time. Even knowing SQL,
I'd rather draw up my tables and relations in 4D, and do my queries
in SQL. From using it, I'm inclined to say there's a good reason
that 'Q' is in the name of SQL.)

But here's the important bit, which made 4th Dimension able to
leverage that good-for-what-GUIs-can-do GUI and provide a tool
for building pretty much any damned database application you might
dream up: as soon as you hit the conceptual limits of the GUI,
you ran into the procedural programming language they'd stapled
onto the back of each of those GUI objects! And at that point,
you were doing most of the tedious, PITA, setup and UI stuff in
a GUI that made them quick & easy, and everything that you were
going to think of in procedural terms anyhow in a procedural
language. (Event-driven, but still familiarly imperative-language
shaped.)

Now, technically, it didn't have a CLI: you never "drove" 4D
using a command line ... but it still depended on a "program it
in words, not pictures" aspect to provide the real _power_
lurking behind all that ease-of-use. So if we're talking
specifically about _CLI_ versus GUI, hey, it didn't have a CLI,
but if, as I've been thinking about this, what we really mean
is _verbal_ versus graphical, then 4th Dimension was (maybe still
is for all I know) a great product -- a great tool -- because
it combined in a natural-feeling way the greatest strengths of
a GUI _and_ the greatest strengths of a verbal programming
paradigm. (And I think they even added SQL to it eventually.)


Earlier, I've pointed out that I like to use a GUI for
GUI-friendly tasks, a CLI for CLI-friendly tasks, and
whichever I'm closest to for tasks that can be done either
way. I'd completely forgotten about my experience with
4th Dimension, where I was using a GUI and a verbal interface
simultaneously for different aspects of the same task.


Anywho, OT1H what you're describing can be done without all those
Unix commands and a shell, just _differently_;

Sure, in the sense that you could, as you suggest, use a DBMS. Or
would write a C program to do it. If you make the C program general
enough, you will have reinvented the CLI.

What's that famous saying, something like, "any sufficiently
powerful user interface eventually contains a LISP interpreter"?

Exactly. And languages are not intuitive. They have to be learned.
This takes time and effort. Until learned, they look like gibberish,
and this is scary to some people.

Or they look just close enough to "natural language" to fool
a newcomer into thinking they don't need to learn 'em ...

GUIs offered the false promise that no learning was necessary.

.... as several "so easy you won't need to hire a programmer"
languages have done. (Gosh, it turns out that you don't hire
a programmer for her familiarity with a particular language;
you hire a programmer for her ability to think like a
programmer in whatever language she's going to wind up using.)

Note that these days, a great many non-programmers are able to
use computers. And many of them in fact only do stuff that it
turns out GUIs can handle. My brother can't do half of what I
can do on a Linux box ... but until he _wants_ to be able to
do at least half of what I can do, he doesn't need to get around
to learning any of the shells installed on his Ubuntu netbook.
I would not be entirely satisfied with any GUI; he is. So's my
Mom. I'm glad his netbook and Mom's iMac have CLIs there for
me to use when they want me to fix something or add something
(*cough* or when I simply borrow Mom's iMac with its huge, pretty
screen), but as users, they can forget the CLI is even there.
The GUI is suitable for what _they_ need to do.

think by now everyone realizes that that promise was false, and GUIs
require learning. So the question is how much learning for how much
power.

*nod* Mom did need to spend some time learning how to drive
her Mac. A whole lot less time than she thought she would,
thanks to years of using Windows (same for my brother and Linux),
but yeah, sure, it required a small amount of learning.

_For_many_people_ (I'm _not_ going to even guess at percentages,
or whether it's "most" or "a small fraction" or "about half"; just
that it's a large number of souls), learning the underlying metaphor
and idiomatic organization of a GUI descended from the Xerox Star
well enough to _get_them_started_ using their computer, is easier
and -- perhaps more importantly -- faster than learning a command
language well enough to recall the verbs when needed and have the
grammar feel natural. If someone is wired like that _and_ is
mostly going to use the computer for GUI-friendly tasks, then it
makes a great deal of sense to give them an OS with a GUI. And
that's a lot of people.

For the other side of the argument, well there are some rather
important "if"s in the preceding paragraph. CLIs are too useful
to even consider doing away with.

Note that before OS GUIs became commonplace, the kinds of users
who now stick to the GUI (and should), used to learn just a few
"incantations" in their computer's command language, which many
of them never actually tried to _understand_ -- if they wanted
to do something new, or just a little bit different from what
they had a recipe for, they didn't use the "it's a language"
power of the CLI to figure out what commands to use, but asked
their on-call expert to provide them a new incantation for the
new task, and carefully stuck it on a Post-It note. That class
of users did not benefit from The Power Of The CLI -- the power
was there for anyone interested enough to invest the effort in
learning it, but for the "cookbook/spellbook" type of user,
that power remained untapped. They can do as much with a GUI,
and for the things they need to do, a GUI is frequently (no,
not always, but often) easier for them to learn the basic
metaphor of, than memorizing a set of gibberish-to-them incantations.

We can debate as much as we like whether we think those
users _ought_to_ want more power than that and spend the time
learning more powerful tools, but our opinion isn't much going
to change whether they _do_ want it badly enough to spend the
time learning it. I'll be happy if people learn enough about
how things work not to break stuff or inconvenience me. It'd
be convenient for me if I could communicate tech answers to
tech questions in geekspeak, but I'll settle for just having
them not send text documents as hundred-megabyte Jpeg page
images, y'know?

--
D. Glenn Arthur Jr./The Human Vibrator, dglenn@xxxxxxxxx
Due to hand/wrist problems my newsreading time varies so I may miss followups.
"Being a _man_ means knowing that one has a choice not to act like a 'man'."
http://www.dglenn.org/ http://dglenn.dreamwidth.org
.



Relevant Pages

  • Re: GUI vs: CLI (was: Shell command in VB6)
    ... > this aspect of cli apps, but it does not apply to me" ?). ... between GUI and CLI is actually fairly slight. ... how many of us programmers would ...
    (comp.programming)
  • Re: system-config-users 1.2.39 broken?
    ... I can do this in CLI in seconds. ... >> directory to another is a simple command in the CLI. ... In the GUI it ... > scanning the content with my eyes, and adjusting what I want where I ...
    (Fedora)
  • Re: CLI vs. GUI (WAS: Re: [opensuse] Mount windoze shares)
    ... The fact that one MUST use the CLI for some things on a modern OS ... Were I able to open a nice GUI and click a few options, ... To converse we use language which has grammar (syntax ... designs that confuse. ...
    (SuSE)
  • Re: RTFM
    ... In other words, you would use a program with a graphical interface, most ... > is missing on the minority of the computers, ... CLI, although I will assume that it's possible. ... But that really has little to do with CLI vs. GUI, ...
    (comp.os.linux.misc)
  • Re: RTFM
    ... In other words, you would use a program with a graphical interface, most ... > is missing on the minority of the computers, ... CLI, although I will assume that it's possible. ... But that really has little to do with CLI vs. GUI, ...
    (alt.os.linux)