Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site dciem.UUCP
Path: utzoo!dciem!mmt
From: mmt@dciem.UUCP (Martin Taylor)
Newsgroups: net.cog-eng,net.nlang
Subject: Re: expert-friendly: are long names a waste of time?
Message-ID: <507@dciem.UUCP>
Date: Sun, 27-Nov-83 16:12:48 EST
Article-I.D.: dciem.507
Posted: Sun Nov 27 16:12:48 1983
Date-Received: Sun, 27-Nov-83 16:27:38 EST
References: <6196@watmath.UUCP>
Organization: D.C.I.E.M., Toronto, Canada
Lines: 52

============
  From Ian Allen:
  The problem with heuristics is that they don't always work.  If you
  can tolerate a command language that will sometimes come back to you
  and say "what do you really mean?", heuristics are wonderful.  You
  can then engage in a dialogue with the command interpreter to sort
  out what you really mean to say.  If you carry the idea to extremes,
  you eventually end up with a menu-driven interpreter that always asks
  what you mean right from sign-on.  I have no objection to this.
========

I have an objection to carrying such ideas to extremes. If a dialogue
is designed in such a way that ambiguities are few (cp 0666 0777 is
the example given), then most of the time the command interpreter need
not query every command. The problem is elsewhere: the command interpreter
must know what kinds of arguments are needed for any program that could
be called, so that it can tell whether there is an ambiguity. This is
contrary to the UNIX philosophy, but it is in line with the human user's
idea that the other side of the dialogue is "the computer", rather
than "the current shell" or "the cp program".

One cannot tolerate a command language that asks for ambiguity correction
when it is supposed to be running in background. This is why I suggested
in my original article on this theme that there should be a formal and
exact command language for background commands and a more flexible
command language for interactive commands, in an exact analogy with
the formal language used in writing (non-interactive) as compared with
the informal and flexible syntax used in conversation.

=========
  If you are designing a command language that is supposed to have a
  precise meaning and work first time and every time, you can't use
  heuristics that change the meaning of commands.  Every command must have
  a unique interpretation, regardless of the current environment in which
  it is invoked.  You can't have "chmod 0666 0777" change meaning depending
  on whether the current directory contains a file named "0666" or "0777".
============
You never will find a command language that works first time and
every time, if only because the users make mistakes. The language
specification may be precise, but the overall result may be better
if an imprecise language, easier for humans, can be used. I don't
think the objective is to design "a command language that is supposed
to have a precise meaning" but to provide ways of interacting with
the machine that get the job done easily and without frustration
on the part of users. There may well be circumstances that demand
a precise specification, but common situations may benefit from
the application of a little tolerance on the part of the command
interpreter.
-- 

Martin Taylor
{allegra,linus,ihnp4,uw-beaver,floyd,ubc-vision}!utcsrgv!dciem!mmt