Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.cog-eng
Subject: Re: Re: thousands of input flags in one - (nf)
Message-ID: <1081@rlgvax.UUCP>
Date: Wed, 31-Aug-83 19:25:13 EDT
Article-I.D.: rlgvax.1081
Posted: Wed Aug 31 19:25:13 1983
Date-Received: Thu, 1-Sep-83 20:26:35 EDT
References: <1306@whuxlb.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 34

Perhaps UNIX systems should provide a variety of user interfaces, as they
definitely aren't just for programmers anymore.  However, for all the the
flak UNIX gets for its user interface it's not clear that most other
*comparable* systems are better by all that much.  Would you say that CP/M's,
or RSX-11's, or TOPS-10's "PIP" is less "cryptic" than UNIX's "cp"?  (Yes, I
know that DEC's command languages have picked "COPY" for the copy command
now.)  Perhaps UNIX's command language isn't the nicest in the world, but
are most of the comparative systems *that* much better?  If not, perhaps
the criticisms should be levelled equally at all such systems.  Then again,
there was some research at Bell Labs that indicated that the difference
in "user-friendliness" between "cp" and "copy" didn't amount to much, if
anything - users could pick up whatever the "local" name for a command was
in a short period of time.  I suspect what's referred to as the "principle
of least surprise" is more important; keep your command language reasonably
self-consistent (e.g., if the "-v" flag means "verbose" in most commands try
to make it mean that in as many commands as possible) and consistent with
some fairly straightforward model of the world (i.e., a "copy" command which
took the input file as "/INPUTFILE=xxx" and prompted you for the output file
might be poor).

Complete and *obligatory* terseness is *not* a virtue.  The pre-UNIX/TS "ed"
which had *no way* of explaining an error message was not the right way to
do things, 300 baud terminal or no.  Many editors which were used at 300 baud
had more helpful error messages.  One idea which TECO had and which appears
in the current "ed" is that the editor can either output long error messages
or it can output short ones and you can ask for an explanation of the last
error.  If you have to look at the past 20 lines of output to figure out
why something went wrong (i.e., because a program is *always* silent about
missing files) that's not a good idea.  (And "pr"s "Very funny." error
message is amusing to those who know what's so funny but insulting to those
who don't.)

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy