Iyfjky

Question

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

Is there any 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.

The title's a little off; DOS does use English words. There's directory, echo, copy... The question's pretty good, though; I can guess, but I don't actually know the answer. — 2 hours ago
How about "ShowMeAllTheFiles,filesizes,fileAttributesinThisDirectory" then"? (Yes, it's a little long, but says exactly what it does) ;) - But you could insert it into a batch file called DIR.BAT to save yourself some typing ;) — 2 hours ago
@tofro - I get what you're saying, a lot of typing compared to dir /b ;). I was just wondering, because in more sophisticated programming languages it's a good idea to write clean code, descriptive variable and method names, small methods. To a new comer or someone starting to maintain a system that uses batch files and cmd, they might come across dir /b and not understand it, but that's why we have the manual. — 1 hour ago

score 2 · Accepted Answer · 2018-09-21 15:52:43Z

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 60s and were designed to run in very little space, e.g. DOS-11 ran on a PDP 11 with 8K 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, 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). Its only because of changing technology in the interim that the choice of command became obscure.

+1 - Essentially the same thing I said, though you provided a little more detail. — 2 hours ago
It is interesting enough whether CP/M inherites some of its shell commands from somewhere else, probably from OS/8 (DIR, PIP for example). And whether MSDOS inherites something from RT-11 or similar PDP-11 shells. — 2 hours ago
Apple DOS uses CATALOG D1. We had programmable keyboards to cope with that nuisance. — 1 hour ago

Will Hartung 2,532615 · Answer 2 · 2018-09-21 16:40:34Z

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?)

I know I could say "Alexa, turn down the volume". But it's far more effective to just rotate the knob. — 1 hour ago

Jeff Zeitlin 47727 · Answer 3 · 2018-09-21 15:50:39Z

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.

Raffzahn 34.5k477137 · Answer 4 · 2018-09-21 18:32:45Z

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 begining a rather plain CP/M clone, which itself was created with DEC systems in mind. Other, later (2.0) additions where taken from Unix. From a developer point of view it was more import to get the system running than to think about (maybe) more apealing command names.

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

On 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 a command like 'SHOWALLFILESONDISK' ist a nonsensical bloat - and equaly 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 more clear what exactly the code is doing.

Wouldn't that be just helpful 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 screw up typing even these short commands? Every additional letter 26-folds the chances of geting an error instead of a result.

A good CLI is always a compromise between shortness and the support of memorizing them - and regularity to crossreference (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 aplicable, right? Except it would be a different short name on different machines and resulting in a real Babylon effect of noone being able to tolk to a different computer as his own - as by then, the long names used during learn phase have been vanished from memory, and guessing about name and spelling starts ove.

Not realy foreward looking.

A little mainframe anecdote here.

In the late 1970 Siemens tried to push their mainframes (/370ish) into the mini range and targeting office applications. They invested almost more money into a crating good education/user manuals then in downsizeing the machines (*1). The basic idea was that DEC, DR or others made their users successfuly use some cryptic command line, so why not using the even more complex ... err ... powerful BS2000 command line :) The project floped part due the hardware, but equaly due the fact that the targeted Users aren't doing personal computing. They use company applications and never touched a command line.

Forceing the micro/mini based concept of a command line to use seperated, 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 realy nifty menue system was created. While ease usage for first time users, it became a lump foot to more experianced ones. Several revisions of the system happened in short time until it got burries with the whole project.

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

Not much later complains about an ever growing complexity the command line (there where function with dozends of arguments) together with increasing cost to implement new commands and/or parameters needed for new functions resulted in a project to redo the command system/interpreter. A realy nifty system to structure the command interpreter as well as command and parameter modules was developed. It work quite well and proved adain, 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 moree than double with the new system.

Except, management (guess who *3) also came up with the idea of a way more user friendly command language. Instead of stupid pseudo language commands (and them even abrivated), a much more clear 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 about how to crate 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 to get attributes of a file turned into a typing Session:

Old:

/fs <filename>,all

New:

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

There where many good reasons to do this, not at least the interpreter structure. Now a command an all it's parametes where defined in an unambigous 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 invoced, thus releving the function program of many, many statements. The improvement on the OS development side was unpreceded. And they couldn't understand why reaction on the user side was considerable less enthusiasic. Not at all.

To be fair, they were aware that this is much to type, sothe system also included a method to shorten commands to the least amout 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 identifyer. In above case this would shorten that to:

/s-f-a <filename>

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

This proofed even a true bug breeder for batchjobs. While most 'official' jobs where done with the long form, the usual quick typed scripts did more often than not use the abrevation its programmer prefered (*5). We all seen these scripts not just used once, but surviveing for years in production environments. Don'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 hard to detect and to correct, still a dangling Damocles sword ofer all jobs.

To make it worse, the now way longer commands made abrevations almost mandatory. The command line is limited in length to 72 characters per line and allows only a certain amount of extension lines. So 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 attribues about devices to use, access rights and alike was originally possible within a single FILE command, making it not just compact (and hard to read), but also atomicon the file system. Except for rather simple cases the new syntax required several different commands to first create it, then assign attribures and alike, but also several of them, as complex cases couldn't fit a simgle command line. All while hoping that all other processes wtching the file system would be able to cope with these intermediate states that could not have happened before (*6).

Heck, it wasn't all that bad - or at least it wouldn'T seam 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 involvment of the function. These screns even allowed menue driven point and clock alike completion with nicely formated fields for all usable parameters and so on. Except, to do so the terminal was switched from line into form mode. Somethign a CLI user hates. Not just because of a different handling metaphore (thing about a CLI window just poping up a modal box to be handled with the mouse) destroying the flow, but also because the screen was cleared afterwards, so no easy use of any former line to copy and reuse. Some users realy developed a neurosis about not geting the help screen (*7).

Oh, and to close the cicle, it also got a staircase wit: People introduced today (well, after 1990) complain a lot about the total unimaginitive bourocracy and unhandy nature of this CLI - and blame it on been typical mainframe complex.

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

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

*2 - Which again is usual in large companies.

*3 - I don't have proof for that claim beside being tols so back then. So while it sounds truthish, it might not be true

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

*5 - It's much like the problem I mentioned in the answer abotu private naming conventions for batch files ment to shorten the typing.

*6 - 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 independant (and older) transfer process did not include handling for a file with attrbutes set only partly the way it was expecting them. As this softwaer 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.

*7 - Later on it was made optional and regular error messages where displayed - but then again, instead of a simple line like Filename missing` a structured analysis was presented ofer up to a dozend lines - again killing most of your screen.

score 2 · Accepted Answer · 2018-09-21 15:52:43Z

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 60s and were designed to run in very little space, e.g. DOS-11 ran on a PDP 11 with 8K 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, 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). Its only because of changing technology in the interim that the choice of command became obscure.

+1 - Essentially the same thing I said, though you provided a little more detail. — 2 hours ago
It is interesting enough whether CP/M inherites some of its shell commands from somewhere else, probably from OS/8 (DIR, PIP for example). And whether MSDOS inherites something from RT-11 or similar PDP-11 shells. — 2 hours ago
Apple DOS uses CATALOG D1. We had programmable keyboards to cope with that nuisance. — 1 hour ago

Will Hartung 2,532615 · Answer 6 · 2018-09-21 16:40:34Z