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)