Discussion:
Command line VS GUI, redux
(too old to reply)
mlw
2005-11-18 02:42:28 UTC
Permalink
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much all
depend on GUI programs. Just because GUIs are largely "the" way to
accomplish most basic tasks, there exists task, IMHO, that are more suited
for GUI.

I've had conversations with users, and they want a CLI. They don't know it,
but I've heard things like "how can I just tell it what I want to do?" "Why
can't I just tell it to pop out the CD?" "Why can't I say 'record at
5:00'?"

The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.

A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex ones,
much easier.

The question is: How to we incorporate a linguistic interface in a way that
the user will be inclined to use it?
George Ellison
2005-11-18 02:55:07 UTC
Permalink
Post by mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much all
depend on GUI programs. Just because GUIs are largely "the" way to
accomplish most basic tasks, there exists task, IMHO, that are more suited
for GUI.
I've had conversations with users, and they want a CLI. They don't know it,
but I've heard things like "how can I just tell it what I want to do?" "Why
can't I just tell it to pop out the CD?" "Why can't I say 'record at
5:00'?"
The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex ones,
much easier.
The question is: How to we incorporate a linguistic interface in a way that
the user will be inclined to use it?
Hmmm, you know, I've only been using Linux for a few months myself, and
I started out with Xandros, which is probably one of the most GUI-ified
distros out there. I was all pointy-clicky for all of two days until I
bothered to try out the terminal. (I used a Unix shell account at a
local ISP a few years back, so I had minimal knowledge of how to get
around. Any old MS-DOS hand could probably find his way around bash
fairly easily). Since then, I've been hooked. I love KDE and xfce,
and can even tolerate GNOME for short periods of time, but I tend to
do more and more from the console, simply because it's faster and more
efficient. Burning ISO images to try out a new LiveCD can be a mess with
K3B, whereas it's a single command job with cdrecord. I'm not the best
when it comes to things like piping or I/O redirection, but the command
line seems to offer more bang for the buck than most GUI's. No wonder MS
is trying to strengthen the CLI for Vista.
damon
2005-11-18 03:16:48 UTC
Permalink
Post by George Ellison
Post by mlw
I've had conversations with users, and they want a CLI. They don't know it,
but I've heard things like "how can I just tell it what I want to do?" "Why
can't I just tell it to pop out the CD?" "Why can't I say 'record at
5:00'?"
The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex ones,
much easier.
The question is: How to we incorporate a linguistic interface in a way that
the user will be inclined to use it?
I'm not the best
Post by George Ellison
when it comes to things like piping or I/O redirection, but the command
line seems to offer more bang for the buck than most GUI's.
And don't forget all the fine programs that are available on the command
line. I use good ol' ftp and ssh all the time. And trolling through
menus to find a program seems goofy when you can just type the name and
whack enter. mv, cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all
the time and hate it when I have to learn how to use a friend's GUI.

The learning curve is steep, but the cli is designed to be
expert-friendly, after all.

-- damon
tab
2005-11-18 03:25:10 UTC
Permalink
damn, another honest guy in COLA.
cli is awesome, if you are an expert.

i don't have to know commands.
I know where all the gui's are. :)
I just hope they are user friendly.
Lee Sau Dan
2005-11-18 15:35:14 UTC
Permalink
tab> damn, another honest guy in COLA. cli is awesome, if you are
tab> an expert.

tab> i don't have to know commands. I know where all the gui's
tab> are. :) I just hope they are user friendly.

What if your UI designers decided that in the next major release,
they'd re-organize the icons and menus, and replace your familiar
icons with "prettier and cutier" ones?

