From: utzoo!watmath!idallen
Newsgroups: net.works
Title: Bandwidth, encodings, abbreviations and command language.
Article-I.D.: watmath.3102
Posted: Tue Jul 27 16:17:45 1982
Received: Tue Jul 27 23:52:26 1982
References: sri-unix.2264

We argue here over ways to make it *easier* and *faster* to do *more*
with *less* typing, less reference to manuals, less guesswork.

Bandwidth -- that's the central issue in command language design.
People argue over schemes that will remain friendly and mnemonic and
also provide high bandwidth (usually, less typing).

To maximize bandwidth without regard for memorability, simply assign
the first 26 most heavily used commands each to a single letter of the
alphabet.  Minimum typing, but hell to learn and remember!

I have seen no discussions about how to maximize memorability without
regard for bandwidth.  How do we write a command language that is
really *easy* to learn and remember?

Not everyone wants to learn a command language that is optimized for
speed and brevity.  To want to learn such a language, the investment of
time spent learning it must produce a day-to-day saving that is worth
it.  It's not worth it to me to Huffman-encode my command vocabulary
to reduce the number of keystrokes to the absolute minimum!

Let us be careful to distinguish how command language is used
	1) when you know how to do something, and
	2) when you don't know how to do something.

When you know how to do something, you may be willing to learn an
encoding scheme (such as abbreviation, command-completion, adoption of
terse aliases) to make entering the known sequence of commands faster.
If you are willing to spend time memorizing an encoding scheme, it
doesn't much matter which one you choose.  I think the type of scheme
used will depend on personal taste.

When you don't know exactly how to express your needs in terms of the
names of commands that will do the job for you, then you aren't at all
interested in fancy encodings.  Your first objective is to get the task
done.  Speeding it up can be learned later.

We all start life using command language in the second category.
We all find ourselves in the second category at some time,
wondering just what the name of that command was that did such-and-such.
We know *what* we want to do, but don't quite know *how*.

The few command languages I've seen (UNIX, Honeywell TSS, VM/CMS,
IBM/TSO, CP/M) seem to echo the sentiments of many people on this
News Network -- they are already semi-encoded for speed.
They allow abbreviations, and all kinds of neat stuff.
But nobody has told me what the design of the underling command
language is.  How am I to remember even the unabbreviated command names?

I must insist that a language be designed to be easy to learn and remember.
I should be able to guess how to do things once I understand the model.
I see a lot of emphasis on abbreviations and encodings that allow
command language to be typed conveniently.

But, what is the underlying design of the language that everybody
is trying so very hard to abbreviate?

	-IAN!   U of Waterloo    (decvax!watmath!idallen)