No matter its (horrible) aspect or its age, the Command line interface (CLI) concept is bad because of its inherent defects, since the very beginning.
historical imperfections
An important aspect of the Command line concept is it is a human-machine interface, just like the Graphical user interface.
So they are in competition, they are not two completely different things as many think, at a theory level.
Nevertheless, they are very different in many aspects. Their differences are not only how they look, but how they work.
Another difference is how they grew.
While the GUI was researched, thought and built in laboratories, and well thought, the Command line interface has an erratic and slow evolution inheriting habits from the typewriters and of the teleprinter machines.
Since obviously a computer is not a simple typewriter, the concept should have evolved along the time, but unfortunately it did not much. In place, the GUI has replaced it for most users.
But, strangely, the Command line did not disappear, mainly because of conservatism and because of its main qualities: scripting (automation) and ease to make simplistic console software.
It is a matter of fact that the GUI concept does not include any kind of automation.
And making a GUI software requires more work, or was it true at the beginning of its era.
The problems
As a single command
Complexity of the parameters
Simple parameters can be used by humans, but from a certain amount of parameters, it is way more difficult.
Just imagine 10 complex parameters in a single line of text.
Or more complexity in the syntax.
For example:dpkg-query -W -f='${Installed-Size;10}t${Package}n' | sort -k1,1n
This command line calls two different programs and contains not only parameters and values, but sub-parameters (as “Installed-Size“).
The syntax is not really comprehensible to humans !
You can notice this syntax is a bit particular to the dpkg command, they apparently needed that to express sub-parameters (a non-standard feature).
No real standard for the parameter’s prefix
On Unix, they are prefixed with a “-” or a “–“, when on Windows it is a “/”.
Unfortunately on Unix a “/” is a file or directory path delimiter.
So, the Command line concept lacks multi-platforms uniformity.
Syntax elements are numerous
- “-” and “–” are parameter prefixes.
- “/” is a file or directory path delimiter.
- “*” and “?” are the wildcards, allowing file or directory multiple selection.
- “>” and “<” are the redirection system.
- “|” is for the pipeline system.
And I will not list all of them, because they are incredibly numerous, and it seems each new year new elements appear.
They multiply quicker than rabbits !
So imagine a command line using a combination of all of these possibilities.
That’s scary.
Difficulty in discriminating syntax elements from text values
Now, imagine the value of a parameter contains a “-” character. How can the program decode it ? Is it a parameter, or a value ?
The same for all syntax elements.
Difficulty with international characters
By international characters I mean characters for the whole planet. Unicode is here to help us.
Not all operating systems manage well international characters in their shell, causing wrong interpretation of the parameters and of the values.
Between commands
Communication between programs is not easy
Programs exchange information by files or by text, not by structures or classes (objects).
These texts and files must be decoded first, which can lead to misinterpretation.
This concept does not exist in GUI either, but it exists in some platforms, as Corba or Com+.
No event concept
When a program A calls a program B, A have to wait for B to end its work, there is no communication by events. B can not tell A what is it doing, and A can not ask B anything while B is running.
In the GUI, event and communication are natural by concept. In CLI, there is no natural concept of communication, each program/command is isolated.
As a script
The worst are the shell scripts, mixing command lines and programming lines.
What a mess of syntax !
A wrong concept in the language theory field
All those imperfections are the clues showing the whole syntax of the Command line interface concept is pointless and wrong.
This syntax should have been replaced for dozens of years by a better one, in fact by a well-designed one.
Some better syntaxes
Many more correct text syntaxes already exist, and for many years.
Among them, a well-known one is XML.
At least it has no lame syntax. It is rather well organized and stays reasonably readable for a human.
it is not new, it appeared about 1997, but it is based on the SGML (created in the 1960s).
It is time for a better command interface
I advocate for a new syntax, usable by both the users and the programs.
I am not sure XML is the best choice, but at least it is a possibility and it is well-known.
We will take it as a base in this discussion.
It is a bit more adapted to program communication, due to its verbosity, but stays comprehensible by humans.
And it is easy to make a GUI XML editor specialized to the command line use.
Example
In place of this command line call:dpkg-query -W -f='${Installed-Size;10}t${Package}n' | sort -k1,1n
We could have something as:
<pipeline> <command value="dpkg"> <options> <showwarning/> </options> <query> <field> <installedsize value=10 /> <type value="package"/> </field> </query> </command> <command value="sort"> <key> <position1 value="1" /> <position2 value="1n" /> </key> </command> </pipeline>
It is much longer, but much clearer for someone who knows XML.
So to address the remaining imperfections, we need:
An XML specialized editor with Command patterns
Here a pattern is a kind of definition of what parameters are accepted by the command, and its options.
In XML vocabulary, it is a schema. One of these is XML Schema.
With this help, a specialized (GUI) XML editor could help user a lot to build a command call, using code completion and predefined templates for major usages.
And I do not mean a raw text XML editor, but a graphical parameters tree editor.
The advantages
- Each command (program) will publish a syntax pattern, which can be used as a short documentation.
A standard parameter<givepattern/>tells a command to write it, no need to add an external file to each command. - Standard options, as:
- Version number of the pattern used and published.
- Obsolescence warning, in the pattern.
- Native implementation of international characters.
- Sub-parameters.
XML is naturally hierarchical. - Existing concepts will be available.
I mean: pipelining, wildcards, redirections, etc.. - No ambiguities in the parameters and their values.
- Parameters analysis by the command program is a lot easier.
- Version tolerance: upward and downward compatibility.
A newer or older parameter can be ignored by the command program, if wanted. Just as in HTML.
That is preferable to just causing an error in the command and crashing it.
Of course, that depends on the XML validation choice we make.
The pattern concept allows a command to tell what is compulsory or not in its parameters and options.
In fact this concept allows many possibilities and can be extended in the future, as any XML-based format is extensible.
And this concept will work with both pure-text programs & GUI programs.
Communication in XML between programs
It appears logical that the concept replaces the text communication of the traditional Command line concept by an XML communication.
Traditional commands produces files and text, which can be used by the next command as an input for its processing.
So xml commands should communicate though binary files, xml files and xml text.
That would avoid the heavy and complex particular syntax analysis and allow high-level communication.
Maybe something like SOAP.
What for scripting ?
Historically, the script languages come from the single Command line concept.
A script is basically a collection of command lines.
My example in XML can be copied several times and put altogether in a single XML file, that is fine and no problem in XML. The resulting big XML file would be the equivalent of a basic script.
Comparatively, in the Command line world, the script languages have evolved and now they are close to be general programming languages. Some kind of specialized programming languages.
In XML, the most logical would be to create a complete language as well, and not a simple collection of commands.
As for what happened for the GUI, I think that language should be built on good theories, not as a hack as are some clunky languages.
This language does not need to be a general programming language (there are so many already), but just a limited specialized language.
I don’t know many XML programming language for now, only some attempts and researches [1].
A benefit to create a new language is to add new possibilities, as parallel programming for example.
What in a live console ?
Of course, it seems quicker and more efficient to enter “ls *.odt” than to enter a large bunch of XML code.
Well, it would be true, with an ordinary XML text editor.
But imagine your execution window (equivalent to a console) is equipped with a code editor.
- You type “ls” in it,
- it selects the most probable correspondence (the “ls” command), and proposes parameters on the right of its window,
- you enter “*.odt” in the file field and let the other parameters empty.
- Then hit the Enter key.
If you count, you hit these keys: “ls”, Tab (to go to the first parameter field, which most probably is the file name field), “*.odt”, and Enter. Exactly the same number of keys than for “ls *.odt” !
So, no, this kind of XML is not slower than a simple text interface, it is just a lot more clear.
It is a matter of having the right tool.
So what ?
In the world of open source, the usual answer to critics and to suggestions is “Why don’t you do it yourself ?“.
Of course, I could do this kind of project, for example building a layer on the standard commands of Unix and Windows, but I don’t think it would be so nice.
Since this concept is associated with operating systems, all of them, it will be a success only if it is well-designed, is a consensus, and is a common work.
The first step to reach this goal is to think all together.
And the step just before that was to write this suggestion here.