Is there a reason why MS-DOS didn't use more English words for commands?

Question

When using diskpart, I can list all the drives by typing LIST DISK or to select a specific drive I can type select disk 1.

Is there a reason why MS-DOS didn't use more English words to do tasks, for example, to list all of the files in a directory with no additional information, I can do this:

dir /b

Why couldn't the developers have made it so that I can type view insertdirectorynamehere -bare?

It's a little longer to type, but it's a little more clear what exactly the code is doing. Insert it into a batch file that can take command line parameters and you can save yourself some typing.

Answer 1

MS DOS inherited many of its commands from CP/M. CP/M was designed with influences from classic minicomputer operating systems, especially those produced by DEC. Many of these systems dated back to the mid to late 1960s and were designed to run in very little space, e.g. DOS-11 ran on a PDP 11 with 8 KB of RAM. They were also mostly designed primarily for programmers, not end users.

This meant that the influences drawn had terse command structures, often using as few characters as possible, and users were expected to understand and appreciate the precision of using technical terms.

You can see the influence of this on DIR, as in your example. It shows the directory of a disk (CP/M and early DOS versions only supported a single directory per disk - nested subdirectories were a feature added in DOS 2.0). "VIEW" could have been ambiguous - it may have shown the contents of a file instead.

TYPE is another good example, but for a different reason - it printed the contents of a file (early versions of CP/M were intended for use on a teletype, not a visual display). It's only because of changing technology in the interim that the choice of command became obscure.

Answer 2

Because typing is awful.

Having to type "select folder" or "change directory" or anything else like that gets very tedious, very quickly.

The commands are meant to be used to express the users wishes to the computer, they're not designed to be necessarily used to communicate between human beings.

In truth "change directory" is no more intuitive than "cd" or "wd" or "F1" or double clicking on that folder thing in the window, especially when the user has no concept of what a "directory" is in the first place. It all needs to be trained up.

Also, there's the usage of the programs. Consider the CP/M pip command. "Peripheral Interface Program" (or something close). Regardless of what the command is called, this is a particularly arcane multitool to try and figure out and use.

Computers are not the commands, they're concepts. The concepts are (demonstrably), even after all this time, quite difficult for folks to grasp. No matter how much lipstick you paint on these things, they're still computers underneath.

Today, we have the momentum of 40+ years of history, so there's motivation today to keep things "similar". So as not to have to relearn vocabularies. Take a look at the UCSD P-System. It used "English" for everything (almost, it's menu driven), but to someone used to how things work today? It's not an intuitive system at all. It's assumptions and preconceptions don't match what we're used to today. However, to someone who never used a computer, I'm sure it may have been easier to adopt. But in the end, an advanced user isn't looking at commands at all. "FC" becomes F)ile -> C)opy.

If you've ever watched someone learn a computer system, they, in general, do not know "why" they do something, only "What to do". This was starkly demonstrated to me when I saw someone learning a hotel management system. The instructor described the interface, the menus, the organization, all this taxonomy of structure built in the system. Meanwhile, at the end, the student basically said "So, to do XX I pre F6, right?" That's all they wanted to know. All of the rest, none of that took.

In the end, we want to express ourselves succinctly to the computer. Repeatedly typing long treatises to the machine is tedious, slow, and error prone. For the same reason we don't like listening to voice response menus at customer support, once we know the system, we don't like typing long strings of commands if we can possibly avoid it. And since any system needs to be trained upon anyway, in the end many of the commands don't matter, as long as they're remotely mnemonic. (But even that's not true, how is typing 'ant' to compile a program intuitive or mnemonic?)

Answer 3

Is there any reason why MS-DOS didn't use more English words to do tasks,

The most obvious one is that MS-DOS was in the beginning a rather plain CP/M clone, which itself was created with DEC systems in mind. Other, later (2.0) additions were taken from Unix. From a developer point of view it was more important to get the system running than to think about (maybe) more appealing command names.

This as well worked with early users, as they were coming with a great majority from CP/M (and some from Unix) and didn't have to relearn everything, only the newer/different features. That's way less work than learning a whole new system.

In the long run this is also quite important for international sales. While commands like DIR, CD or DEL are based on English words, in itself they are just a few letters to memorize. No English required. In contrast to a command like 'SHOWALLFILESONDISK' is a nonsensical bloat - and equally hard to read/learn for anyone speaking English as well.

Why couldn't the developers have made it so that I can type view insertdirectorynamehere -bare? It's a little longer to type, but it's a little clearer what exactly the code is doing.

Wouldn't that be helpful just in the early learning stage? If at all?

After all, the command line is to be used in direct dialog. Here, short easy memorable commands are king. Remember how often you screwed up typing even these short commands? Every additional letter 26-folds the chances of getting an error instead of a result.

A good CLI is always a compromise between shortness and the support of memorizing them – and regularity to cross-reference (See story below)

Insert it into a batch file that can take command line parameters and you can save yourself some typing.

Which then again would get of course a short name, to make it applicable, right? Except it would be a different short name on different machines and resulting in a real Babylon effect of no-one being able to talk to a different computer than his own - as by then, the long names used during learning phase have been vanished from memory, and guessing about name and spelling starts over.

Conclusion: Such a CLI wouldn't be forward looking.

---

A little mainframe anecdote to add:

In the late 1970s Siemens tried to push their mainframes (/370ish) into the mini range and targeting office applications. They invested almost more money into a creating good educational/user manuals then in downsizing the machines (*1). The basic idea was that DEC, DR or others successfully made their users use some cryptic command line, so why not use the even more complex … err … powerful BS2000 (*2) command line :) The project flopped partly due to the hardware, but equally due to the fact that the targeted users weren't doing personal computing. They used company applications and never touched a command line.

