From: ewright@convex.com (Edward V. Wright)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 6 Oct 92 15:06:52 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In <1992Oct3.235607.14542@nwnexus.WA.COM> kanefsky@halcyon.com (Steve Kanefsky) writes:

>There are *lot* of other short-cuts built into CLIs.  I'll use tcsh 
>under UNIX as an example.

>First of all, tcsh has filename completion.  

Uh, that's nice.  So does System 7.

How many times will CLI advocates point out features available
on the Mac as "advantages" of DOS or UNIX?  How many times will
they ignore all the replies telling them that the feature is
available, without a CLI, on the Mac?  How long will it be before
one of them actually breaks down and *tries* a Mac? 

>(BTW UNIX filenames can be 128 characters long 
>and can have embedded spaces, punctuation, etc.  

Yes and no.  UNIX allows you to create such filenames, but filenames
with embedded spaces and some puntuation marks cause problems when
you try to use some UNIX utilities.  For example, if you have a file
named "foo bar", you can't do

 rm foo bar

You have to remember to do

 rm "foo bar" 

instead.  Bad design.

>There's also a UNIX
>command which can determine the type of a file (C code, PostScript,
>digitized sound, etc.) by its *content*.  Naturally the command is
>extensible to handle new file formats as they come along).
     
I doubt that very much.  Both C and PostScript files usually have
the same file type -- ASCII.  

>If I forget what files I have, I can always type a couple letters and
>then type ctrl-D, which will show me a list of all the files that
>match.  

Whereas, on the Mac, you'd have to go to *all the trouble* of typing
cmd-F, a couple of returns, and the carriage return.  Yeah, that's a
big advantage.

>I can easily tell the find
>command to apply the print command to all the C files which      
>are owned by me, readable by others, modified in the last 10 days,    
>and which don't have any syntax errors, for example.

The find utility knows whether a C file contains syntax errors? 
That's funny, the man page doesn't mention that.  However, you
forgot one thing about find.  "The syntax is cumbersome."  That 
isn't just my opinion, it's listed as a bug on the man page!

>The fact is, UNIX is so modular that you can do anything you can  
>imagine.  

Fine.  Write a device-indepent program that will play a digitized
sound on any UNIX box.  I can imagine it.  Can you do it?

>I've often written scripts which execute a command, take
>the output of that command and generate more commands from it, and  
>then execute those commands.  For example, before archie came along,
>I had a script which would ftp to a site, get a list of ftp sites,  
>generate a script to ftp to all of those sites, get lists of the    
>files at those sites, and put the lists into a tab-delimited form   
>that I could import into a database. And I know relatively little   
>about UNIX scripting!  

Oh, rubbish.  Anyone who can do that is at least a quasi-expert
on UNIX scripting.  It would take a fairly competent Hypercard
programmer to do the same thing.

>The Mac GUI is great for many things, but there are many areas 
>where a CLI is better.  Apple recognizes this, 
>which is why MPW has a CLI and why they are developing AppleScript.

Well, since you've previously shown that you don't know what
features are already in System 7, it should come as no surprise
that you don't have a clue what AppleScript is.  Hint: it's not
a CLI.

As for MPW, it exists, but Think C outsells it by a wide margin,
in part because of its superior, Mac-like interface.  Even people
who use MPW generally use the "Commando" utility to *cover up* the
command-line interface.

>You'll note that, even though THINK C has a better compiler and linker,
>most serious programs are written in MPW because the CLI offers the
>power and flexibility necessary for large programming projects.

Nope.  Not even close to be true.  I've heard that Think C outsells
MPW by ten to one.  That sounds high to me, but it might be true.
Symantec used to run an ad for Think C with a long list of the "serious"
programs developed with it.  That was several years ago, but three I
remember are PageMaker, Foxbase, and Macintax.  NIH Image was written
in Think Pascal.  The Think compilers are even used at Apple. 


>If you really think that the GUI is faster than a CLI in every case,
>try this:  Go into your favorite word processor.  Type a line.  Now 
>make 5 copies of the line using command-C and command-V.  Now do the
>same using the copy and paste menu items.  Time each one and tell me
>which is faster.  

Well, I won't go into all the reasons why it's impossible to 
time yourself in an experiment like this -- I would have thought
that was obvious.  However, if you set up a proper experiment,
with an unbiased subject and unbiased observer, you will probably
find the same thing as everyone else who has performed this experiment:
using the menus is faster, although, to the user, cmd-C and cmd-V
*seem* faster.

Now, what was your point again?

>A keyboard shortcut is essentially the same as  
>using a CLI, except you don't need to hit return at the end of the
>command.  

Maybe, if you don't have the slightest idea what a CLI *is*. 


>CLIs may have a big disadvantage in terms of the time it 
>takes to learn the commands, but they often have a big advantage in
>speed, 

Why does your definition of speed exclude the time it takes
to learn a command?  That statement is like saying, "The Rolls
Royce may have a big disadvantage in terms of the money it takes
to buy it, but it often has a big advantage over the Hundai in
cost per mile." 

>especially when you were already on the keyboard anyway and
>don't need to make an extra trip to the mouse and back.  

Nope.  Doesn't make any difference.  The time it takes to
make the trip to the mouse and back is less than the time
it takes to remember the command-key or CLI command.  People
who have actually performed the experiment in the real world,
instead of in their heads, have shown that.

>If you agree
>that the CLI is faster in this case, you have to agree that there are
>essentially infinitely-many cases where the CLI is faster.

And if I agreed that pigs could fly...
Xref: sparky comp.sys.mac.advocacy:936 comp.sys.next.advocacy:2478 comp.sys.next.misc:20393