idallen@watmath.UUCP (10/23/83)
But most short names are abbreviations for long names. RM is an abbreviation
for REMOVE FILE, RMDIR is an abbreviation for REMOVE DIRECTORY.
If you claim that nobody will remember a long name, then I claim
you make it worse by forcing people to remember the abbreviation too.
If you want to argue about what people will remember, then we should
talk about ways to minimize the amount of stuff that has to be remembered.
I don't know if memorizing arbitrary abbreviations is easier than
remembering whole words, but I do know that memorizing fewer things is
better than memorizing a lot of things.
Teach me command names in a cross-product approach, where I only need
to remember a few verbs and objects. Allow me synonyms for each.
(Let DATASET be synonymous with FILE; let DELETE be synonymous with
REMOVE.) Then, I can build most of my commands using the verbs and
objects I know.
--
-IAN! (Ian! D. Allen) University of Waterlootim@minn-ua.UUCP (Tim Giebelhaus) (10/26/83)
I wasn't thinking of UNIX so much. I think that their names are a little overly short. I would just assume type in "pascal" as "pc". PC is harder for me to remember. On the other hand, I would not like to type in: compile_pascal_program. On Multics there are long commands like that, but luckly, they have abrevs. It is a nice way to do it, that is, have both long and short names be reconized. stolaf!umn-cs!minn-ua!tim
idallen@watmath.UUCP (11/02/83)
This is why I prefer "compile_pascal_program" over "pascal":
Question: If the name of the pascal compiler is "pascal",
what is the pascal debugger called?
Answer: Well, um, uh.... Maybe "debug_pascal" or "pascal_debug" or
"debug", or... Well, who knows, really.
Question: If the name of the pascal compiler is "compile_pascal_program",
what is the pascal debugger called?
Answer: debug_pascal_program!
Once I know the long names for things, I can find out the system
abbreviations if I need them. Maybe I know the system-wide abbreviation
rule, and can figure out the abbreviation myself. But I don't have to
remember arbitrary names right from the start.
--
-IAN! (Ian! D. Allen) University of Waterloolaura@utcsstat.UUCP (Laura Creighton) (11/02/83)
"compile pascal program" and "debug pascal program" only are reasonable ways of doing things because of the structure of English. I find English highly unsatifactory as a language to express day to day thoughts in, so I am not sure that it is going to be a wonderful computer language. The most annoying thing that I see about English, is that grammar teachers to the contrary, there is a pretty strict sense of word order. You need a <subject and subject modifiers and their modifiers> followed by a <verb and verb modifiers and their modifiers> followed by a <subjective completion or object and subjective completion or object modifiers and their modifiers>. You can forget about the object or the subj. comp. if it is an intransitive verb, but often in English the object is the most important thing. Sometimes the adverb modifiers are -- and often they are stuck out on the end of the sentence! A while ago I said "Are we going to go to the Chelsea Inn soon?". Now the crucial part of this message is "Chelsea Inn" and "soon". I am hungry and want to get eating. But I had to say 7 useless words before I could get into the 2 important ones! It is a measure of how useless word order is in determining meaning in that we have to use STRESS so much in this language. "Are WE going to the Chelsea Inn soon?" and "Are we going to THE CHELSEA INN soon?" and "Are we going to the Chelsea Inn SOON" all mean quite different things. Pity the new speaker of English! This is also why certain technical writing in the passive voice goes over so badly -- English needs a subject so people use "one" or "people" or maybe even "you" until everyone is tired of it, and then switches to the passive voice. However, it is not the voice that matters, but how quickly you get to the "good stuff". People tend to say that the passive voice "drags on and on" because in general it *does* add extra noise words to the sentence, and unless you offset this disadvantage by getting to the most intersting part of the sentence faster you will make things *worse*, not better! I think that "debug pascal program" works because you get into the meat of the matter "debug". This is not perfectly extensible however. How many times have you thought? Is it "adb program coredump" or "adb coredump program"? How about "chmod mode file" or "chmod file mode"? Clearly, what will sound better to you is going to vary. I always think that "chmod mode file" is backwards. I think that the file is much more important than the mode. There are hundreds of files which I own, I might forget the name, but there are only ~300 modes, only 6 of which I use with any frequency. However, I meet people who disqagree. I do not think making the commands any longer is going to help. "change the mode of file foo to mode" and "change the mode to this of file foo" are still going to be a problem. Laura Creighton utzoo!utcsstat!laura
mmt@dciem.UUCP (Martin Taylor) (11/03/83)
Laura (in net.cog-eng) points out that English uses a lot of
"useless words" that often occur before "you get to the good stuff".
This is a consequence of the fact that the real world contains
many possible contexts within which statements, questions and
other interactions can be framed. There is a concept in psycholinguistics
called the "Given-new contract", which, roughly stated, says that
the partners in a dialogue agree to present something new in each
element of the dialogue, with enough prior material (the given) to
show where the new stuff belongs. In Laura's example: "Are we going
to the Chelsea Inn soon?" the early words are NOT useless unless
she assumes that the context of going out to the Chelsea Inn was
previously established in the minds of all participants. If
the dialogue had been:
Where are we going?
Chelsea Inn.
Soon?
Each of the dialogue elements would have contained almost exclusively "new"
items, and there would be no wasted words. (Only "are we going" in the
first unit would be "given" material.)
Now consider this in the context of long computer commands. If the
computer had an intelligent interface that permitted the use of prior
context, then most of the time it would be possible to use very short
commands, analogous to "Soon?". But this facility would have to be balanced
by the need for long specification when the context was switched,
in a way precisely analogous to what has to be done in natural language.
Laura also brings up the point that the order of arguments is not
necessarily natural in multi-argument commands, and that this problem
might not be alleviated by increased command length. In English,
the relation between verbs and their arguments can be signalled
both by word order and by the addition of cue words ("function
words") that indicate special relationships or relationships that
differ from what the word order suggests.
If a command has many arguments, they can easily be signalled by
function words (chmod files=foo,bar,grunch mode=755; chmod 755 foo bar grunch).
The problem is the same as in natural language, that of remembering
the proper word order. Since a command is in the imperative, it is
natural to put the verb first, and the subject is usually the computer.
A problem arises in that there may be many arguments, not just the
three to which English verbs are limited in the absence of function
words. When there are many, it is difficult to remember their order.
In English there are general rules about the orders of direct objects,
indirect objects, and so forth (one says "put that there", not
"*put there that"). Similarly, in UNIX, commands relating two files
usually have "oldfile newfile" as the accepted order. Novices may
not know that, and it would be useful to allow function words: "mv old to new".
Where the arguments are of different semantic types, English usually
permits one to interpret correctly the meaning even when the order
is wrong. So should the computer command language. "chmod foo bar 755"
should be interpretable if foo and bar are files, and 755 is a legitimate
mode known to the chmod command. In fact, that kind of syntax could
permit a useful extension to such commands: chmod foo bar 755 grunch 644,
for example (This would be identical in effect to:
chmod 755 foo bar 644 grunch, since the slots requiring mode arguments
would be filled in the same order in both cases).
This line of argument is quite independent of the mnemonic argument
that started the discussion on this topic, and should perhaps be
continued in net.nlang rather than net.cog-eng.
Martin Tayloridallen@watmath.UUCP (11/04/83)
I do not like, and am not suggesting, English as a computer language.
"Compile_pascal_program" and "debug_pascal_program" as command names are
only coincidentally reasonable because of the structure of English.
We only need to use the actions and objects of English, not the
ambiguities of English structure, emphasis, and syntax.
Even if you told me that the command to compile a Pascal program was
program_pascal_compile
I could still tell you what the command to debug it was. I could also tell
you how to compile FORTRAN or COBOL programs, or how to delete such programs.
(Just substitute the obvious word in the reasonable place in the template.)
Making the command names longer does help; I have to remember fewer things.
Just knowing the above command name and the new words "debug", "delete",
"FORTRAN" and "COBOL" gives me nine working commands. If I learn a word
for another language (e.g. MODULA), I instantly know twelve working commands.
If I then learn a new verb (e.g. edit), I instantly know sixteen commands.
This cross-product command naming scheme saves me from memorizing arbitrary
names for every combination of verb and object. Saves brain space.
--
-IAN! (Ian! D. Allen) University of Waterlooidallen@watmath.UUCP (11/04/83)
I agree with Martin Taylor when he says remembering the order of
arguments is difficult. I don't think his answer, have the computer
try to interpret the order, will work well. Continuing his example:
echo hi >755 ; echo ho >644 ; chmod 644 755
The computer can't figure out which argument order I mean in this
(contrived) case. Nor can it figure out if I replace CHMOD with CP.
If two (or more) different things have to be given as command arguments,
then the order of two things can get confused. Some way is needed
to flag which kind is which. The easiest thing on the brain is:
***************************************************************
***> Don't allow more than one kind of unflagged argument. <***
***************************************************************
I would rewrite CHMOD as follows (the order of arguments doesn't matter):
change_file_mode [mode=]755 [filename=]/u/idallen/myfile
where either "mode=" or "filename=" *must* be present to tell the
command which kind of argument is which. A repaired example:
change_file_mode 644 mode=755 /*OKAY*/
change_file_mode filename=644 755 /*OKAY*/
change_file_mode m=755 f=644 /*OKAY*/
change_file_mode 644 755 /*NO GOOD*/
Never rely on position (first, second, last, etc.) to determine what
will be done with an argument. Require the user to make explicit which
types of arguments are which, and then order doesn't matter. The
arguments can be flagged and typed in as the user sees fit, and the
user's perception of which argument "should" come first doesn't matter.
--
-IAN! (Ian! D. Allen) University of Waterloophil@amd70.UUCP (Phil Ngai) (11/04/83)
Re Laura's question about "chmod 755 file" or "chmod file 755", it's
more logical if you remember you could have "chmod 755 file1 file2".
If you had "chmod file1 file2 755" the program would have to read until
the end to find out what mode to use. When it gets the mode first, it
can just grab new file names and change them. Please don't make suggestions
that prevent me from having files with numbers as names.
Now, who can explain:
clri filesystem i-number vs
ncheck -i numbers filesystem
--
Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!philspeaker@umcp-cs.UUCP (11/05/83)
Once I know the long names for things, I can find out the system abbreviations if I need them. But I don't have to remember arbitrary names right from the start. Hmmmm... I find just the opposite is true. That is, long names confuse and cloud the issue. Consider what you might call the program that lists your directories... "list_directories" "show_directories" "directory" "list" "catalog" "directory_list" "files" "list_files" "show_files" etc, etc. Who knows WHAT it might be! The Unix 'ls' is much easier to remember because I associate 'ls' with listing my directories. I don't have to go through the intermediate step of figuring out what the abbreviation is for. 'ls' seems to be a word or entity all to itself and I associate it immediately with seeing my directories. The same is true with a seemingly meaningless word like 'grep'. Sometimes I feel I could use this in everyday conversation, the meaning is so well defined in my head. And in fact... I and some of my friends DO use it as such. To each his own. -- - Speaker-To-Stuffed-Animals speaker@umcp-cs speaker.umcp-cs@CSnet-Relay
judd@umcp-cs.UUCP (11/06/83)
I disagree (some what) with Ian. The use of parameter names can
be as confusing as the use of shart command names(opinion). I
find it much more natural to use english connectives to make clear
what is what. {this was the point of an earlyer article}
For chmod how about:
chmod <myfile> to <mode>
chmod to <mode> <myfile>
chmod <file1> to <mode1> <file2> to <mode2>
all as legitimate? This is "natural" and very flexible and very precise.
It may be harder on the program but who cares - cpu time is cheap.thomas@utah-gr.UUCP (Spencer W. Thomas) (11/06/83)
I would rather see 'compile' and 'debug' for ALL languages. I mean, why should YOU have to tell the computer what kind of language you are using. Really, talk about *useless information*. Since, for example, cc will only accept files ending in '.c' as C programs (it passes '.s' files off to the assembler, '.o' files to the loader, etc.), it comes pretty close to such a 'compile' command. I should only have to tell the computer ONCE what type of file I've got, it should remember from then on. =Spencer
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/06/83)
There was an article in a recent CACM which 'demonstrated' that it didn't matter *what* you called the commands in an editor - the command names could be totally meaningless - when people learned any set of commands they were equally proficient. =Spencer
crl@pur-phy.UUCP (Charles LaBrec) (11/06/83)
It seems to me that what a lot of people are talking about has already been implemented on TOPS-20 (yes, another former DECsystem-20 user speaks up). I will use as an example the TOPS-20 equivalent of chmod. The full verbose syntax was: @SET FILE PROTECTION (OF FILES) FILE.EXT (TO) 777752 However, the guide words (in parentheses) were not necessary to type in, and command completion and least ambiguous recognition were done on each field. So the expert would learn to say: @set fil prot foo.bar 777752 For the novice, typing a '?' at various points would tell him/her what was expected next--after 'set' would say what keywords were valid, after the 'f' of 'file' would say what keywords began with 'f', after 'prot' it would say "FILE NAME", and after the file, "Octal number protection value" (or some such). If an escape was typed in the middle of any keyword/file name, it would complete it, if not ambiguous, and print the guide words that followed. I've always liked the user interface on TOPS-20. Not as concise as UNIX, but verbose enough for novices. If it only had pipes, redirection, C, and more UNIX tools . . . Charles LaBrec UUCP: pur-ee!Physics:crl, purdue!Physics:crl INTERNET: crl @ pur-phy.UUCP
idallen@watmath.UUCP (11/08/83)
I, too, don't care about CPU power needed to parse something; but,
I don't want to mislead people into thinking the command interpreter
understands English. Too much flexibility and the use of English
connectives might do this. If you make the interpreter respond to
some English syntax, but not all, you may not be able to tell your
users precisely what your command interpreter can understand.
Even the simple "chmod x to y" could read "chmod of x to y", and
perhaps "ch_the_mode of x to y" or "Change the mode of file x to mode y.".
In settling on "chmod x to y", you have already dropped many of the
components of the English sentence; how does the user know which words
to drop? Many people have implicitly dropped the "of" when they say
"chmod mode file"; on the other hand, some people think they drop the
"to", and mistakenly say "chmod file mode".
English is not a concise command language, even between people. I
don't think you can keep the English connectives without misleading
people about the power of the command interface.
Have you seen the October SIGCHI Bulletin, "Constrained Languages Need
not Constrain Person/Computer Interaction"? A real study of people.
--
-IAN! (Ian! D. Allen) University of Waterloochuqui@cae780.UUCP (Chuq Von Rospach) (11/10/83)
Phil brought up an interesting point about chmod: the reason its the way it is is because it was easier for the programmer to write it that way. This may have been appropriate when resources were scanty and users were experts (and I doubt if the latter was ever REALLY true. technically oriented, maybe) but now it seems like pure laziness to me. As far as chmod is concerned, you don't need to worry about reading all of the files before getting to the mode... When you start parsing parameters you pull off the last one for the mode and then use the rest for filenames. Presto - no worry about numeric files, and parameter parsing is not changed significantly, yet chmod now works as some people say it should (I have fallen into 'chmod file mode' more than once, but I don't know if that is a preferable syntax or not. Personally, most of Unix's syntax is painful...). Now, to take chmod one step further, to properly implement it the command should look something like this: chmod <file> <file ...> <mode> <file> <file ...> <mode> ... where you can change modes in midstream. I can't tell you how many times I have wanted to do a group of somethings to files and have had to invoke chmod multiple times in a row.... -- From the dungeons of the warlock: amd70!cae780!chuqui Chuqui the Plaid *pif*
idallen@watmath.UUCP (11/13/83)
From thomas@utah-gr.UUCP (Spencer W. Thomas) Wed Dec 31 19:00:00 1969
There was an article in a recent CACM which 'demonstrated' that it
didn't matter *what* you called the commands in an editor - the
command names could be totally meaningless - when people learned
any set of commands they were equally proficient.
...which means we should worry about how to name commands so people
learn them most easily.
--
-IAN! (Ian! D. Allen) University of Waterloothomas@utah-gr.UUCP (Spencer W. Thomas) (11/14/83)
Let me clarify. I quote from "Natural Command Names and Initial
Learning: A Study of Text-Editing Terms", CACM 26,7 (July 1983), 495.
First, from the abstract:
... computer-naive typists spent two hours learning minimal
text-editing systmes that varied in several ways. Lexical
naturalness [e.g. "natural" command names] ... made little
difference in their performance. ... having different, rather
than the same names for operations requiring different syntax
greatly reduced difficulty. It is concluded that the design
of user-compatible commands involves deeper issues than are
captured by the slogan "naturalness". ... Only initial learning
of a small set of commands was at issue ... generalization ...
will require further testing.
The article is actually in two parts, the first was a study which asked
people what they would call certain text editing operations. Not
surprisingly, there was a VERY large amount of variation.
The editor command sets they used were
Old New Random
--- --- ------
Delete Omit Allege
Append Add Cipher
Substitute Change Deliberate
Where the "new" names were supposedly more natural, based on the results
of part 1.
>From the conclusion, talking about choosing command names:
We began our investigations with the hypothesis that commonly
used words for similar operations in the noncomputer
environment would be best. Such words are familiar and have
at least approximately correct known meanings, so they should
demand minimal new learning. This line of reasoning has a wide
following .... It now appears to be a somewhat naively
undifferentiated view. ... popular [words] [are] the ones less
consistently applied .... Clearly, constructing a command set of
words whose natural meanings tend to lead to misuse is not
desirable. .... The finial conclusion ... is clear: rational
design of commands and command names for usability requires
deeper understanding than is captured in the slogan "make the
language natural."
=Spencerdaemon@decwrl.UUCP (11/14/83)
From: Ed Featherston HL01-1/P06 225-5241 <roll::featherston>
Begin Forwarded Message:
-------------------------------------------
Newsgroup : net.cog-eng
>From : KRYPTN::TS1::BURROWS
Organization : Digital Equipment Corp.
Subject: Re: expert-friendly: are long names a waste of time?
-------------
From thomas@utah-gr.UUCP (Spencer W. Thomas) Wed Dec 31 19:00:00 1969
There was an article in a recent CACM which 'demonstrated' that it
didn't matter *what* you called the commands in an editor - the
command names could be totally meaningless - when people learned
any set of commands they were equally proficient.
Actually, that's not what they demonstrated, although it's not hard to see
why one might get that impression. (In fact, a friend who reviewed the article
warned one of the authors that it might be so construed. Ah, well...)
Their actual conclusions were:
1) Novices and system designers use different language to describe
text editing.
2) That people in general describe the operations differently, and
inconsistantly.
3) That guessing what is "natural" or "common" rather than observing
and analysing real users is unlikely work
4) That although familiar words are easy to learn as command names,
there is a danger that the imprecision of a number of the most
common words will cause them to be misused.
5) That a reasonable compromise might be to use words that were
only moderately common, so that they are recognisable, and thus
more easily remembered than totally unfamiliar words, but don't
suggest so many different and possibly conflicting means as to
lead to misuse.
6) That it is more important that the commands be unambiguous and
precise than familiar and memorable.
7) That 'rational design of commands and command names for usability
requires deeper understanding than is captured in the slogan
"make the language natural."'
What leads to the misinterpretation is that they point out that they have
no direct evidence that the approach of taking moderately familiar words
which they suggest in #5 above will work. It is merely a conjecture they
have drawn. The confusing passage is:
"We have no direct evidence of this conjecture. In fact, the results
of Experiment 2 give little support to the belief that word choice
is of much importance at all. However, as stated previously, we are
reluctant to conclude that word choice would not be influential in
larger command sets used for longer periods."
Given that subjects in the study only learned the Unix (tm) ED editor's
APPEND, DELETE, and SUBSTITUTE commands in addition to the command to start
an exercise (START n), and how to abort the entry of a line (with @), and
terminate input for an insert (with .) virtually *ANY EDITOR* would have
a significantly larger command set! So that warning at the end is very
important. Also, note that although they say their experiment gives little
support to the notion, they do not say that it disproves it. It is very
important in logic, math, and research to remember that there is a big
difference between failing to prove something and disproving it.
So, although it may not matter whether your editor's entire command set
consists of DELETE, APPEND and SUBSTITUTE; or OMIT, ADD and CHANGE; or
ALLEGE, CIPHER and DELIBERATE; if you use have a larger command set it may
make a difference what you chose as command names. Also, they did find that
command syntax could be important.
Mail address : ...decvax!decwrl!rhea!kryptn!ts1!burrows
-------------------------------------------
End Forwarded Messageidallen@watmath.UUCP (11/14/83)
If some people think CHMOD should be "chmod mode file" and others think
"chmod file mode", then either choice will have a bunch of people making
argument-order mistakes. You wouldn't have this problem if you were
allowed to flag the type of one or both parameters:
chmod a b c d mode=0777
chmod m=077 a b c d
chmod a b m=0777 c d
chmod 0777 file=a
chmod f=a 0777
This way, neither you nor the command has to remember the order at all.
Of course, the idea of "chmod mode file file file mode file file file"
can't work, since UNIX files can look just like modes. Even if they
didn't look like modes, the argument order problem is still there. Is it
chmod mode file file mode file file
or
chmod file file mode file file mode ?
--
-IAN! (Ian! D. Allen) University of Waterlooisrael@umcp-cs.UUCP (11/22/83)
From: idallen@watmath.UUCP
Of course, the idea of "chmod mode file file file mode file
file file" can't work, since UNIX files can look just like
modes. Even if they didn't look like modes, the argument order
problem is still there. Is it
chmod mode file file mode file file
or
chmod file file mode file file mode ?
Of course it can work! After all, are the two above cases ambiguous
from a human point of view? All you need is a recognition procedure
for a validly constructed mode definition, and also a couple of
heuristics to use, such as:
1) if it starts with something that could be a mode, it is in
mode-first format.
2) if it ends with a mode, then it's in mode-last format.
3) if its in both formats, or neither, then error.
4) if a mode is also the name of a file in the current directory, and
could be either a mode or a file (in other words, not in either the
first or last position), then ambiguity; print out a message and do
something (continue or exit).
Note that #4 is a new problem (not currently in 'chmod' now) brought
about by the extended paramter parsing. This is equivalent to the
problem 'rm' (and other processes) have of files beginning with
dashes (i.e. 'rm -f' meaning (to the user) 'rm ./-f').
--
^-^ Bruce ^-^
University of Maryland, Computer Science
{rlgvax,seismo}!umcp-cs!israel (Usenet) israel.umcp-cs@CSNet-Relay (Arpanet)idallen@watmath.UUCP (11/27/83)
=======================================================================
From: israel@umcp-cs.UUCP Mon, 21-Nov-83 17:24:50 EST
Of course it can work! After all, are the two above cases ambiguous
from a human point of view? All you need is a recognition procedure
for a validly constructed mode definition, and also a couple of
heuristics to use...
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.
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".
--
-IAN! (Ian! D. Allen) University of Waterloommt@dciem.UUCP (Martin Taylor) (11/28/83)
============
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!mmtlaura@utcsstat.UUCP (Laura Creighton) (11/28/83)
I have been thinking about those long names. They will be a pain to type, right? So I will either have a shorter-to-type private version in my bin, or the command interpreter will understand abbreviations (perhaps like TOPS-20). So the question is "who are the long commands for"? there are people who like Ian Allen, find them aesthetically pleasing. this is all any very good for them, but if this is the primary reason then we can just ask Ian Allen to put long forms in *his* bin... there are novice users. Now, we never settled this the last time, but I still think that novice users have a very short lifetime. Give them a week or a month and they can learn to use "grep" and "cat" like the rest of us. It is possible to design systems for them, but this is (in my opinion) silly. They will be experts too quickly and will have the same complaints about the long names that the rest of us have -- they take too long to type. Thus it is only the marketing types that have "novice users" as their primary concern, since all they have to do is SELL the product -- once they have sold it it becomes the problem of the 'support staff' or some other group... there are casual users. I define casual users to be users that never will use the system often enough to become an expert -- or who use the system infrequently enough that they have to relearn the system every time as if "from scratch". Shoppers using a computerised store directory are the first sort, and professors who use the system once a year to put in a grant request and their latest paper are the second sort. I have come to the conclusion that these people are the primary beneficiaries of the 'long name' command syntaxes. But now that I have isolated (what I perceive as) the problem, I have come to the astonishing conclusion that THESE FOLK DON'T WANT LONG NAMES. These are the people who want menus. They want a pop-up menu with the answer to every possible mess they could get themselves into. Now, what is it that the long words have over the menus... THE MENUS TAKE TOO LONG TO GET DRAWN ON THE SCREENS. (we will assume that you have solved the 'from leaf to leaf I'm want to leap, across the branches I'm forced to creep' problem. It is hard, but not unsurrmountable.) The menus take forever to come up and get drawn. this problem is exacerbated by people who want to make it clear to the user that they knew every feature that the vt100 has, and thus play multiple bells and draw funny pictures in inverse video and play with the scrolling regions. It looks spiff-o but it *takes too long*. The problem with a menu system is that I can type faster than it will give me the menus, so I get pissed off with the whole thing. But this is not an inherant problem with menus. IT JUST MEANS THAT THE HARDWARE WAS NOT DESIGNED FOR MENUS. So if you had real slick fast hardware that didn't think that it was an ascii typewriter you could get a blindingly fast menu system. What if you had multiple windows (a la blits) and if the menu maintaining stuff lived in your terminal... I dunno folks. I think that the idea has merit, but then I haven't heard *anybody* talking about "hardware that thinks that it is a typewriter being user-hostile". I have yet to see the HARDWARE DESIGN raked over the coals as I just did...and there are a fair number of vociferous coal-rakers in the field of human factors... Maybe bitmapped displays are too new, or maybe I have been reading the wrong articles. What do other people think? I have just killed the pro-"long command names" group by assuming that long commands are menu-replacements that are useful only because menus take too long to draw on the screen -- probably that is unfair. But, for the life of me, I can't see what else they are for... Laura (puzzled) Creighton utzoo!utcsstat!laura
idallen@watmath.UUCP (11/29/83)
=======================================================================
From laura@utcsstat.UUCP (Laura Creighton) Sun Nov 27 23:53:45 1983
I have been thinking about those long names. They will be a pain to
type, right?
Right, but what good is a command name that is easy to type, if you can't
remember it? Remember the name first, abbreviate it only when you use
it often enough to need an abbreviation. The abbreviation might even
be a system alias for the long name. Or, it can be a personal alias
chosen when you find yourself using the command a lot. I wonder which
is easier to remember, an abbreviation I choose myself, or one someone
else chooses for me? With long names at least no one is *forcing* me to
remember their abbreviations. And, if I forget my own abbreviation I
can still use the full name...
there are people who like Ian Allen, find them aesthetically pleasing.
Wasn't me that said this. I like them because they are easier to
learn and remember than abbreviations. Less brain work.
there are novice users. They will be experts too quickly and will have
the same complaints about the long names that the rest of us have --
they take too long to type.
Quickly? How will nonsense names help them learn? If you want names that
are easy to type, then do the job properly and assign your favourite 26
commands to letters of the alphabet (very favourite eight to the home
row of the keyboard, of course). Novice users are either going to
remain novices, in which case you shouldn't expect them to use a
command language at all, or else they are going to become.......
... casual users. I define casual users to be users that never
will use the system often enough to become an expert -- or who use
the system infrequently enough that they have to relearn the system
every time as if "from scratch".
Every user who has ever forgotten or had to look up the name of a command
is in this category. There are no "experts"; only experts in some area.
Even our local UNIX gurus don't know all the INGRES database commands that
are in /usr/bin. Any time you go scrambling for the name of a command,
you aren't an expert. You are in need of mnemonic aid for a command name.
You don't need a cryptic abbreviation, you need something you can remember.
Something that works in with all the other command names you know.
I have come to the astonishing conclusion that THESE FOLK DON'T WANT
LONG NAMES.
Research report number?
These are the people who want menus. They want a pop-up menu with
the answer to every possible mess they could get themselves into.
Hey, you forgot to interview me. When I need to do something, I don't
want to have to call for a menu of all possible moves (especially at UNIX
shell command level -- at last count WATMATH had 400 command names out there).
I'd rather that the command names were structured so that I could build
on what I already knew (like deriving debug_pascal from compile_pascal).
I have just killed the pro-"long command names" group by assuming
that long commands are menu-replacements that are useful only because
menus take too long to draw on the screen -- probably that is unfair.
Not unfair, just not true. You can't replace the mental step between
"compile_pascal" and "debug_pascal" with a menu of 400 commands.
--
-IAN! (Ian! D. Allen) University of Waterloolaura@utcsstat.UUCP (Laura Creighton) (11/30/83)
Okay, I have 2 problems. First of all, i thought that the names were supposed to be easier to remember because they were aethetically pleasing. Why are they eaiser to rememeber then? I actually have 14 one letter commands in my bin, so speed of typing is very important to me. All the commands in the editor I know are one letter commands as well. Somehow I seem to remember them. What does the long commnds give you that a really fast menu wouldn't? i thought that the long commnds and the menus were designed for the same group of people. If they aren't then you have isolated a group of people whom I do not recognise. Note, that I do not think that novices become casual users, but that I think that they are two very different groups of people. I also do not think that being an 'expert' is some boolean function like "being alive" where you either are one or are not. What I know about ingres right now could fit on a postage stamp -- but I bet if i had to learn how to use it it would take me a week, after which I would start wanting to have shorter names for things... But I am perfectly willing to admit that my whole problems with "too much typing" would go away if I could get a menu system that went fast enough and was not organised heirarchially (or strictly heirarchially). It is just that the menus take to long to get drawn, so they are more of a pain than the typing. What have I missed here? I still don't know what it is. Laura Creighton utzoo!utcsstat!laura
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/30/83)
I once used a system which had long names with several components, separated by hyphens (don't use underscore, you have to shift to get to that on most keyboards). You could abbreviate any component of the command (as long as the whole thing was unique). This seemed to me to be a pretty good compromise. Thus, I don't have to type compile-p (to distinguish it from compile-c), I can type c-p (which is probably not unique, but you get the idea). But, I can also type out the full name if necessary. This goes together pretty well with the "cross product" theory of command composition. (Of course, it's not clear to me why I really need different commands to compile C and Pascal - the C compiler will only work on files whose names end in .c anyway. So why can't I just have a "compile" command which figures out for itself which compiler to invoke. (Sorry for this nit, it just bugs me sometimes.)) =Spencer
henry@utzoo.UUCP (Henry Spencer) (11/30/83)
I'm afraid I have to go along with Laura. A user who does not know
how to do what he wants does not *want* to have to guess whether he
should type "list", "print", or "output" (to say nothing of "lpr"!)
to get a printout on the line printer. He wants a menu which says,
among other things:
list list contents of current directory
print print a file on the line printer
I hope this example clearly indicates the perils of requiring users
to guess command names, be those names long or short.
Ian! comments "novice users are either going to remain novices...or
become casual users". Wrong, this was just Laura's point: either
they will become casual (i.e., once-a-month) users, or they will
become experienced users. No way will they remain novices (in the
precise sense being used here). "Experienced" does not necessarily
mean "expert" or "knowledgable"; it means "I know how to do the things
I do frequently". This is exactly the right condition for abbreviations
and short commands. When dealing with things she does not do often,
the experienced user (that includes you and me, folks!) is effectively
a casual user, i.e. has no idea how to obtain function "foo". This is
exactly the right condition for menus. Why do you think summary cards
are so popular?
Ian! further observes that he doesn't want to call up a 400-item menu.
This is so ridiculous that I can only class it as a deliberate attempt
to obscure the issue, like the twits who still refuse to install Unix
because "its file system isn't crashproof". Nobody in his right mind
is going to set up a 400-item menu; it's going to be tree-structured,
with a top level set up by general areas of activity. With a fast display
and a mouse, getting to (say) Pascal compilation from there is click,
click, click. Faster than typing "compile_pascal", and no memory needed.
I agree with Ian! that if one *must* guess the name of a command, life
is simpler if names are formed systematically so that guessing is easy
and reliable. The point is that the system should not require me to
guess command names at all!
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrytugs@utcsrgv.UUCP (Stephen Hull) (11/30/83)
Interesting thought:
Ian! said that you can't have the command "chmod 0666 0777" change
meaning on the basis of whether or not there's a file "0666" in the directory.
However, it's perfectly acceptable for UNIX people to have the command
"chmod 0666 0777" change meaning on the basis of whether or not there's a file
"chmod" in the directory.
steve hull
--
UUCP { linus ihnp4 allegra utzoo decwrl cornell
floyd watmath uw-beaver ubc-vision }!utcsrgv!tugs
{ decvax cwruecmp duke research floyd }!utzoo!utcsrgv!tugskoved@umcp-cs.UUCP (12/01/83)
Laura, Your view of the world is too narrow to see over the top of your keyboard. When you go out of the computer room at your school, you may run into many computer users who are not interested in learning about computers... they just want to get their work done. Of course there are the novice users and those executives or secretaries who could benefit from menus. Menus could possibly solve 90-100% of their problems. This is being used in the *real* world. Long command names for commands are not necessary for them since they do not need commands at all. The infrequent users need a way of remembering the commands (which may be the full command name rather than the abbreviated form). Some of the systems I have seen contain several levels of abbreviations and synonyms for the commonly used commands plus personally tailored versions which are automatically added to the system (global) versions. This seems to work rather well when the synonyms and abbreviations are used. In general, a user can use the whole command name (or its synonyn) or its abbreviation. There is a set of users of computers who must contend with multiple sets of operating systems, editors, mail systems, etc. which are operating on different brands of hardware and software. If they must become experts to remember the abberviated forms of all of the commands which they need to commonly use, nothing would ever get accomplished. I find myself lucky that I only use 3 computer systems (with completely different command formats and different names)! I know of people who use more than 3 systems during a week (although I use all 3 almost every day)! This may become more common with the proliferation of small cheap machines. These people want to get work done, but having to learn all of the abbreviations for each of the systems on which the person is working is too much of a burden. From experience, once the salesman has sold the software, the fun just begins! Many places do not have *experienced* staff to install the software and maintain it. If the commands are not spelled out completely, the installer-user becomes confused and frustrated. This is one of the reasons that computers and software have bad reputations (ie: the computer made an error.... not that the person using the computer made an error while using a program). Some of the people using the software are very bright, but are not familiar enough with the computer to understand all of the abbreviations and computer jargon. I constantly deal with people who are non-experts who are trying to install and use software. These problems repeat themselves often. This is not to say that I am against short command names and abbreviations and synonyms... On the contrary! However, they have their place, and must be taken in perspective. Larry
jack@rlgvax.UUCP (12/02/83)
How about taking this discussion off of net.nlang? It really should just be in net.cog-eng.
koved@umcp-cs.UUCP (12/02/83)
.
I think that you missed the point that I was trying to make.
The problem lies when people have to use more than one system at
a time (ie: more than one computer, or more than one software system
on a computer system). If each such system has its own abbreviations
and synonyms for the desired functions, a person would have to constantly
have to consult reference manuals and other sources just to be able to
use each of the systems. This becomes confusting when each such system
has its own editor, text formatter, mail system, file system directory
command, etc. If each such system tends (notice that I have not REQUIRED
each system to be the SAME) to have similar command names (the full name),
it is easier to move between environments.
For example, I may use a computer during the day to do the following
activities:
Document preparation (reports, presentation materials, memos, etc.)
Mail
Database retrieval
Write programs (including writing, compiling and debugging)
Read the news and bulletin boards
If each system had the same command to do a particular activity (such as
print the current information on the terminal) such as the "print" command.
If each system had a different abbreviation, changing contexts (moving from
system to system) would become mentally taxing! How could you remember
what the *correct* abbreviation currently is if you must know which
system you are currently in? If the set of abbreviations is
{p, pr, pri, print, prt, pt}, you would have to do a mental context
swap every time you entered (or popped back into) a different software
environment! I run into this problem frequently when I am using 4 or
5 different editors/text processing applications concurrently.
There is no doubt that there is a need for abbreviations and synonyms,
or menus, or some other time saving devices, but that is no excuse to
reduce commands to 1-3 letter/number abbreviations which can only be
remembered by experts! Remember, as systems become more complex
and sophisticated, the number of experts who know EVERYTHING about
the system becomes smaller. The remainder of the people have to look
up the commands and syntax when they want to tread in new areas,
or areas which are not their area of expertise.
Larry Koved
U. of Marylandspeaker@umcp-cs.UUCP (12/02/83)
With long names at least no one is *forcing* me to remember their abbreviations. With long names, you're forcing everyone who likes short names to use aliases. How will nonsense names help them learn? Some people need long names to keep the meaning associated with the command name itself. Some people have no problem associating the command's meaning with a terse name... even a nonsense name. I like the idea of keeping names terse (for ease of typing) yet descriptive. Better naming conventions are probably what you want... not just longer names. This problem isn't easily resolved since we all need one nomenclature to work with and no one likes the same one. For novices who need help, lists of commands in menus don't quite cut it. Instead of menus of commands and their descriptions it might be nice to have a shell expert-system that interacted with the novice. This could work with pop-up windows for terminals fast enough to handle windows, or in the style of 'write' when used with slower terminals. VMESS has a help facility similar in concept to this, but incredibly primitive. For more advanced users, lists of commands or a terse help facility like that in EMACS would be appropriate. I agree with Laura that a non-hierarchical menu system would be appropriate, the bottleneck is speed and the intelligence of your terminal. -- - Bessie the Hellcow speaker@umcp-cs speaker.umcp-cs@CSnet-Relay
billp@azure.UUCP (Bill Pfeifer) (12/02/83)
Larry, You accuse Laura of a narrow view of the world; let me accuse you of the same! All advocates of long command names seem to overlook one thing: Many, if not most novice users can't touch-type! I have been using a keyboard for many years now, but an abortion like "compile_debug" still takes me close to 7 seconds to type with my hunt-and-peck method. Yes, I know that I should learn to touch-type, but I just don't seem to have the knack for it. I have observed many absolute novices struggling with the insane arrangement of the keys on a standard keyboard, doing almost a linear scan of the entire layout to find each key. I can almost feel their frustration, if after finally typing "compile-pascal" the system wouldn't take it, and they wouldn't know where to get help that told them that the "-" should have been a "_". Personally, I find "pc" much easier to remember than "compile_pascal" (or was it "pascal.compile" or "compile_my_program_which_is_written_in_pascal" or "!@#*&%?/_$^>/@$!"). Did you ever see the original calculator-style keyboard of the PET computer? It cannot be used for touch-typing at all. The explanation that I heard for that thing was that throughout the entire design and evaluation cycle not a single touch-typist saw it. A novice has to struggle with learning and memorizing a lot more than just command names. I remember how I was baffled at first with the idea of the directory structure of UNIX*. There were so many new concepts to learn along with a new set of commands. It doesn't really matter if the new command now is "ls" or "directory", if I'm used to "PFLIST" and "DIR" and "CAT" on the 3 other systems I am using. If I have to memorize a new command anyway, let it be short. Bill Pfeifer Tektronix ----------------------- * UNIX is a Trademark of Bell Laboratories.
liz@umcp-cs.UUCP (12/02/83)
What do you folks think of systems that use long names, but allow you to type something like <space> or <esc> when you've typed enough of the beginning? When you type <space> and you haven't typed a unique prefix, it fills in what it can and (maybe) rings a bell to tell you there's more to type. Such systems usually give you a command to ask what all the possible commands are at any given time allowing you to find out what your options are. I haven't had an opportunity to use such systems much -- the two I can think of right away are emacs when you're typing commands out if full and RIG (Rochester Intelligent Gateway). It seems to me a nice compromise, but I've hardly used emacs (I prefer vi for other reasons) and RIG has a relatively small command set -- just used to connect you out to other machines. I have used ncsh which fills in UNIX commands, but UNIX comands are too short and it takes too long for them to fill out -- and it doesn't know about aliases... I do use ncsh to fill out file names, and I like that feature immensely. Comments? -Liz Allen -- Univ of Maryland, College Park MD Usenet: ...!seismo!umcp-cs!liz Arpanet: liz%umcp-cs@CSNet-Relay
davidson@sdcsvax.UUCP (12/03/83)
Continuing in the context of Laura's analysis, we have (1) novices, (2) experts and (3) casual users to please with our command languages. All but the rankest novices will know at least some commands, and all but the most expert will not know a great many others, especially in a system like UNIX, where a command is any program and there are hundreds of them. If a user knows a command, they will want to enter it in as abbreviated fashion as possible, and aside from the question of how they learned it, they will be better off with short names. Both command completion systems and regular expression abbreviation systems require more keystrokes than short names. Let us suppose that the purpose of large names is to enable users to guess at the names of commands they are not very familiar with. Now the name of a command, even when mnemonic, is fairly difficult to guess, especially when there is a choice of several hundreds of commands. This is a common problem in EMACS, where there are hundreds of commands with long names like case-paragraph-raise (initially capitalize the words in the paragraph), which are similar to other commands like case-paragraph-upper (capitalize all of the letters in the words in the paragraph). The response to this is that if you don't know an EMACS command, you use apropos to find its name. The long names simply become a clumsy way to specify keywords. In UNIX, we have a similar situation, but we have the advantage of short command names and a (slightly) more sophisticated keyword based help system (also called apropos). If you know a command, you want its name and options to be first, short, and second, mnemonic, in that order of priority. If you don't know the command name, you find out with apropos. If you don't know a particular option, you find out with man. Both the command lookup facility and the option descriptions in the manual could stand improvement, but the division of labor is quite efficient. Given the choice to make command and option names as short as possible, it is still important to make them both mnemonic (easy to guess and recognize) and iconic (easy to associate with their meaning). The biggest help here is to have some regularities. For example, the regularity among the compiler names cc, cp, and ct help casual and expert users guess the names. A second big help is option consistency across commands, e.g., l for long, R for recursive, etc. Existing conventions like this need to be documented and stressed, so that new commands will tend to be consistent. As for menu systems, I have used some excellent ones on the MIT and Xerox Lisp and Smalltalk systems. I've used some passable ones on more affordable systems, including the SUN workstation. Window oriented menu systems can be great, as long as one of the windows is a command window! Being trapped in a menu system, or having only one line of historic context in a command window is simply not worth the advantages of menus. -Greg
twh@mb2c.UUCP (Darth Hitchcock) (12/04/83)
BRAVO Larry ! ! !
bbanerje@sjuvax.UUCP (12/05/83)
I'll keep this short.
a) Menu systems would be preferable only in a situation where
1) The menus came up VERY quickly.
2) Are easily assimiliable.
3) Individual items can be easily selected. ( Never having used
a mouse, I don't know how easy it is to point with one).
4) Its possible to escape from the menu hierarchy easily.
b) Due to the tremendous resources tied up in hardware that won't
support these wonderful overlapping windows, etc. We have to
make the most of the glass teletype environment. In this context
short command names make life far easier.
Perhaps the UNIX community doesn't know how good it has it. I've
just been using UNIX for about 2 months, and am quite delighted by
the consistency, ease of use, and indeed the elegance of the command,
file structure. Next time you feel like complaining about something
as minor as an abbreviated command, try UNIVAC 1100 Exec-8 or a
UNIVAC 90 running VS-9. Tends to make one count their blessings.
--
Binayak Banerjee
{astrovax | bpa | burdvax}!sjuvax!bbanerjejudd@umcp-cs.UUCP (12/06/83)
..................
The consensus I see is to have several command interpreters. The user
uses whichever HE finds convenient.
The especialy nice thing about this is that command interpreters must then
*compete* for users! May the best shell win!!!!!
--
Spoken: Judd Rogers
Arpa: judd.umcp-cs@CSNet-relay
Uucp:...{allegra,seismo}!umcp-cs!juddlaura@utcsstat.UUCP (Laura Creighton) (12/06/83)
I think that what umcp!koved wants is Software Tools. You can port the Software tools editor to a dead whale and it will run, which will give you the same editor everywhere. For those of you who *don't* like line editors, I was told at Toronto USENIX that somebody was working on a Software Tools vi. I think that you missed my point again, though. I am not saying that menus are good because they have one letter abbreviations. All the menu systems that i have seen so far are too slow, so they lose no matter how long the abbreviations. What I think is that long names are an attempt to address the same user group that menus adress *faster* than the menus can. Thus they are a good idea given the currently availaible hardware. But that means that the next innovation should not be software, since we have already beaten that horse for a long while, but real fast menu hardware. laura creighton utzoo!utcsstat!laura
koved@umcp-cs.UUCP (12/06/83)
I will agree that if you want to become an expert on a system, then you will probably prefer the short version. It should be available, and I support that 100%. There must be a way for the novice or casual user to also use the system and gradually become an expert of they so desire. That is a problem of how to recognize the command and its operands through synonyms and abbreviations. If you think about it, the commands which are currently used are abbreviations of english words. Let the computer figure out your intent. You can use the very short form if you are an expert, or a longer form if you are a casual user, or the long form if you are a novice. If you can't type, maybe there should be menus to guide you through the system. That would be much faster than trying to type. Larry
neal@denelcor.UUCP (Neal Weidenhofer) (12/06/83)
************************************************************************** Has anyone else used a console on a CDC-6XXX or Cyber? They use an interesting and useful (in my opinion) algorithm. For each letter you type: 1. If the letter doesn't fit a known command, it is ignored and NOT echoed to the screen. 2. If the letter does fit, it is echoed, accumulated and either: 2.1. If more than one letter can immediately follow the given letter, the system waits for more to be typed. 2.2. If the next letter (or the next n letters) can be inferred from what has already been typed it is (they are) displayed and assumed to have been typed. Similar to some ideas already suggested but WITHOUT needing ESC or whatever to ask the system to look. 2.3. If the letter (including any letters inserted by 2.2.) completes the command, the command is displayed in "flash mode" and waits for a new-line or parameters. This would also take some intelligence in the terminal--probably comparable to a menu system, but it's an interesting alternative to consider. Regards, Neal Weidenhofer Denelcor, Inc. <hao|csu-cs|brl-bmd>!denelcor!neal
israel@umcp-cs.UUCP (12/07/83)
From: neal@denelcor.UUCP
Has anyone else used a console on a CDC-6XXX or Cyber?
They use an interesting and useful (in my opinion) algorithm.
For each letter you type:
[ Algorithm paraphrased for brevity ]
Complete as much as can be completed automatically, on a
character by character basis, and ignore any illegal chars.
I don't know if I like this scheme (though I've never used it, and
that's the real test of whether I would like it!) because of the
following situation.
Basic assumption: command names are long (if they weren't this'd be
a pretty ridiculous algorithm to bother using).
Say I'm a casual or even expert user and I know the commands. I want
to compile my pascal program with 'compile_pascal_program'. I would be
more likely as a reasonably fast touch typist to try typing the whole
command. So I type the 'c'. Since the only commands beginning with
'c' are 'compile_*', it fills in the 'ompile_' and waits for me to
continue. I type the 'o' which it ignores, and then when I type the
'm', it automatically completes out to 'compile_modula_program'.
A possible habit to build to fix this situation (while retaining fast
command typing) might be for expert users to remember where it
automatically completes and type the exact string which completes to
what they want. For example, an expert might type in 'CPA' with the
command looking something like 'Compile_PAscal_program'.
This case is no better than the short mnemonics, since it is
obviously equivalent. Also, I think you end up remembering two
commands (the long version and the short version) instead of
one. Another point is that any time a new command gets added to
the system the completion map changes.
I think that this scheme can be very handy for novice users (but still
does not really answer the problem being discussed, since the novices
don't know the command names to begin with, unless the naming convention
is extremely regular), but not very comfortable for casual or expert
users.
It could become useful for experts only if the system was so fast that
it had effectively instaneous completion time. If the user ever has
to wait more than the time it takes him to type the next key, it would
probably be more bothersome than anything else.
How about some feedback? Did you use it much and what level user were
you? Any people out there who have used the above systems on an
expert level? (By the way, the above opinions on the effects of such
a system are totally my own and are not meant to represent my
department, the University of Maryland, the state of Md, the USA, North
America, the Earth, this Solar system, this universe, or any other
entities of which I may be a part :-) )
--
^-^ Bruce ^-^
University of Maryland, Computer Science
{rlgvax,seismo}!umcp-cs!israel (Usenet) israel.umcp-cs@CSNet-Relay (Arpanet)kjm@ut-ngp.UUCP (kjm) (12/07/83)
This is in regard to the Cyber console command fillout technique
quoted by denelcor!neal (immediate interactive fillout of commands
as far as possible and rejection of unidentifiable characters).
The Cyber program which does this (Dynamic System Display) is able
to fill out commands in real time because it is resident in one of
the twenty PP's (Peripheral Processors -- sort of a programmable,
very intelligent I/O channel controller). This capability would
likely raise load averages into orbit on computers with only one
processor, because a hash table of all built-in commands and all
executable files in the search path would have have to be scanned
in processing the first character, all entries starting with that
character would have to be scanned in processing the second, and
so forth. Better yet, the technique used to handle a backspace
is to delete the last character from the input buffer and restart
the command scanner (overhead!). Finally, to do this at all, this
shell would have to run in CBREAK mode (yuck!).
Shredder-Of-Hapless-Smurfs
(or) Ken Montgomery
...!{ihnp4,ctvax,seismo}!ut-sally!ut-ngp!kjmellis@flairvax.UUCP (Michael Ellis) (12/07/83)
Why is all this cog-eng crap in the `natural language' newsgroup? It really belongs in net.religion, if you ask me... -michael