I think a better analogy, though maybe not perfect, is a knife vs a tomato slicer[1].
Tomato slicers are safer, their features are more discoverable, and they're even easier to use, but they're bulky and less versatile.
Having gotten comfortable with a knife, I like that it's easier to keep clean, takes up less space, has far more uses than slicing tomatoes, and doesn't require complicated mechanisms to adjust the width of slices.
Knives are dangerous, yes, but I think most of us already easily handle that level of danger every day.
I'm in love with this analogy. Too many modern GUI applications are the software equivalents of 'unitasker' kitchen gadgets. However I must note that not all GUI applications have this problem; a few exceptional examples stand out as being knives, not unitaskers. Excel is a classic example. In fact, I consider Excel proof that when programmers of GUI applications don't sneer down their noses at users who aren't professional programmers, it is possible to create very powerful and flexible GUI applications that empower those non-programmer users to implement their own custom solutions to novel problems.
Sometimes I wonder if Excel could even be invented in recent years. Could you ever get an application like that past "UX experts" who think users should to be treated like idiot children?
Following the same analogy, I think Excel would be a rice cooker. You can do lots of things with it, like cooking rice, steaming vegetables, making soups, etc. You're right that it's not a unitasker, but in contrast to CLI utilities, it's not meant to be composable. With CLI, each tool specializes in doing one thing well and composing with other tools to do more complicated things. Using CLI equates to making your rice, soups and steamed vegetables with a stove, pots, lids, and steam baskets. The benefit being that you can use each of those things for more than just making your rice, soups and steamed vegetables, specially when composed with other tools, things that the rice cooker isn't prepared to do.
If you ever wish to fry some food, you can't with the rice cooker, but you can with the stove. You can compose it with a pot or a pan depending on your need.
Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line. *nix CLI for example is not an ideal of uniformity ([0]) and simplicity. It's not at the same level of simplicity as your common household knife, at least.
[0]: `--opt=val`, `--opt val`, `-opt=val`, `opt=val`. First two are usually interchangeable but sometimes not. Third one was completely unexpected for me (clang uses a mix of first, second and third). Forth one is easy, only `dd` uses it.
> Sledgehammer is an allegory for cognitive burden of checking and rechecking the code you write in a command line.
The way you write that makes it sound like you're taking several seconds to read and re-read commands you've written tens of thousands of times before. It doesn't have to be like that. Not every command is risky, and checking for mistakes takes an instant. If you're paying attention to what you're typing, you can know what you've written is correct even if you're not looking at the computer or keyboard. It's just about practice. The more you use the command line, the less mistakes you make.
Also, I find that use of GUI also carries significant cognitive burden, because there's is more room for human error, and I can't always rewind what I've done to recheck. With the CLI, I can scroll up or check my history to see exactly what I asked the computer to do, but when using a GUI, things are more manual, and there's no always-available equivalent to scrolling on the terminal or checking history, as if I had a Tivo on my desktop.
For example, using sqlite on CSVs versus working those CSVs on a spreadsheet program. Let's say I want to remove rows where a certain column is a certain value. In sqlite, I would just translate that last sentence to SQL and tell it to sqlite, leaving it in history and my terminal window like a chat conversation between me and my computer. In a spreadsheet, I think the natural thing to do would be to sort by the column, select the range of fields I see that have the mentioned value in the mentioned column, and delete them. Let's say I save, turn off the computer and leave. Then the next day, I would wonder if I could have possibly moved the mouse a little more than I should have, selecting one more row than I should have and deleted something I shouldn't have. Spreadsheets have undo/redo (by per-app convention only), but it probably doesn't save that undo history across reboots. So that information is lost. I'd have to compare the CSV I saved with the original. In a CLI, I would just look at the history of what I did yesterday and read (in SQL) "remove rows where a certain column is a certain value", and with that I can be sure that that mistake would have been impossible.
In other words, with CLI, I just need to make sure I'm translating what I want to code appropriately, and I'm free from the burden of caring about the possibilities for human errors, like those possible when working manually with data in a GUI.
> nix CLI for example is not an ideal of uniformity [...] `--opt=val`, `--opt val`, `-opt=val`, `opt=val`.
That's very rarely a problem. I don't forget the syntax of tools I'm using day by day. It could only happen on new tools or ones that I haven't used in a very, very long time. If I really am not sure of something like the syntax of options, I'll just give a quick check in the manual. Takes less than 5 seconds.
Also, I think GUIs are even less uniform. For example, it used to be that by convention, every GUI program had a menu-bar at the top, but for Firefox and Chromium now, probably the most used GUI programs worldwide right now, the menu-bar is basically non-existent. We now get a hamburger button or a vertical ellipsis button to our right. The interface is very non-standard. The guys who built Blender, the 3d modeling program, were also very creative in how they designed the GUI, with their splitable tiling subwindows. I don't know of any other interface like it. Gimp is also very unique in having different windows for differing things in the same running instance of the program. MS Office introduced the ribbon interface to replace the toolbars it had before.
Honestly, in comparison, I think CLIs are very uniform. The interface is much more restrictive, and doesn't allow for as much creativity.
> simplicity. It's not at the same level of simplicity as your common household knife, at least.
I think you're confusing simplicity with ease of use. CLI is simple like a knife and GUIs are easy to use like a tomato slicer. A knife is not easier than a tomato slicer, and a tomato slicer is not simpler than a knife.
Why is a CLI simpler than a GUI: Because for any one task, a GUI program's code will be mostly about the management of the GUI and have little to do with the task it's supposed to do, while a CLI program's code will be mostly about the task itself. The reason for that is that a CLI is super super simple. You take a list of string arguments, maybe read from stdin, maybe write to stdout or stderr, and return a status code. That's basically it. A GUI on the other hand, needs to create windows. redraw them regularly, listen for input, decide to play an animation over widgets when some event happens like when you hover over a button with the mouse, etc. If you check what a CLI program asks of the OS while it's running (via strace for example), the requests are normally very relatable to what the program is supposed to be doing. If you did that with a GUI program, you're going to be bombarded with the amount of system calls it makes for GUI shenanigans.
A second reason why a CLI is simpler is that CLI tools are composable while GUIs are not. This means that CLI tools can be made for very fine-grained functionalities. For example, you can't split a basic GUI file manager into multiple GUI programs, but can make a bunch of CLI utilities that handle the various tasks of a GUI file manager. Because they're so focused on a granular task they can solve it better. I mean, who's going get a better solution for the searching of files? A GUI file manager developer that needs to also cover many other things like file copy and move, or a CLI utility developer that is making a utility like `find` that is solely focused on finding files? CLI utilities are simpler because they're focused because they're composable.
CLIs are very much like knives: simple, versatile, composable.