With a CLI, the commands seldom change name. (A name change can be
smoothed by using a symlink or alias from the old name to the new
one.) And it doesn't matter where the commands are located: the shell
does the searching (along PATH) for you. That means: knowledge of the
unix CLI remains useful for decades, like knowledge of a language.
--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: ***@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Linønut
2005-11-18 04:07:53 UTC
Permalink
Post by damon
And don't forget all the fine programs that are available on the command
line. I use good ol' ftp and ssh all the time. And trolling through
menus to find a program seems goofy when you can just type the name and
whack enter. mv, cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all
the time and hate it when I have to learn how to use a friend's GUI.
The learning curve is steep, but the cli is designed to be
expert-friendly, after all.
ooffice mydocument &
--
Treat yourself to the devices, applications, and services running on the
GNU/Linux® operating system!
Lee Sau Dan
2005-11-18 15:32:13 UTC
Permalink
damon> And don't forget all the fine programs that are available
damon> on the command line. I use good ol' ftp and ssh all the
damon> time. And trolling through menus to find a program seems
damon> goofy when you can just type the name and whack enter. mv,
damon> cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all the
damon> time and hate it when I have to learn how to use a friend's
damon> GUI.

A GUI can't let you set variables and refer to them later, like (bash):

$ X=/a/very/lengthy/path/to/some/directory
$ Y=/another/very/lengthy/path/to/some/file
$ echo so something ...
$ mv $Y $X

And the "~1", "~2" as well as "pushd" and "popd" in bash are so handy
that I have to hate the ksh, which I'm forced to use when working on
some proprietary unixes not administered by me. (If I were the sys
admin, I'd have compiled and installed bash and emacs at the first
instance!)

Does any GUI provide something even remotely comparable?


damon> The learning curve is steep, but the cli is designed to be
damon> expert-friendly, after all.

So, it's user-friendly, when user == expert.
--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: ***@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Larry Qualig
2005-11-18 16:29:13 UTC
Permalink
Post by Lee Sau Dan
damon> And don't forget all the fine programs that are available
damon> on the command line. I use good ol' ftp and ssh all the
damon> time. And trolling through menus to find a program seems
damon> goofy when you can just type the name and whack enter. mv,
damon> cp, ls, man, pwd, rm, wc, rsync, lpr... I use them all the
damon> time and hate it when I have to learn how to use a friend's
damon> GUI.
$ X=/a/very/lengthy/path/to/some/directory
$ Y=/another/very/lengthy/path/to/some/file
$ echo so something ...
$ mv $Y $X
And the "~1", "~2" as well as "pushd" and "popd" in bash are so handy
that I have to hate the ksh, which I'm forced to use when working on
some proprietary unixes not administered by me. (If I were the sys
admin, I'd have compiled and installed bash and emacs at the first
instance!)
Does any GUI provide something even remotely comparable?
damon> The learning curve is steep, but the cli is designed to be
damon> expert-friendly, after all.
So, it's user-friendly, when user == expert.
This is the primary issue. The CLI is a powerful interface for computer
'experts' but something needs to exist for the other 95% of computer
users. Not everyone studies computers or has the desire to learn
commands like ' export PATH="$(print -r $PATH | sed
's|$ENV_VAR|ENV_VAR|g')" '. Computers need to appeal to a broad number
of users including people like nurses, builders, realtors, etc. These
people *need* GUI tools.
TheLetterK
2005-11-18 06:12:10 UTC
Permalink
Post by George Ellison
Post by mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much all
depend on GUI programs. Just because GUIs are largely "the" way to
accomplish most basic tasks, there exists task, IMHO, that are more suited
for GUI.
I've had conversations with users, and they want a CLI. They don't know it,
but I've heard things like "how can I just tell it what I want to do?" "Why
can't I just tell it to pop out the CD?" "Why can't I say 'record at
5:00'?"
The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex ones,
much easier.
The question is: How to we incorporate a linguistic interface in a way that
the user will be inclined to use it?
Hmmm, you know, I've only been using Linux for a few months myself, and
I started out with Xandros, which is probably one of the most GUI-ified
distros out there. I was all pointy-clicky for all of two days until I
bothered to try out the terminal. (I used a Unix shell account at a
local ISP a few years back, so I had minimal knowledge of how to get
around. Any old MS-DOS hand could probably find his way around bash
fairly easily). Since then, I've been hooked. I love KDE and xfce,
and can even tolerate GNOME for short periods of time, but I tend to
do more and more from the console, simply because it's faster and more
efficient. Burning ISO images to try out a new LiveCD can be a mess with
K3B, whereas it's a single command job with cdrecord.
Just FYI, Nautilus has integrated CD burning. No need for an external
burn app, just right click on the disk image and click 'burn to disk'.
Post by George Ellison
I'm not the best
when it comes to things like piping or I/O redirection, but the command
line seems to offer more bang for the buck than most GUI's. No wonder MS
is trying to strengthen the CLI for Vista.
Ironically, Microsoft's attempts to strengthen their command line will
probably backfire. Most of thier problem here is that they have a
simplistic CLI with complex methods--they're replacing it with a highly
complex CLI with even more complex methods.
--
"There is nothing I understand." - Shit
Lee Sau Dan
2005-11-18 15:28:26 UTC
Permalink
George> (I used a Unix shell account at a local ISP a few years
George> back, so I had minimal knowledge of how to get around. Any
George> old MS-DOS hand could probably find his way around bash
George> fairly easily).

