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 Taylorphil@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!philchuqui@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/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 Waterloothomas@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
speaker@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
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
twh@mb2c.UUCP (Darth Hitchcock) (12/04/83)
BRAVO Larry ! ! !
judd@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!juddellis@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