From: kanefsky@halcyon.com (Steve Kanefsky)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: More Defense of CLI (there, I changed the subject ... )
Date: 16 Oct 92 22:39:36 GMT
Article-I.D.: nwnexus.1992Oct16.223936.1831
Organization: The 23:00 News and Mail Service

In article <ewright.719257733@convex.convex.com> ewright@convex.com (Edward V. Wright) writes:
>In <1992Oct15.204843.11547@nwnexus.WA.COM> kanefsky@halcyon.com (Steve Kanefsky) writes:

Side note:  Please try and keep the information content of your postings
up.  Silly insulting rhetorical remarks aren't necessary.  If you can't
refute a claim with useful information, just don't respond to it.

>>>Am I missing something here?
>
>>Dunno.  I think I've shown that a GUI is not inherently more or less
>>consistent than a CLI.  
>
>No, no, no.  All you showed was that the Macintosh interface was not
>*perfectly* consistent.  You did not show that it was as inconsistent
>as any CLI -- not within an order of magnitude.

This is true.  I consider the burden of proof to be on you to show why a
CLI is *inherently* less consistent than a GUI.  There are already  CLIs
with more consistency than the MacOS in some areas.  I consider UNIX's
standard input/output mechanism to be more consistent than Macintosh
I/O, for example.



>>Apple has shown an ability to come up with a
>>consistent interface.  I'd like them to use that ability to come up with
>>a consistent command-line Mac interface
>
>A double oxymoron.  No command-line interface can be consistent.  And if 
>it's a CLI, it's not a Mac interface.

Please demonstrate the first statement.  If I pick an apple out of a
barrel and it's rotten, does that mean that all the apples in the barrel
are rotten?  Even if I pick out a hundred apples and they're all rotten,
it doesn't prove the rest are rotten.  That's about the first thing you
learn in logic.

>>(which they are, in fact, doing)
>
>Oh?  Perhaps you should leak this revelation to the rest of the world.
>MacWeek would pay good money for secret information like this.

I believe AppleScript has been reported on extensively.  There's also
A/UX and MPW and AppleEvents, which are all related to CLI support in
one way or another.  I'm not sure exactly what AppleScript will turn out
to be, but it sure sounds like a CLI.


>>because a command-line interface has some advantages over a graphical
>>interface in some areas.  
>
>Bullpuckey.

Lots of useful information there.  Thanks.


>>These advantages/disadvantages are completely independent of consistency.  
>>got it now?
>
>Yes.  You're deluded.

Whoa, how can I beat that argument?


>>>And if you're really a "fan" of the Macintosh interface, why do you
>>>slime it by using derogatory terms like "Gooey" for it?
>
>>Be careful, you're really coming across like a fanatic here.  
>
>But you claimed you were a Macintosh fanatic yourself.  (Look up the
>word "fan" in the dictionary.)
>
>>Since when is "Graphical User Interface" a derogatory term?  
>
>Since the day it was created.  That term was created to slime
>the Macintosh interface by lumping it with MS Windows, X, and
>all the other "Gooeys."

I think you're mistaken.  GUI is a very reasonable and descriptive term.
I really have trouble seeing why it would be invented to slime
something.  That's like saying that the term "software" was invented to
lump together all programs with bad programs.  Do you think that every
word which describes a group of things, some of which are bad, was
invented to lump the good in with the bad.  Do you think the MacOS is so
different and so superior to Windows that it should have a whole new
term invented for it?  I'm perfectly happy calling it a GUI and I don't
mean any offense by it.  I think it's the best GUI I've seen, though
there are features here and there where other GUI's have it beat.


>>I simply used an abbreviation for that term:  "GUI."  I have never, 
>>ever, used the term "Gooey." 
>
>Same term, different spelling.  "Gooey" is how it's pronounced.

Hmm, I pronounce it "gee-you-eye", although I rarely use it in speech.
It's just easier to type than "graphical user interface"


>It's okay, though.  I expect this from a fan of CLUNK (Command
>Line Under Normal Komputing) machines.

I'm a "fan" of both.  I don't like the term "fan" however, because it
implies that you support something without regard for its merit.  A fan
of a sports club generally roots for them even if they're the worst team
in the league.  I would drop the MacOS in a second if something better
came along.  I'm always looking to make things better.