An old MS-DOS hand would be extremely amazed by the completion (which
works not only for file/directory names, but also shell variable
names!) and editable history list (navigatible with UP and DOWN
arrows) of bash, let alone the power of unix shells: pipes, job
control, etc. And they'll be surprised that the "*' wildcard really
works as it should be.


George> Since then, I've been hooked. I love KDE and xfce, and can
George> even tolerate GNOME for short periods of time, but I tend
George> to do more and more from the console, simply because it's
George> faster and more efficient.

That's why I always use "emacs&" to start Emacs, "xterm&" to start
xterm, and "firefox&" to start firefox. I have these things
configured in my FVWM menus, but seldom use such menus. Typing the
command is just so much quicker. And I don't have to look at the
screen to carefully aim at those tiny menu entries. Aiming with the
mouse is so tiring and slow.



George> Burning ISO images to try out a new LiveCD can be a mess
George> with K3B, whereas it's a single command job with cdrecord.
George> I'm not the best when it comes to things like piping or
George> I/O redirection, but the command line seems to offer more
George> bang for the buck than most GUI's. No wonder MS is trying
George> to strengthen the CLI for Vista.

DOS's COMMAND.COM and NT's CMD.EXE are simply ridiculous in comparison
with even Bourne shell.
--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: ***@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
DFS
2005-11-18 03:33:14 UTC
Permalink
Post by mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty
much all depend on GUI programs. Just because GUIs are largely "the"
way to accomplish most basic tasks, there exists task, IMHO, that are
more suited for GUI.
I've had conversations with users, and they want a CLI. They don't
know it, but I've heard things like "how can I just tell it what I
want to do?" "Why can't I just tell it to pop out the CD?" "Why can't
I say 'record at 5:00'?"
The issue is the complexity of tasks. With a GUI, you need to
complete a complex series of dialog box tasks, possibly save the
results, and then press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can
make complex tasks easier, and make repeated tasks, especially the
complex ones, much easier.
The question is: How to we incorporate a linguistic interface in a
way that the user will be inclined to use it?
Months ago Ghost mentioned a GUI interface that incrementally builds a
command. I took a look and found one that already does this. Can't find
the link just now, but you make point-click choices and it builds a command
string you can edit and execute.

In general I really really dislike the CLI, and I think most people do.
It's boring to look at, and tedious to use. It just feels slow and
unproductive and antiquated - whether it is or not. And it's worse on
Windows than on Linux.

But I noticed the more you use it the more comfortable you get with it,
pretty quickly too. If you can touch-type at a decent rate and know your
commands, you can be fairly efficient with it.

The *nix CLI is a powerful interface. Difficult but powerful. It's ultra
nice being able to pipe command outputs to files, or do that 'locate' thing,
or search for all packages with 'gnumeric' in the name, or schedule jobs
with a few commands, etc.

The CLI is hard to like and hard to learn, but not hard to appreciate.
Tim Smith
2005-11-18 05:21:25 UTC
Permalink
Post by DFS
Months ago Ghost mentioned a GUI interface that incrementally builds a
command. I took a look and found one that already does this. Can't find
the link just now, but you make point-click choices and it builds a command
string you can edit and execute.
Way back in the late '80s Apple had something like that, in the MPW
(Macintosh Programmer's Workbench) environment. They also had it in
A/UX for most Unix commands.

Suppose you wanted to do a "find" command, but wanted help with the
arguments. You'd do "find..." (The "..." is actually one character,
which you got by typing option-semicolon), and it would give you a
dialog for that command. It would have checkboxes and radio buttons for
options, file selection areas for specifying files, and so on. This was
in the era before tabbed dialogs were invented, but it had the
equivalent (for complex commands like find) in buttons that would take
you to other dialogs, so that the could organize options by functional
groups.

