NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/mac/misc/16262

Internet Message Format | 1992-09-09 | 6.4 KB

Path: sparky!uunet!hayes!bcoleman
From: [e-mail] (Bill Coleman)
Newsgroups: comp.sys.mac.misc
Subject: Re: MACS COST TOO MUCH (NOT!)
Message-ID: <[e-mail]>
Date: 9 Sep 92 13:50:09 EDT
References: <[e-mail]> <92239     <[e-mail]> <[e-mail]>     <[e-mail]> <[e-mail]>    <[e-mail]> <922 <ajross.715985399@husc10>
Followup-To: 2 <ajross.715985399@husc10>
Lines: 123

Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 120

In article <ajross.715985399@husc10>, [e-mail] (Andrew Ross) writes:
>
> OK fine, lets all go out and buy Mac's 'cause you can name disks.  Back
> when floppies were king, this was a MAJOR advantage;  but now...  Well,
> hands up people, how many of you use your floppies more than once a week?

Uh, floppy disks aren't the only removable random-access storage media. The
naming convention of the Macintosh applies to all types of volumes. Now, I
don't think anyone renames his hard disk drive(s) on a regular basis, but
having unique names for each drive (rather than the nondescript A, B, C, etc)
is definitely a useful thing.

When it comes to removable media, I can tell at a glance which CD-ROM I have
in the drive, merely by looking at the name. With a command-line (DOS)
system, I'd have to do a DIR E: or some such just to see the title of
the drive.

> How many use them for anything but backup and software installation?  Of
> those of you who do use them, how many are not planning on upgrading to a
> better file exchange format in the near future?  At least where I am,
> floppies are dead.

Again, the naming of drives isn't confined to floppies. You're making that
assertion as a way of building a straw man in order to topple him.

The original poster was trying to demonstrate ONE thing the Mac could do
that you couldn't do on a PC. It was a simple, trivial thing, yet it was
beyond the capabilities of PC software.

If the Mac can out-do the PC in such a trivial area, imagine how the Mac might
out-do the PC in more significant areas.

> Because (and I still can't see why you won't admit this)  there are times
> where a command line interface is just plain easier than a graphical one.

Uh huh. And I got a bridge to sell you, too.

It may seem "easier" because of all the years of training and conditioning
you've done on command line interfaces. It may even BE easier because all of
the graphical interfaces you've compared are gosh-awful.

Before you make statements like these, I'd like you to point out some kind
of user interface study that showed that command line interfaces were
superior to graphical ones. Apple has made several such studies, and
graphical interfaces have won out each time.

> Like being able to run over your command line and run an applet or
> somesuch just buy typing it's name.

Oh, and what was that name? Was it "clock" or "time"? Perhaps "watch"? Was
it "calc" or perhaps "calculator". Oh no, it wasn't that at all, it was
"HP16C".

The biggest problem with CLIs is the need for perfect memory. You have to
remember what to type before you type it. While actually typing characters
may take less time, if you include the memory and lookup time, CLIs may
actually be slower than:

> Clicking through folders typically
> takes much more time than typing "clock", or "calc".

The advantage is that graphical interfaces let us tap our most basic learning.
When you are perhaps 1 year old, you already knew how to perceive things
in the world, reach out and grab them. With a graphical interface, you can
apply that learning. You can't remember what your clock or calculator is
called, but you remember from the shape and color exactly what it is, and
where it is. You can reach for it (via a mouse or other device) and interact
with it directly.

Compare this to the act of typing in a name. Many people can't even spell
correctly after years of schooling. Yet you would claim that typing in names
is easier than touching or grasping displayed items. I don't buy it.

> Also, some more
> complex shell operations are difficult or immpossible with a GUI.  You'd
> have to write a program to perform what would be a single line command in
> a CLI.

There may be specific shortcuts which the CLI has been optimized for. Consider.
You can easily copy all the files out of a directly by using the wildcard
"*.*". The graphical user has to select the files and drag them. Fortunately,
he can select them in groups, and perhaps the system provides a shortcut for
selecting them all.

Now the rub. In that same CLI, what if you want to copy some, but not all of
the files? The graphical user merely selects the ones he wants and drags
them. The CLI user is sunk. He's got to whip up a mental program of wildcard
matches, or he faces typing in the name of each file. If there's enough room,
and not too many files he doesn't want, perhaps he'll do a "*.*" anyway,
then delete the ones he didn't want copied.

A simple example. A better case for CLIs might be made by looking at the
power of the Unix shell -- which allows complex graphs of applications to
be linked together. But the implication of this "piping" is that all data
is represented by ASCII text files. Sadly, very little data is ASCII text
in a graphical machine. So there's currently no equivalent for Unix pipes
in a graphical environment.

The singular advantage CLIs might hold over GUIs is the ease of translation of
steps into a canonical notation. A CLI script is merely the concatenation of
several individual CLI commands. No equivalent yet exists for GUIs.

Were breaking ground here. AppleScript promises to erase some of this
"advantage". Frontier has already automated many of these things. Note that
while Frontier sales are solid, they haven't exactly taken the market
by storm.

Perhaps the answer lies in the users. Graphical interface users don't need
scripting. At least, they don't need it very often. When they do, they
either pony up for it, or they make do with what they have.


--
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: [e-mail]
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.