idallen (07/27/82)
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)
G:wing (07/28/82)
VAX/VMS (no flames, please!) is a very human command language. ALL of the commands are words. The abbreviated forms of these commands are just that, you simply drop letters at the end of the command word until VAX/VMS says that you are ambiguous. RUB OUT is the erase character here and a very logical one. The only problem I see is that one, the error messages aren't worth much (If you have a copy of DecWars, they have one in the text), and two, the changing of erase character between UNIX and VAX/VMS has killed this news item a number of times and occasionally screws up one of my commands in VMS!
idallen (07/30/82)
It was said (populi.261 from G:wing) that VAX/VMS is a very human command language. The text of the article went on to state that all VMS commands were words, and abbreviations just abbreviated each word. This may be true, but if this article was meant to be a followup to my article on bandwidth and encoding, then the point of my news item was missed. (I do try to make myself clear, but it's not easy!) The followup article might reasonably argue that VMS has a human-oriented *abbreviation scheme*; but, the article does not give any evidence that the unabbreviated *language itself* is human-oriented. My main point was that we mistake bandwidth-improving encoding schemes (abbreviation is one such scheme) as being *language design*. Everyone is saying how wonderful their abbreviation scheme is; nobody is saying how wonderful their *command language design* is. I don't much care how easy it is to abbreviate the EXPUNGE_DATASET_WITH_QUERY command, if I can't even remember that it is the command I have to use. I strongly believe that the *first* requirement for command language design is to make the language *memorable*. Once we remember *what* we want to say, we can, at our leisure, learn encoding (abbreviation) schemes to speed things up at the keyboard (or mouse, or ...). -IAN! U of Waterloo (decvax!watmath!idallen)
G:wing (08/04/82)
To make a rebuttal to the last news item posted on this subject from ARPAVAX:CSVAX:mhtsa!eagle!harpo!decvax!utzoo!watmath!idallen : The command language for VAX/VMS IS memorable, at least to a point. Some things are a little weird, i.e. using a command file, deleting something from a queue, but are for the most part memorable. The help system on here is somewhat cryptic, but it is pretty good and has fast response, unlike "man." One main reason for the site I am at (not Populi, but RIX) chose VAX/VMS is that it DOES have a more human oriented command language that one can understand. Another reason was that some of the possibily better system available when this system was booted up for the first time were not available for VAX-11/780's. And, by the way, I didn't miss your point, you missed mine... Live Long And Prosper, and May The Force Be With You. The One And Only, Philip L. Wing U.C. at Berkeley ETA Region IX/DOL P.S. If you know how to send stuff by mail to the Lawerence Berkeley Laboratory Vax/Unix, you could probably bounce something to RIX. My account name there is the same as here...