From a UX perspective, terminal consoles have a few key advantages over GUI’s. These advantages are rarely relevant to end-users, which is why CLI’s are used almost exclusively by technical users and “power users” these days.
Things done in a terminal are easily repeatable.
Imagine needing to configure 5 computers for some purpose. For this small number, it’s probably not worthwhile to create an automated solution to configure them all. You’ll just tweak the settings of each.
On a terminal, it’s simple to copy and paste the commands. On a GUI, you might get familiar with where the configurations are stored, but may still be left with a fair deal of clicking. Mistakes are more likely.
This also is relevant to documentation and technical help. Providing four lines to copy and paste into a terminal console might replace a couple paragraphs of explanation of how to click into various admin tools (especially since the GUI directions might only be perfect for one of several interfaces, see “GUI interfaces are countless” below).
Tracking/auditing is easier
A command-line interface (CLI) retains a record of what you’ve done, which you can easily extract and keep. When something goes wrong your boss asks, “Are you sure you did it exactly right?” you can have evidence to prove you did. Even if you did make a mistake, you can more easily see it and learn from it.
Scripting/automating is nearly as easy as entering commands
Everyone knows how to use a mouse to open a file in a GUI. Far fewer people know how to make that happen automatically. With a CLI, automating the task can be almost as easy as typing it in by hand.
Technological Constraints can still make CLI’s compelling
Logging into a GUI box remotely requires a fair deal of bandwidth, and latency (delay in the connection) can make the experience frustrating. A CLI remote login has a much lower bandwidth requirement, since it is just transmitting a little text back and forth. And latency is much easier to deal with when you are typing, than when you are trying to hover a mouse over an icon.
A CLI can be used for Input/Output
Some have called this The Age of the API, where systems are built on top of systems. A CLI allows a similar interoperability. In the question’s example about Git, it would be possible to hook another “enterprise system” – such as a defect tracking system.
Compared to a SOAP or even Rest API, CLI commands can be easy to develop and test.
There are just a few standard shells; GUI interfaces are countless
If you log into the GUI admin interface of a few different web hosting services, you’ll probably see that they are all different. It’s not hard to poke around and figure out where everything is, but it takes time. Next year, the host may have upgraded their solution, and now everything is in a slightly different place — one more thing to learn.
That hosting service probably still uses the same CLI. The new version is backward compatible with the old. Users familiar with Bash, PowerShell, or whatever CLI is on the system can eliminate the ramp-up time spent familiarizing (or re-familiarizing) themselves with that particular GUI.
In short: command lines are language; language gives expressiveness.
An example of a text interface that you use: Google Search. Imagine if you couldn’t type your queries as text into Google, and had to select documents you wanted from a menu of choices (like the erstwhile Yahoo web directory).
Jakob Nielsen, the usability expert and user-experience researcher, wrote with Don Gentner an article called “The Anti-Mac Interface”:
Gentner, D., and Nielsen, J.: The Anti-Mac interface, Communications of the ACM 39, 8 (August 1996), 70–82
In it, the authors point out deficiencies in many principles that go into “GUI” interfaces. For example,
The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It’s as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don’t exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).
If we want to order food in a country where we don’t know the language at all, we’re forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef.
The whole article may be worth reading, and contains many answers to your question.
So language (a command-line) lets you have a richer experience. But as you say, this does not mean that language is better, as illustrated this example that (probably coincidentally) neatly turns the above example around:
Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.
— Joel Spolsky, User Interface Design for Programmers, p. 76
Which is better, a GUI or a text interface? The text interface requires more time to learn, in return for being more expressive and powerful. Whether it is worth it to you depends on how long you intend to live in that environment, and how rich an experience you’d like to have.
The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language.
Note that learning the “command-line language” (a Bash-like shell in a Unix-like environment, or perhaps the Windows equivalent) opens up to the learner at once a large number of potential experiences. So many have chosen to invest in this learning, and I for one can say it has paid off handsomely.
Finally, to answer your question on why services (such as hosting services) advertise text interfaces as a feature: imagine you’re in a foreign country where very few speak English, somehow struggling with gestures and the like, and you see a sign on an establishment that says “We speak English here”. (Similarly, depending on where you live, you might have seen signs saying “Se habla español”.) The advertising you mention is similar: for those who are literate in the command-line “language”, this amounts to an invitation that they can expect to have the rich experience of being expressive, without being limited to the graphical interfaces that have been already thought up and implemented.
The long version
The answer’s basically included in your question itself:
a user needs to memorize hundreds or thousands of commands
Switching that to hundreds or thousands of buttons would not be an improvement in usability (and even if done would be much much more limited than the text command line.)
If you tried to build a GUI general-purpose enough to cover every task that gets done in a terminal window, your GUI would be either be unusably complex or unusably limited in functionality for a significant subset of your users. Take your examples, for example: “one-click install” is great if all you want is the default settings, but it’s insufficient for anything else. Editing a single file in a terminal may look complex, but terminal users routinely chain multiple text utilities together for specific purposes; working at the command line is usually a lot more similar to writing short, single-purpose programs than it is to clicking a button to perform a predefined task.
Most tasks which can be improved by moving them from the command line to a GUI, already have been — if you don’t want to use nano (or vi or emacs or whatever) there’s no shortage of GUI-based text editors to choose from, for example. (Though if you’re already on the command line and just need to make a quick change, it’s quick enough to just type vi and make that quick edit without ever reaching for the mouse.)
But nobody’s ever going to write a GUI able to, say, find all the files within a specific directory whose name matches a given pattern, then perform a search-and-replace within them, wrap the originals in a tarball and push it to another server — because that would be an insanely overspecific task for a GUI to handle. But when you do need to do something specific like that, it’s simple to pipe together a few UNIX utilities to do so. And to capture that in a shell script so you can do it again every week from now on.
Developers need to do insanely overspecific stuff like that all the time. The terminal is the most efficient and easy to use UI for that sort of task.
The short version
The command line trades away discoverability, in exchange for efficiency and flexibility.
The user has to have learned the commands ahead of time, they can’t just dig around in menus and toolbars to find them as in a GUI. But once learned, all of those tools are a just handful of keystrokes away, and can be combined in novel ways as needed (while in a GUI every task has to have been thought of ahead of time by the designer.)
Followups in response to comments
The comment threads throughout this question have been culled a couple times now for chattiness, but since the same points seem to keep coming up, I’d like to address them here:
- You don’t really need thousands of commands, twenty or thirty will do.
True! Sort of. The problem is the 20 or 30 commands you need aren’t necessarily going to be same ones the next guy needs — a simplified GUI containing only the subset of commands you routinely use won’t be sufficient for that other guy; and won’t work for you either, the first day you need to do something that isn’t routine.
(Secondarily, once you account for all the various commandline options on each of those commands, as well as the ways they can usefully be piped together, you’re really at a lot more than 20 or 30 interactions that would need to be supported in your personalized GUI…)
A GUI has to be designed to a particular purpose. The command line by contrast is general purpose — it can be all things to all people, because if the functionality you need isn’t built in, you can add it yourself.
- That example you gave of an insanely over-specific task that nobody would build a GUI for: somebody did.
True! I walked right into that one, yup. I changed the example to make it slightly more insanely over-specific (but no less plausible).
GUI wrappers have been spun off for plenty of command line tasks, and certainly are useful (I spend much more time in the github GUI than using git on the command line, for example) — but each of those is just one subset of the many types of tasks the command line is used for; my point there was more that no reasonable GUI could cover all, or even anywhere close to most, commandline tasks. (Or, heck, even those for just
git itself; I do still frequently need to drop back down to the command line for things the GUI front end can’t handle.)
- Discoverability (“The command line is more discoverable than you think” / “GUIs aren’t as discoverable as you think”)
I’m using the term “discoverable” in its strict sense here: a new user can figure out how to use a program by just using the program. i.e. if you just bang away at it for long enough, you’ll be able to figure out how it works without resorting to external resources. (I am definitely not saying that that’s the only or the best way for a user to learn how to use something; just that it’s a potential advantage GUIs have over the CLI.)
I will happily concede that poorly designed GUI interfaces don’t necessarily facilitate discoverability.
I don’t agree with the several comments (some deleted, some still current) suggesting that the command line does facilitate discoverability, to any real degree. If you have to read the
man page in order to figure out how to use a feature, that’s not discoverability; that’s learning. Which is great, but it’s a different thing. I don’t think there’s enough consistency in the command line options for various tools to make the argument that learning one tool helps you understand the others; and there’s no reasonable way for a CLI user to discover the existence of tools they don’t even know about yet (no,
ls /usr/bin doesn’t quite cut it; that’s more analogous to “give me the index to the manual, in alphabetical order”.) There are some helpers and shortcuts, such as tab-completion, but those are more useful as a reminder after you’ve learned something than they are as a way of learning it in the first place.