When you finished, it put the constructed command back into the terminal
window for you.
--
--Tim Smith
Edwards
2005-11-18 17:33:54 UTC
Permalink
Post by DFS
Post by mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty
much all depend on GUI programs. Just because GUIs are largely "the"
way to accomplish most basic tasks, there exists task, IMHO, that are
more suited for GUI.
I've had conversations with users, and they want a CLI. They don't
know it, but I've heard things like "how can I just tell it what I
want to do?" "Why can't I just tell it to pop out the CD?" "Why can't
I say 'record at 5:00'?"
The issue is the complexity of tasks. With a GUI, you need to
complete a complex series of dialog box tasks, possibly save the
results, and then press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can
make complex tasks easier, and make repeated tasks, especially the
complex ones, much easier.
The question is: How to we incorporate a linguistic interface in a
way that the user will be inclined to use it?
Months ago Ghost mentioned a GUI interface that incrementally builds a
command. I took a look and found one that already does this. Can't find
the link just now, but you make point-click choices and it builds a command
string you can edit and execute.
In general I really really dislike the CLI, and I think most people do.
It's boring to look at,
http://www.eterm.org
Post by DFS
and tedious to use.
Nonsense, clicking and dragging a bunch of file icons, or typing
a command to do something to a bunch of filenames -- it's the same
amount of tedium.
Post by DFS
It just feels slow and
unproductive and antiquated - whether it is or not. And it's worse on
Windows than on Linux.
But I noticed the more you use it the more comfortable you get with it,
pretty quickly too. If you can touch-type at a decent rate and know your
commands, you can be fairly efficient with it.
Tab completion, etc. All I can do is hunt & peck but with all the
bells and whistles of modern shells, it doesn't hold me back.
Post by DFS
The *nix CLI is a powerful interface. Difficult but powerful.
It's not difficult, because it's discoverable; if you need to figure
out how to do something in a CLI, the answers/explanation are right
there in the CLI (man, apropos, info, html help files, etc).

What's difficult is sitting down at an unfamiliar GUI and struggling
to remember or work out by trial and error its idiosyncracies for
accomplishing basic tasks. Every time my next door neighbor asks for
help with her Mac, I grit my teeth, knowing that very soon I'll be
struggling to do something that ought to be simple, but unable to
recall whether it's done by clicking while holding down the cloverleaf
key, or the shift key, or the control key, or the option key, or some
combination of the above. I end up doing things the slow way,
_knowing_ there's an easier way but that it won't be worth the effort
of finding it. Selecting a bunch of files to be moved to a different
folder, say; finally I figure out how to get it to select more than
one file at a time, but can't for the life of me recall the _second_
magic key sequence to let me drag all of those files at once -- every
time I click it selects the one file I've clicked on and desects all
the others. "Searing damnation, I just want to mv R*.doc
../some_other_dir/, you pestilent piece of garbage!" But she's eighty
or so and I can't very well refuse to at least try to help. :)
Post by DFS
It's ultra
nice being able to pipe command outputs to files, or do that 'locate' thing,
or search for all packages with 'gnumeric' in the name, or schedule jobs
with a few commands, etc.
The CLI is hard to like
I don't buy that. It _might_ be true that some folks like CLI better,
some exclusive GUI, and that few switch once they've picked. (I'm not
convinced of that but it's at least possible.) But all of us who
regularly use (and do indeed like) the CLI started from scratch at one
point. If it were hard to like noone at _all_ would use it.
Post by DFS
and hard to learn,
All the anecdotal evidence I've seen suggests otherwise; it takes
about as much effort to "master" a CLI as a typical GUI. Related to
my rant above, my impression is that a CLI rewards incremental
learning. You don't _have_ to master all of /usr/bin:/usr/local/bin
at once, you start by learning a few commands and gradually increase
your vocabulary.