Forcing the micro/mini based concept of a command line to use separated, rather minimal applications instead of integrated software, did not only not bring the promised cost cutting, but also produced unsatisfied users. As a last effort some really nifty menu system was created. While it eased usage for first time users, it became a lump foot for more experienced ones. Several revisions of the system happened in short time until it got buried with the whole project.

So far the usual. Except (*3), the ones responsible stayed with the company, close/within OS development.

Not much later complaints about an ever growing complexity of the command line (there were function with dozens of arguments) together with increasing costs to implement new commands and/or parameters needed for new functions resulted in a project to redo the command system/interpreter. A really nifty system to structure the command interpreter as well as command and parameter modules was developed. It worked quite well and proved again, that a complete redo of something, that has been grown over years, is a great idea. Productivity of the OS development related to command execution did more than double with the new system.

Except, management (guess who *4) also came up with the idea of a way more user friendly command language. Instead of stupid pseudo language commands (and those even abbreviated), a much more clearly readable, writeable and memorizable command language should be used. And of course with way less parameters to make it easy. As handy it is, there was also a project about that at a German university on how to create such a language in a systematic way, using tools to define and handle that. So that was also brought in.

As a result, even simple things like getting the attributes of a file turned into a typing Session:

Old:

/fs <filename>,all

New:

/show-file-attribues file-name=<filename> (*5)

There were many good reasons to do this, not the least the interpreter structure. Now a command and all its parameters were defined in an unambiguous way (using a DSL) that could not only be used to check for valid commands, but also take these checks out of each function into a centralized command interpreter doing all needed syntax checks before the function gets invoked, thus relieving the function program of many, many statements. The improvement on the OS development side was unprecedented. And they couldn't understand why reaction on the user side was considerable less enthusiastic. Not at all.

To be fair, they were aware that this is much to type, so the system also included a method to shorten commands to the least amount of letters needed to identify it correctly. Also, at least parameters that had to be always included (like the file name in above example) could be given without their identifier. In above case this would shorten that to:

/s-f-a <filename>

Great, except, this is an especially simple example, and even here it doesn't work as simply, as there is also a set-file-attribute command, so abbreviation must be rather sh-f-a And here lies the real issue for humans. To decide which abbreviation is possible and which not, one needs to know all existing commands. There was no structure (as with MS-DOS or other hand made CLI). A human could deduct it, but it had to be learned. And relearned when new commands, conflicting with his memorized abbreviations came up.

This proved even a true bug breeder for batch-jobs. While most 'official' jobs were done with the long form, the usual quickly typed scripts did more often than not use the abbreviation its programmer preferred (*6). We have all seen these scripts not used just once, but surviving for years in production environments. Haven't we? In case of the command syntax system in use this would mean each of them could fail with any new OS release without any prior warning. Not only hard to detect and to correct, still a dangling Damocles sword over all jobs.

To make it worse, the now way longer commands made abbreviations almost mandatory. The command line is limited in length to 72 characters per line and allows only a certain amount of extension lines. With all these lengthy parameter names, this maximum was easy to reach. So not just quick and dirty procedures did sit below the sword.

Creating a file (entry) with certain attributes about devices to use, access rights and the like was originally possible within a single FILE command, making it not just compact (and hard to read), but also atomic on the file system. Except for rather simple cases the new syntax required several different commands to first create it, then assign attributes and the like, but also several of them, as complex cases couldn't fit a single command line. All while hoping that all other processes watching the file system would be able to cope with these intermediate states that could not have happened before (*7).

