One common question, upon seeing someone working in a terminal is,
"Why don't you use a nice-looking, easy-to-use GUI software instead?"
And a perrenial related question discussed among developers is along the lines of,
"UI or CLI, which is better?"
People have argued on either side (e.g. see random threads and blog posts from a cursory Google search here vs. here).
This post outlines several reasons to prefer command line interface (CLI) software to GUIs (graphical user interfaces).
Before diving in, and as a pre-emptive strike against possible debates this could spark, let me begin by saying that the first question above is a valid one (cogent, relative to discussion) and focuses on preferences, while the second question above is what we in philosophy call a false dilemma. False dilemma is a logical correlative fallacy in which a tension is built between A vs. B, as if A and B were the only choices, when in fact many (likely infinite) other options exist. For example, UI vs. GUI is a false dilemma beause it leaves out all but those two options, when in practice virtually no one exclusively uses only CLI software (even sysadmin folks need to resort to GUIs for some, to various, computing needs after all!).
Thus, in reality, the most practical and logically sound conclusion we can draw about the "UI vs. GUI?" question is that in computing we should always use the best, most suitable tool for a given job. It will be up to us to determine the best choice in any given case.
Here are eight good reasons to prefer CLI software (Table 1 below), ordered according to a few broad categories of considerations:
Table 1.
| Reason | Category |
|---|---|
| 1. Disk size | Physical (Computer) |
| 2. Memory usage | Physical (Computer) |
| 3a. Interaction speed | Physical (User) |
| 3b. Computational speed | Computing performance |
| 3c. Compilation speed | Computing performance |
| 4. Efficiency | Productivity |
| 5. Design(ed) constraints | Design / Utility |
| 6. Interoperability | Design / Utility |
| 7. Customization (flexibility) | Design / Utility |
| 8. Learning and metacognition | Education / Personal growth |
CLI software generally, in my experience, is lighter and smaller in overall size and hence occupied disk space than GUI software. Given that GUI softwares are often combinations of technology producing a platform overlying the CLI or the Linux kernel core (or similar), it stands to reason that CLI software should be lighter. This is not often a major consideration, given the ever-expanding disk storage capacity of standard desktop and laptop machines (not to mention affordability of external hard drive space), but it is an advantage over GUIs nonetheless.
Given the many graphical components of GUIs, they intrinsically require more memory (Random Access Memory, or RAM) to run than CLI software programs.
Two of the main limiting factors at play in determining GUI computing speeds are mouse or trackpad movement and click speeds. Given that you have to move your hand further and expend more energy to move the mouse around (or access and press down on a trackpad) while also interacting with the keyboard when using a GUI, whereas CLI users interact with the keyboard nearly 100% of the time, interaction speeds are slower for GUIs as compared to CLI software. This is a clear win for CLIs.
CLI programs also tend to be computationally faster than GUI software because they do not need to worry about tracking or altering graphics, and they do not necessarily need to log output to screen (which, if done while running interactively, could produce megabytes of information printed in the terminal, which thus also will increase memory usage of the terminal window).
It is well known that CLI programs generally take less time to compile than GUI software, because the CLI softwares themselves produce very little usage drag on resources like RAM.
Efficiency and speed are often contrasted, sometimes confused. The Oxford Languages dictionary (via Google) defines efficiency as
"the ratio of the useful work performed by a machine or in a process to the total energy expended or heat taken in."
Here, we see that while speed is the rate at which an action is performed, efficiency is always a ratio--a ratio of work performed against total input of energy or resources. Speed matters, but it is not the only thing that matters, and faster is not always better, is it?
Since interaction speed, and many times also computational speed, is greater for CLI software (see above), this means that users of CLI software can accomplish more work more quickly, increasing the numerator of the efficiency ratio above. Specifically, this improves the efficiency ratios for CLI software by increasing the amount of work performed (or possible to perform) per unit energy or resources expended (e.g. time).
Additionally, the greater interaction speed of CLI software also has the separate effect of reducing the total input of energy required to do work (over the period of time of performing a task), which further improves efficiency ratios for CLI software by decreasing their denominators.
The greater efficiency of CLI software, as compared to that of GUIs, can easily be seen by considering the following classic example. In our thought experiment, we consider the simple use case of producing and saving a new file containing one line of content (e.g. 'Hello world.'). Under a GUI-based approach, this would require several operations, and in describing them we will consider 'mouse' and 'trackpad' to be synonymous. These operations include 1) using your mouse to click on and open the desired text editor or word processing software; 2) waiting up to 1-3 seconds for the GUI software to open (e.g. loading graphical elements); 3) data entry to add the file's contents, typing 'Hello world.'; 4) clicking on "Save As" from the dropdown (usually "File") menu or obtaining the "Save As" window via keyboard shortcut; and 5) data entry of the desired filename (e.g. 'helloworld.txt'). At the CLI, this is trivially simple and can be accomplished as simply $ echo "Hello world." > helloworld.txt, which takes equal to or less than the amount of time for steps #1 or #2 in the GUI example above.
While GUI software programs are thought to be technically more flexible than CLIs, due to their visually appealing options buttons, windows, and drop-down menus, the level of such flexibility is undeniably case-dependent. We all know that the actual level of constraint imposed by any given GUI or CLI software depends on the goals and skill level of the developer(s), as well as the amount of options coded into a given release.
With this being said, you might elucidate a sound argument for why CLI software are in many cases actually less susceptible to the pitfall of imposing limitations on the user, due to design constraints, than their graphical counterparts.
For example, we can defend the assertion that it is easier and takes less time to add options to CLI software programs, because no time is required to add new graphics or GUI features.
As a counterpoint, one might argue, "But dumbed-down GUI packages that provide wrappers for CLI scripts or major packages abound for several major coding languages, for example including Python." This is still a problem because beginning developers will struggle with the pages of documentation tied to these GUIs, making them time-consuming and difficult to implement. Even building GUIs with GUI packages takes more time than simply writing stable CLI software. For Python, PySimpleGUI appears to remedy this, providing an easier-to-use GUI development approach, but even it has considerable documentation (see the cookbook).
Command line tools can be run on multiple different operating systems (OS's) because the needed portability context and interoperability tools are already built. For example, you can run POSIX-compatible sub-systems and run-time environments on any of the major OS's. Standard environments such as Cygwin provide a system that uses bash as the default shell, just like on most UNIX/Linux distributions, and also have many GNU and UNIX utilities (e.g. sed, awk). These environments typically even have UNIX-like directory structures. This means that UNIX/Linux CLI software should be portable to Windows machines running Cygwin. Thus, it is nearly just as easy for CLI tools to cross over between OS's and platforms as the "universal" languages for writing and building great GUI software that work on basically every machine, such as Java.
When CLI programs are provided as free Open Source software (OSS; e.g. on GitHub) rather than binaries, they are completely "hackable" and easy to edit and customize, lending them an added dimension of flexibility. Of course, this can also be said of GUIs distributed as OSS, or OSS distributed in both GUI and CLI formats.
Nevertheless, and by contrast, some CLI software and many GUI software programs are proprietary and distributed in closed-source format, and this means that these programs cannot be easily tested, hacked, or debugged. The user is simply at the mercy of the individual or company for support including ongoing development (e.g. new features and patches for bug fixes or changes breaking forwards/backwards compatibility).
Here, OSS CLI software may still have the advantage because it is easier to edit and customize CLI scripts, and users are more likely to know how to code from the get-go. Their source code is 100% out in the open, like all OSS. Whether the script/program can be directly customized in a given case just depends whether the user can code in the language that the program was written in.
One complaint about CLI tools is that they supposedly have a 'steeper learning curve' and no one can remember what commands to use. After all, this is why GUIs were created in the first place (right?)--to improve accessibility and reduce training time.
While this sounds rather egalitarian, in reality, the 'learning curve' is something everyone must overcome in the early stages of learning and working with any software program. For complex software, the difference is essentially between clicking around a UI to find the right series of operations or options (GUI software), versus (possibly regularly) referring to the man pages or help text (CLI) to find the information you need. In this regard, both kinds of software aid in personal growth of a computer user.
The advantage in education and skill that one can receive, after spending more time working with CLI software, is in part simply the greater familiarity that one gains with the command line, in general, which is a great asset.