With a GUI, on the other hand, there's a fairly large repertoire of
"gestures" one must learn right away in order to be able to use it at
_all_. Increasing that repertoire as time goes on requires
essentially rote memorization of new gestures that aren't necessarily
related to the previous ones in any syntactic or "deducible" way.
(Knowing that right clicking on a file in an explorer window gives you
access to its properties doesn't necessarily tell you anything about
what will happen if you right click on, say, the root desktop or the
toolbar.)

Compare the (in theory subtle and complex) concept of, say, pipes in a
CLI. Maybe a coworker showed you how to pipe the output of ls to grep
or something (e.g. so you can pick which images to send to an image
editing program). Then a few days later you accidentally or maybe
even on purpose connect a couple of different text i/o programs with a
pipe, or discover that there can be more than two programs in your
"chain" of pipes, and kablammo, you've opened a whole new world for
yourself. I firmly believe that's because the CLI is _generalizable_
in a way that a GUI can't be (because the former is loosely modeled on
the way language works, with _syntactic_ as well as semantic
relationships, while the latter is more like a collection of entities
which may carry semantic information but have simple and generally
unsystematic relationships).
Post by DFS
but not hard to appreciate.
Well, neither is a GUI; despite the above, I don't actually sit at a
VGA console all day, I use enlightnement and am very happy with it.
But the actual _things_ I am doing are generally happening in Eterms
and xemacs windows, plus programs like pdf and ps viewers (text-based,
but not really separable from their GUI, so what are they?). Someone
once quipped "Time is what keeps everything from happening at once," I
guess for me a window manager is what keeps all my terminals from
falling on top of each other. Obviously GUIs aren't going anywhere
anytime soon, and everyone needs to decide on their own how best to
get their own work done; but anyone who dismisses CLIs out of hand,
thinking they're "old" or "difficult" or whatnot, is missing something
important IMO.
--
Darrin
r***@usa.net
2005-11-18 06:17:13 UTC
Permalink
There were a few attempts to do this. In fact, the berkely "csh"
shell had the ability to create aliases which made it possible to make
simple aliases that could be used in place of the short commands.

the original K&R commands were very short because the terminal access
was through a 300 baud tty serial interface connected to a teletype. A
typo in the middle of a command was a real problem. You might have to
retype the whole command.

The irony is that as people got familiar with the commands, they really
LIKED the very short command names. But bash, ksh, and csh all support
aliases. Some popular ones include:

alias move mv
alias copy cp
alias list ls
alias more less
alias directory ls -l

and so on.
Many people would have 50 to 60 aliases which included simple "one
liner" scripts.

Of course, the other thing you can do is write scripts using the cli
shell of your choice. In addition, many applications can be scripted.
Most experienced users create a ~/bin directory (a bin directory in
their home directory) and then ad this directory to their main profile
path.

If you really want to be strange, you can create interesting names that
describe what a program does. For example backup_my_email

Linguistically, English is a terrible language to parse. For example,
a computer parser/translator translated english to russian and russian
back to english. When this computer was fed the phrase "the spirit is
willing but the flesh is weak" it was translated to "the wine is strong
but the meat is rotten".

There have been several attempts to create "plain english" programming
language such as pilot and cobol. Often these aren't much better. The
one good thing about a programming language like cobol is that the
actual program can be included in the legislative act, which eliminates
most of the ambiguity, and yet it still looks like a standard english
phrase.

Other attempts were even wierder. The FORTH program would let you put
the "nouns" on the stack, then have the "verbs" operate on the stack.
In fact, forth let you use any word you want, and assign any meaning
(program) to that word. The forth programs or words were then stored
in the "dictionary".

Linux environments also come with commands like "whatis", so you can
ask
whatis grep, and you'll get a basic description of grep. For a bit
more information, you can use the manual. K&R shorthand for this is
"man", but you can use an alias to make "manual grep" work too.

In addition, you can use <command> --help on almost every single
command line command, which can be used to quickly get a list of which
flags are available. Many times the whatis notation provides
descriptive arguments to very short 1-letter flags.

Then we have some really strange commands that can be aliased.

alias global_regular_expression_print
alias searchfile grep
alias search_replace sed
alias stream_edit sed
alias column_file_search_report awk

