preece@uicsl.UUCP (11/30/83)
#R:watmath:-619600:uicsl:21500004:000:1103 uicsl!preece Nov 29 09:38:00 1983 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". ---------- One of the reasons for having heuristics is to allow the command interpreter to make exactly that kind of change. This should be perfectly reasonable even to naive users. I don't expect the command '!c' to do the same thing every time -- I know it depends on the context. I know that if I walk into our secretary's office and say 'Call Linda' a call will be made to a different person than if I walk into one of my colleague's office and say the same thing. One of the things naive users don't like about computers is exactly that inability to interpret commands sensibly, in the context in which they are offered. scott preece ihnp4!uiucdcs!uicsl!preece
preece@uicsl.UUCP (12/01/83)
#R:watmath:-620600:uicsl:21500005:000:1118 uicsl!preece Nov 30 09:30:00 1983 Who says the only choice is between names with no mnemonic value and long, hard-to-type names? What's the matter with having a simple command mapping mechanism that turns those long names into short ones (or vice versa). When I can't remember the command I want, I use apropos to find it. This doesn't take long and usually gets me what I want in one probe. It would be better, though, if it did multi-term searching, so that the result list would be shorter. I can't believe multi-component commands would be any use. Who can remember the order of the components (the trivial example of 'compile-pascal' implying 'debug-pascal' is too simple; few commands come in neat families like that)? Worse, who can be sure of the individual components or which ones are needed (is it 'change-file-mode' or just 'change-mode')? Best of all would be a heuristic command matcher that would first try the command you entered, then try it as an argument to a command- dictionary-lookup procedure, then try mis-spellings, and ask for confirmation if it couldn't get a single, hard answer. scott preece ihnp4!uiucdcs!uicsl!preece
tjt@kobold.UUCP (T.J.Teixeira) (12/02/83)
Reading Scott Preece's article jogged my memory on where I had run into
trouble with multi-component commands. Both TOPS-20 (Tenex) and VMS
make heavy use of multi-component commands. For example, in VMS there
are lots of commands of the form "SET ...". To change your current
directory you use "SET DEFAULT device-name", to change modes on your terminal
you use "SET TERMINAL [:device-name]/qualifiers". However, to set the
value of a logical name, you use "DEFINE logical-name equiv-name".
TOPS-20 uses a similar scheme, although "SET" is less ubiquitous.
The problem comes in when you aren't quite sure what command you need
to invoke next. I agree with Scott that apropos is a good tool here,
although apropos is no better than the words used in the NAME line of
the manual page (try 'apropos delete' -- for 4.1BSD the only hit is the
dbm(3x) routines!). The HELP command in VMS was not quite as good, but
was serviceable. I no longer remember if it allowed wild cards in early
components such as "HELP * TERMINAL", but it wasn't too hard to
converge on things by the sequence "HELP", "HELP SET", "HELP SET
TERMINAL".
I found TOPS-20 *much* harder to deal with. The HELP database on
TOPS-20 only seems to describe subsystems and not the commands built
into the command interpreter (EXEC). Instead, you have to use a
combination of queries to the wildcard matcher and some inspired free
association. Even then, the *only* help you get online are the
parenthesized guidewords. You cannot find out about what choices are
available for component n without having specified components 1 to n-1.
In addition, far too many of the subsystems (and perhaps some of the
commands) have guidewords that only specify the *type* of the argument
(e.g. (FILE NAME)) and not the *use* of the argument (is it a source
file or a destination file).
Probably the object lesson here is: just as a "real programmer" can
write Fortran programs in *any* language, you can have deficiencies in
a command language no matter what model you follow.
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200franka@tekcad.UUCP (12/02/83)
#R:umcp-cs:-415100:tekcad:4200002:000:1192
tekcad!franka Dec 2 07:57:00 1983
Laura's view of the world too narrow!?!?!? Come on koved! I use a
computer for one purpose: TO GET THINGS DONE! If a stupid command language
makes me type out a fifty character command so that some brain-damaged man-
ager can remember it, I don't particularly find that system "user-friendly"
to me.
All of this crap about long command names vs. short command names
is valid ONLY if you assume you must choose between one or the other. I
really can't call a system "user-friendly" unless either:
1) it has enough different "modes" so that all levels of users have
the type of interaction they want (this means VERY large amounts
of software)
or 2) it is customizable, so that users can change the system to
provide a form of interaction that they are more comfortable
with
So everyone out there that thinks that command languages operate in
an either/or mode, stop wasting my time. If you build customizable systems
or systems with more than one command language, you don't have this stupid
problem.
From the truly menacing,
/- -\ but usually underestimated,
<-> Frank Adrian
(tektronix!tekcad!franka)andree@uokvax.UUCP (12/03/83)
#R:watmath:-620600:uokvax:1800006:000:424 uokvax!andree Dec 1 18:06:00 1983 /***** uokvax:net.cog-eng / uicsl!preece / 9:30 am Nov 30, 1983 */ Best of all would be a heuristic command matcher that would first try the command you entered, then try it as an argument to a command- dictionary-lookup procedure, then try mis-spellings, and ask for confirmation if it couldn't get a single, hard answer. scott preece ihnp4!uiucdcs!uicsl!preece /* ---------- */ Ah - what you want is INTERLISP! <mike
koved@umcp-cs.UUCP (12/06/83)
Frank, You seem to have misinterpreted my comments. I agree that there is a need to have short forms of commands for those people who consider themselves to be experts, and do not want to type the whole (50 character) command name. And, yes, there are systems which allow you to have more than one allowable version of a command name which can be recognized by the system. Let the computer work for you! The computer can have both the long name, and its abbreviations forms (such as the shortest form of the command which will be recognized), and synonyms. I leave it up to the implementers as to which way to set up the synonyms (either remove is a synonym of rm, or visa versa). I am sure there are arguments for both. I am also a computer hack. I am also a novice and an occasional user. I can be in any of these categories depending upon the computer and the software I am using! If the systems are not flexible, I am not likely to become an expert because it requires too much time to learn all of the tricks to become an expert. If a system allows room to learn at my own speed (with long command names), I am more likely to use the system because I do not need a reference manual open next to me to use the system. A really good system is one which allows both the expert and the novice, as well as a whole range inbetween! Now, to make such a system, you would need both the shortest (or an abbreviation list) and the longest forms defined. The abbreviation and synonym (alias) recognition software then takes over. The nicest system that I can think of would be one which would let me enter as much of the command name as I wanted...the system would fill in the rest after I hit the space bar or return key. Of course, I need the ability to surpress the expansion of the command name (for the experts who don't care what the whole name is). There have been a variety of such descriptions of this nature. Work needs to be done to understand them better. Anybody want to volunteer? Larry Koved U. Of Maryland, College Park