Heck, it wasn't all that bad – or at least it wouldn't seem so at first sight:

The systematic command definition allowed the addition of a help screen system not just showing general messages, but giving way detailed information what is wrong with the command typed - all without any involvement of the function. These screens even allowed menu driven point and click alike completion with nicely formatted fields for all usable parameters and so on. Except, to do so the terminal was switched from line into form mode. Something a CLI user hates. Not just because of a different handling metaphor (thing about a CLI window just popping up a modal box to be handled with the mouse) destroying the flow, but also because the screen was cleared afterwards, so no easy to use of any former line to copy and reuse. Some users really developed a neurosis about not getting the help screen (*8).

Oh, and to close the circle, it also got a staircase wit: People introduced today (well, after 1990) complain a lot about the total unimaginative bureaucratic and unhandy nature of this CLI - and blame it on being typically mainframe-like complex.

Long story short: OS-development has been there and it turned out to be less than desirable.

---

*1 - The later resulted in what was the most unreliable and least sold of all of their mainframes, the infamous CoCo - here meaning Compact Computer, despite the fact still being the size of several table height refrigerators.

*2 - BS2000 is still around, now owned by Fujitsu. In my opinion eventually the best OS design ever. Ok, given, I should limit this to 'best internal structure and design ever'.

*3 - Which again is usual in large companies.

*4 - I don't have proof for that claim beside being told so back then. So while it sounds truth-ish, it might not be true

*5 - Looks much like the OP asked for - even more readable with hyphens separating real words, doesn't it?

*6 - It's much like the problem I mentioned in the answer about private naming conventions for batch files meant to shorten the typing.

*7 - I had one case like that in a real customer application, where one (redone) job was creating a file in a transfer directory. The complete independent (and older) transfer process did not include handling for a file with attributes set only partly the way it was expecting them. As this software was third party and a (mostly) closed system it took me quite a while to figure out a sequence to make both of us happy.

*8 - Later on it was made optional and regular error messages were displayed - but then again, instead of a simple line like File name missing a structured analysis was presented over up to a dozend lines - again killing most of your screen.

Answer 4

It seems that an important fact is missing in the answers here:

Almost all commands in MS-DOS (and most other operating systems) are in fact filenames. The length of filenames where restricted to 8 characters on MS-DOS (and CP/M, from where many commands where taken). Up to MS-DOS 6.22 they still used only 8 character commands List of all MS-DOS commands

The filename is also an explanation why the commands are single words: space was for a long time a no-no in filenames, even when filenames longer that 8 chracter started to be used most systems had problem with space in a filename.

Historical note, some systems had even shorter filenames that restricted the length of commands even more. (RT-11 on PDP-11 is one example: 6+3 characters per filename)

Answer 5

The reason for short commands has been re-stated several ways here. But there's one critical detail missing from all of the answers: diskpart was introduced after Windows NT was developed.

Windows NT is based on many of the core concepts of Digital's VMS. Dave Cutler - the chief system architect of VMS - quit Digital (DEC) in 1988, and Microsoft hired him and part of his team to develop a new enterprise-grade OS.

In VMS, most complex commands could either be executed as interactive commands with their own shell, or by specifying the command with enough options from the terminal. MS-DOS had previously borrowed DEC's / as an option specifier, so the convention was already familiar to PC users when it was used in Windows NT's shell.

All of VMS's commands could be shortened down to the shortest unique identifier (with occasionally puerile side-effects, especially for larval VMS admins like I was). While you could type out the commands in full (helpful in scripts you were going to reuse) it was usual to shorten commands down to the bone.

Answer 6

A lot of very good answers here, but one point that I haven't seen mentioned... Back in the day, line editing was very primitive. If you got one character wrong, your only option was to backspace to delete until your mistake. And no opportunity to recall previous commands to edit and fix the mistake.

Of course, input on a teletype was even more of a pain. So short commands made sense.

Answer 7

Most of MS-DOS's commands were inherited from CP/M and UNIX, both of which used cryptic commands to conserve space (resources were at a premium in those days - 16K of RAM and 10MB of disk space was considered A LOT! - and expensive to acquire). Since MS-DOS was also operating under resource constraints, it made sense at the time to use the same sort of compact commands, plus, it increased familiarity and made the transition from those older systems to MS-DOS easier. To this day, CMD.EXE on Windows maintains that compatibility/familiarity, even though resources aren't at that kind of premium. PowerShell, however, breaks that paradigm, and provides longer, more descriptive commands.