The other advantage of scripting of course is that you have far more
control over how things can be combined. Take a simple command like
"find".

There are many different expressions available for this command, but
trying to use a GUI would tend to limit you.

Once upon a time, there was even a gui based shell. It had drag and
drop modules which could be connected (just like pipelines) and when a
module was dropped, flags could be selected and set in another dialogue
area. The problem with this program, they couldn't keep up with how
quickly the anthology is growing.

There is also swig, which can be used to generate a wrapper file from a
synopsis or man page.

There are also info files. The advantage to this documentation is that
they make generous use of hyperlinks, which means that you can follow
the see-also sections along with details by following the links.

There are also gui interfaces to the manuals including xman.

There are also the Linux howto manuals which are usually available in
both HTML and "plain text". We also have docbook format, which can be
used to generate both HTML documents and printable "TeX" documents
which can be converted to postscript. If you don't have a postscript
printer, CUPS can convert postscript into HP's PCL along with several
other popular printer formats.

Many of the popular Linux GUI interfaces are actually script
generator/executors.

Linux advocates normally don't want to overwhelm new users with all of
the capabilities of Linux scripting and CLI commands. Ironically, this
is a bit like having an 8 cylinder 32 valve supercharged engine, that
you only drive in a state where the maximum speed limit is 55 mph. You
really don't get to experience all of that power until you want to get
into that tight slot before the convoy of Semi tractor/Trailers gets in
front of you.

Under the covers, Windows is mostly dependent on COM objects which are
packaged into DLLs, and must be compiled into programs. Furthermore,
each application using these large DLLs must load the entire DLL into
each application.

Under the covers, Linux is mostly command line shell commands which
have been compiled from objects stored in libraries. Most of these
commands or programs are very small, and only require very small
library modules to be loaded. This is why you often go to the task
manager processes tab in Windows XP and see 5-6 20-30 kbyte program
images running. IEXPLORE.EXE (40 meg), ntaskldr.exe (34 meg),
svchost.exe (20 meg), explorer.exe (18 meg), soffice.bin (15 meg), and
so on. This is IN ADDITION to the kernel itself (170 meg).
Lee Sau Dan
2005-11-18 15:47:35 UTC
Permalink
r> Other attempts were even wierder. The FORTH program would let
r> you put the "nouns" on the stack, then have the "verbs" operate
r> on the stack.

This is not wierd at all if your mother tongue puts verbs at the end
of a sentence, such as Japanese.

I guess a Japanese would find English's word order wierd. :)


r> In fact, forth let you use any word you want, and assign any
r> meaning (program) to that word. The forth programs or words
r> were then stored in the "dictionary".

And the Postscript language descends from FORTH.


r> In addition, you can use <command> --help on almost every
r> single command line command, which can be used to quickly get a
r> list of which flags are available.

And many DOS programs during the last incarnations of MS-DOS had the
"/?" switch, too!


r> The other advantage of scripting of course is that you have far
r> more control over how things can be combined. Take a simple
r> command like "find".

And shell scripts can be easily scheduled to run unattended using cron
or at. GUI? Huh?


r> Once upon a time, there was even a gui based shell. It had
r> drag and drop modules which could be connected (just like
r> pipelines) and when a module was dropped, flags could be
r> selected and set in another dialogue area. The problem with
r> this program, they couldn't keep up with how quickly the
r> anthology is growing.

This program could have a feature that reads in and parses a command
line typed in by the user, and then constructure those dialogues
automatically and the let the user examine the result visually,
possibly testing and fine-tuning it. Of course, it'd be nice to
translate the final result back into a shell command and let the user
see how it now looks like.



r> Linux advocates normally don't want to overwhelm new users with
r> all of the capabilities of Linux scripting and CLI commands.
r> Ironically, this is a bit like having an 8 cylinder 32 valve
r> supercharged engine, that you only drive in a state where the
r> maximum speed limit is 55 mph. You really don't get to
r> experience all of that power until you want to get into that
r> tight slot before the convoy of Semi tractor/Trailers gets in
r> front of you.

I tend to agree. When people ask me "why do you need to type
commands", I tell them "I don't need to, but I choose to, because
that's more powerful than stupidly pointing and clicking with a
mouse". Those who are interested in Linux for its strengths should be
shown what Linux is good for, not just those GUIs that feels different
from Windows.