>>And if you can't do something at all, it's infinitely difficult, right?
>>Since you can't do some things with the Mac GUI that you can do with
>>some CLI's, those things are infinitely easier to do with a CLI.
>
>Since pigs can fly, they have wings.

The difference here is that your premise isn't true.  I suppose you were
trying to imply that my premise was untrue.  Luckily, it's much easier
for me to show that there exist things you *can't* do with the Mac than
it is for you to show that you can do everything with the Mac.  For
example, I can't do the find command I mentioned earlier, where I search
for files based on whether they are syntactically correct C programs.
No matter how difficult that is with a CLI, it's infinitely more
difficult with the MacOS.  In the best case, you'd have to do it
manually, in which case I just increase the number of files.  I just
type one command and come back tomorrow, while you have to stay all
night doing it.  

>>I've had about equal experience (8 years worth) with UNIX and the Mac.
>>Do you really think I'd be completely blind to the fact that I'm less
>>efficient with UNIX if that were the case?
>
>I don't know.  Are you?

No.

>>No, I'm talking about access controls in the more traditional sense.
>>This is an application to model the entire Boeing 777 aircraft, with
>>hundreds of people entering data and hundreds of thousdands of objects.
>>We can't have Joe Blow deleting the entire aircraft from the database,
>>can we now :-)  We wanted Joe to *know* that delete was unavailable to
>>him by greying it out.  
>
>Well, if it's the *object* that the user doesn't have access to,
>rather than the tool (which is what I thought you said the first
>time), why not do the logical thing and grey out the *object*?

It's the tool applied to the object.  You might be able to use the
delete tool on a signal, or the view tool on the aircraft, but not the
delete tool on the aircraft.


>>On the other hand, if the currently-selected
>>object was a signal, we didn't even want a tool like "simulate" to show
>>up in the menu because it simply doesn't make sense to simulate a
>>signal.  
>
>Well, it makes perfect sense to me, but never mind.  I'll take
>your word that it doesn't make sense in the context of the program.
>But graying out "simulate" would have conveyed the same information
>to the user, without rearranging other menu items so he couldn't
>find them.

Well, you're not in avionics, (I realy don't have much avionics
background myself) so you wouldn't understand what the simulate tool
does.  

When you think about it, the Mac really does the same thing.  When you
switch applications you get an entirely new set of menus applicable to
the current application.  It would be stupid to see every item from
every application's menus in every other application.  In a way, the
program I worked on is like browsing around documents that belong to
different applications.  You could have a project object, for example,
which had relations to all the documents that make up a project.  When
you browse to a Word document, you're in Word, so all the menus change
to reflect that fact.  Move to an Excel document, and you're in Excel,
so you get Excel's menus instead of Word's.  Move to a folder object and
you're in the Finder, etc.  Although the application doesn't run on a
Mac, you can define any domain you like, so a domain like the one I
mentioned is possible.  We just happened to use an aircraft avionics
domain.


>>Even a toolbox would still have been cluttered by all the tools.  
>
>Popup "drawers" within the toolbox...

Take the example above, and try to imagine every menu option in every
application you use as a big set of these popup drawers.  I think things
would get cluttered in a hurry.


>>One of the key aspects of this system was
>>that a system administrator could use it and have a completely different
>>view of things than the average user who just needed to enter some data.
>>The average user didn't even want to know that tools for system
>>administration existed.  
>
>So why should you add them to his program?  One-size-fits-all
>software is the wave of the past....


This isn't one-size-fits-all software.  The software models a world, and
different people are interested in different parts of the world.  Trying
to model the same thing twice for two different views is a big software
no-no.  Obviously I haven't explained things well enough, which is good,
because I'd probably be violating a non-disclosure agreement if I did
:-)

I think I've about run out of things to say on this subject.  It's
pretty silly to argue against people who say that something shouldn't
exist because they don't like it anyway.  If you don't like something,
don't use it, but don't try to tell other people that they can't like it
either.  Personally, I love GUI's, and I love CLI's.  I love computers
in general and I hope the good ideas from *all* interfaces are taken
into acount in the next generation of interfaces. 

--
Steve Kanefsky
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA