From: fj05+@andrew.cmu.edu (Faisal Nameer Jawdat)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: When is a CLI faster than a GUI?
Date: 27 Sep 92 03:31:35 GMT
Article-I.D.: andrew.YelNiLW00VAt8Dqm4L
	<ewright.717455746@convex.convex.com>
Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA

ewright@convex.com (Edward V. Wright) writes:
> Well, the zinger in here comes from the line about "similar experience."
> You couldn't do any of this things with a CLI without spending 20 or
> 30 hours reading manuals, committing commands to memory, etc.  On the
> Mac, the user be productive immediately and use those 20 or 30 hours
> doing real work.  The people who claim CLIs are faster always ignore
> that learning time.  They want to look only at the time it takes to
> type the command line.    

and most people who claim GUI's are faster take for granted the fact
that i'd like to do something besides play with the finder all day,
and the learning curve is there, it's just you're doing it with pretty
icon's and not nasty % signs - a cli is not for a beginning user but
for an advanced user to do anything significant in a GUI requires so
much more work than you waste learning a CLI - because this is the os
we're dealing with - any app has to be a GAI or it's almost useless,
but the os can be CLI based because that gives it a lot of flexibility

not that having a graphical basis also isn't a good idea, but to be
able to type that expression as several posters have is rather
usefull, and aliasing makes it easy to solve the oft quoted seldom
seen spelling problem (i type ahead, and usually delete before i see
it on screen because i know what i typed without looking)

oh, and, you'd have to be really dim or have really deficient manuals
to take 20 to 30 hours to figure out that string

> Even ignoring the time spent learning the CLI, you could drag
> a folder onto a drag-and-drop application that does the task
> faster than you could type the command-line anyone.

sure
have you figured on the time taken to write that program?
or does a good GUI come with a little drag and drop program that will
figure out every single possible string manipulation i want to do
it takes a hell of a lot more than 20 to 30 hours for a novice to
figure out how to program drag and drop text manipulation for the mac
i'd give extreme odds on figuring out how to program text manipulation
on any machine, but it would take a lot longer on the mac
another advantage of the CLI:  easier for people to learn to program
for

GUI's give you a rather large base of limited options
to go beyond that requires writing your own software and since it's a
GUI it requires much more programming effort than writing for a cli,
and to do something you could do on a cli with no knowledge of programming
CLI's give you a smaller base of open-ended options that can be tied
together into much more powerful and varied options.
it's easier to do weird things with a CLI.
thigs like AppleScript are only a half measure

> Also, one time out of every twenty or so, you're going
> to mistype that command line.  Most of the time what you type

maybe if you're really clumsy...

> will be rejected or do something harmless.  One time out of
> every hundred or so, you'll type something like
> 
> >find . -name '*.c' -print | xargs rm -f

anyone who does things like this as often as you purport should not be
allowed to speak with any knowledge on the values of a CLI
since no one I know is this lame, I can only assume that you, Edward
V. Wright, are speaking from experience?

I've been playing with DOS since 7th grade, unix since last year
i've never done anything as catastrophic as wipe a single directory by
accident

And I know plenty of people (the novices that you say GUI's are best
suited for), that upon seeing the question "drive unreadable:
initialize?" relating to their hard drive on the mac, have gone ahead
and hit OK

> Oops!  You've just removed all your source instead of your object
> files!  Now, you're going to spend a lot MORE time fixing what
> you just did.  Especially since Murphy's Law says that you will
> do this right *after* you've just spent 30 hours writing a new
> module that you don't have a backup of.  

and this is just as possible with a GUI

> So, 99 times out of a hundred, this command takes only 30 seconds
> of your time.  One time out of a hundred, it takes 30 hours.  The
> average time required to execute this command, then, is about
> (30 x 60)/100 = 18 minutes.

but gee, it's never 99 times out of a hundred because i'm fairly aware
of what i type when i type it
and when i do screw up, i've got backups... backups that take less
than 2 seconds to retrieve - i do this on the macs too.
but you can't base your entire argument on the worst case scenario for
stupid people - you're not the FDA (well you might be - where's convex)

> (Unless, of course, you lose your job because your company 
> missed a deadline when you accidentally deleted that source
> file.  Then it may take you 30 days to find a new one.  Which
> makes the average time about 18 days.)  

man you've had a hard life
i guess you're the type of user who learned how to backup AFTER his
first bad crash

> >find . -name '*.c' -print | xargs grep -l '/\*+frobozz' | xargs cpr -r0 | lp
> 
> >       Search all subdirectories for a C program containing the function
> >       "frobozz" and print those modules.
> 
> Obviously *much* faster than just clicking on a function name in
> Think C and choosing "print" from the file menu. ;-)

but first you have to find which modules to print - eh?
which means you have to go to every module and chose search and select
OK (unless they have to type frobozz first each time because it
didn't keep it as the default from the first time they did it) and if
it comes back positive chose print, and then go on to the next module

This is an extremely usefull comand if you're programming, and you
change a function, and you want to see if everythign still calls it in
the right way.

Or is there a simple drag and drop program floating around that will
do this for me?

For that matter, drag and drop programs won't take input on startup
besides the file, so you have to use a dialog to get flags like which
function to search for.  Which means I start the program and then I
have to wait for it to ask me questions before it calculates, rather
than just typing the command searchfunct (which is a common alias, and
rather easy to remember, even if you're like most advanced unix
weenies who have to remember what the print command is this week :-)
) and the function name as the only flag, and then either waiting for
a response, or doing something else in the meantime
Newsgroups: comp.sys.mac.advocacy