r> Under the covers, Windows is mostly dependent on COM objects
r> which are packaged into DLLs, and must be compiled into
r> programs. Furthermore, each application using these large DLLs
r> must load the entire DLL into each application.

I can't believe that such an inefficient implementation is adopted!!!
--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: ***@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Kleuskes & Moos
2005-11-18 16:38:10 UTC
Permalink
Post by Lee Sau Dan
r> Other attempts were even wierder. The FORTH program would let
r> you put the "nouns" on the stack, then have the "verbs" operate
r> on the stack.
This is not wierd at all if your mother tongue puts verbs at the end
of a sentence, such as Japanese.
I guess a Japanese would find English's word order wierd. :)
r> In fact, forth let you use any word you want, and assign any
r> meaning (program) to that word. The forth programs or words
r> were then stored in the "dictionary".
And the Postscript language descends from FORTH.
(Courier) findfont 12 scalefont setfont
(\(sorry, couldn't resist\))(The Good Old Days)(Postscript...)(Ah,)
50 10 moveto show
80 10 moveto show
100 10 moveto show
120 10 moveto show
showpage
Post by Lee Sau Dan
r> In addition, you can use <command> --help on almost every
r> single command line command, which can be used to quickly get a
r> list of which flags are available.
And many DOS programs during the last incarnations of MS-DOS had the
"/?" switch, too!
Many *nix tools offer -h or --help or else man and apropos...
Post by Lee Sau Dan
r> The other advantage of scripting of course is that you have far
r> more control over how things can be combined. Take a simple
r> command like "find".
And shell scripts can be easily scheduled to run unattended using cron
or at. GUI? Huh?
r> Once upon a time, there was even a gui based shell. It had
r> drag and drop modules which could be connected (just like
r> pipelines) and when a module was dropped, flags could be
r> selected and set in another dialogue area. The problem with
r> this program, they couldn't keep up with how quickly the
r> anthology is growing.
This program could have a feature that reads in and parses a command
line typed in by the user, and then constructure those dialogues
automatically and the let the user examine the result visually,
possibly testing and fine-tuning it. Of course, it'd be nice to
translate the final result back into a shell command and let the user
see how it now looks like.
Such a tool should not be all *that* difficult to write... Pipes aren't
really the problem, for, while, switch etc, would be more difficult. It
needs a well thought our visual layout, though. You could offer
integrated man-page and info support...

Hey... That could be a swell little tool.
Post by Lee Sau Dan
r> Linux advocates normally don't want to overwhelm new users with
r> all of the capabilities of Linux scripting and CLI commands.
r> Ironically, this is a bit like having an 8 cylinder 32 valve
r> supercharged engine, that you only drive in a state where the
r> maximum speed limit is 55 mph. You really don't get to
r> experience all of that power until you want to get into that
r> tight slot before the convoy of Semi tractor/Trailers gets in
r> front of you.
I tend to agree. When people ask me "why do you need to type
commands", I tell them "I don't need to, but I choose to, because
that's more powerful than stupidly pointing and clicking with a
mouse".
If you're telling them, leave out the 'stupidly'. I think that would
not go down so well with the average GUI-addict you are trying to
convince.
Post by Lee Sau Dan
Those who are interested in Linux for its strengths should be
shown what Linux is good for, not just those GUIs that feels different
from Windows.
Give'm some time. They'll discover it by themselves. In '03 I had a big
argument on GUI vs CLI and we did a little competition. Removing .o
files from a build directory. :-) After he was convinced. He had to
point, click *and* type all I had to do was 'rm *.o<enter>'. He wanted
a replay: building an entire source tree, but he did not know about
'make' (yet). Went on to become a true bash fanatic after that and
within a month he was telling _me_ about the more arcane features and
constructs.
Post by Lee Sau Dan
r> Under the covers, Windows is mostly dependent on COM objects
r> which are packaged into DLLs, and must be compiled into
r> programs. Furthermore, each application using these large DLLs
r> must load the entire DLL into each application.
I can't believe that such an inefficient implementation is adopted!!!
Sad, but true, AFAIK.
Larry Qualig
2005-11-18 15:13:34 UTC
Permalink
Post by mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much all
depend on GUI programs. Just because GUIs are largely "the" way to
accomplish most basic tasks, there exists task, IMHO, that are more suited
for GUI.
I've had conversations with users, and they want a CLI. They don't know it,
but I've heard things like "how can I just tell it what I want to do?" "Why
can't I just tell it to pop out the CD?" "Why can't I say 'record at
5:00'?"
The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex ones,
much easier.
The question is: How to we incorporate a linguistic interface in a way that
the user will be inclined to use it?
I don't think this needs to be an either/or proposition.

The advantage of GUI tools is that they tend to be easier/friendlier
for a newbie to use. Especially if it's a tool one uses infrequently.
CLI tools offer more flexibility (piping, redirection, etc) but take a
bit longer to learn.

Ideally an OS would contain both. The CLI tools would be available to
users who are comfortable with them or want to script tasks. The GUI
would be there for the times when it's more convenient to use it over
the CLI equivalent.
mlw
2005-11-18 15:55:42 UTC
Permalink
Post by Larry Qualig
Post by mlw
This isn't necessarily CLI s GUI so much as a restatement about the
usefullness of a CLI. Yes, we pretty much all use a GUI. We pretty much
all depend on GUI programs. Just because GUIs are largely "the" way to
accomplish most basic tasks, there exists task, IMHO, that are more
suited for GUI.
I've had conversations with users, and they want a CLI. They don't know
it, but I've heard things like "how can I just tell it what I want to
do?" "Why can't I just tell it to pop out the CD?" "Why can't I say
'record at 5:00'?"
The issue is the complexity of tasks. With a GUI, you need to complete a
complex series of dialog box tasks, possibly save the results, and then
press enter.
A CLI rewards a little knowledge, with some basic learning a CLI can make
complex tasks easier, and make repeated tasks, especially the complex
ones, much easier.
The question is: How to we incorporate a linguistic interface in a way
that the user will be inclined to use it?
I don't think this needs to be an either/or proposition.
It wasn't posed as an "either/or" proposition.
Post by Larry Qualig
The advantage of GUI tools is that they tend to be easier/friendlier
for a newbie to use. Especially if it's a tool one uses infrequently.
CLI tools offer more flexibility (piping, redirection, etc) but take a
bit longer to learn.
Ideally an OS would contain both. The CLI tools would be available to
users who are comfortable with them or want to script tasks. The GUI
would be there for the times when it's more convenient to use it over
the CLI equivalent.
Well, ideally, the CLI, actually a linguistic interface to which a CLI would
be a predecessor, incorporated into the UI, maybe it is speech.
Lee Sau Dan
2005-11-18 15:21:50 UTC
Permalink
mlw> The issue is the complexity of tasks. With a GUI, you need to
mlw> complete a complex series of dialog box tasks, possibly save
mlw> the results, and then press enter.

mlw> A CLI rewards a little knowledge, with some basic learning a
mlw> CLI can make complex tasks easier, and make repeated tasks,
mlw> especially the complex ones, much easier.

Good point. CLI: things become easier as your experience with it
grows. GUI: things remain difficult despite the growth of your
experience with it.

Which is thus more frustrating for heavy users?


mlw> The question is: How to we incorporate a linguistic interface
mlw> in a way that the user will be inclined to use it?

At least, CLI resembles language. :) GUI resembles using gestures to
communicate.

(No offense to people who use sign languages. Sign languages are full
languages of their own, with complexities no lower than spoken
languages. I'm just saying that GUI is just a very primitive way of
communication.)
--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: ***@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee
Linønut
2005-11-18 18:34:33 UTC
Permalink
Post by Lee Sau Dan
At least, CLI resembles language. :) GUI resembles using gestures to
communicate.
(No offense to people who use sign languages. Sign languages are full
languages of their own, with complexities no lower than spoken
languages. I'm just saying that GUI is just a very primitive way of
communication.)
GUI resembles normal-hearing people using gestures to communicate (while
the deaf people laugh their asses off!)
--
Treat yourself to the devices, applications, and services running on the
GNU/Linux® operating system!
Continue reading on narkive:
Loading...