381–390 of 439 posts
Earlier quoted context omitted.
what if your mouse doesn't have two buttons? In fact, some mice don't have any buttons. (apple, over the years)
That's apple's problem. I've been fixing apple devices since the puck mouse. They choose to go against the grain on purpose. Sometimes it makes sense and sometimes it makes absolutely none.
$ find . -print | sed -e 's;[^/]\*/;|____;g;s;____|; |;g' # on MacOS
Earlier quoted context omitted.
You can't undo a file-move in (most?) GUI file managers either.
Windows Explorer, macOS Finder, KDE Dolphin, and GNOME Nautilus all beg to differ. The issue is that tasks on the CLI tend to be split between many different utilities. So you'd either need a standardized method for sharing an undo tree between the different utilities, or alternatively to integrate all the different tasks under a single program.
+ foo
+- bar.txt
+ bar
+- bar.txt
That's not a problem with the GUI paradigm, that's a problem with the current implementations of it.
Current implementations of CLI/TUI programs have many problems themselves: lack of undo, poor discoverability, low intuitiveness, no previewing (e.g. in the equivalent to file browsers), poor documentation (which makes the discoverability and intuitiveness problems worse), and so on.
Moreover, with that context,
> require more resources
...is a very poor reason to use them. Computers are meant to be useful, not to sit there saving compute/RAM/electricity.
(I shouldn't have to add this here, but: obviously, if you have two identical tools but for the fact that one consumes less power, then of course I would say you should use the latter one - this is not that scenario)
Most the things in this list are things that you technically don't need a GUI for, but a GUI is so much better that doing it in command line is pointless. For instance, you could do all those file operations in the terminal, but chances are you're already browsing files using a GUI file manager so opening a terminal to do those things is pointless. Terminal is great if you want to do something complicated that a GUI…
I am the opposite, haven't used a GUI file manager in...15 years? I am most certainly not "already in it". (Ok, with the exception of wanting to look at a bunch of images in thumbnail mode. Then I launch a GUI file manager.) The shell is where I "am" and launching a GUI seems more cumbersome than typing the command. In fact reading this post made me realize that using the terminal for file operations is not as common…
Once learned the GUI actions are impossible to forget. Being away from the computer for two weeks will make you forget 80% of the CLI commands from the author's list. The reason is simple: the brain can associate the GUI actions to many concepts from the real world. CLI concepts exist on computers and nowhere else. That knowledge is too abstract and too expensive to be kept unused in our brain's cache non-stop.
Some peoples' brains (such as mine, I believe) are more wired to be symbolic. I suspect that, for these people, using a textual-command-oriented CLI interface is going to be noticeably easier/more intuitive than those whose brains are wired to be more visual/kinesthetic/whatever else there might be.
I don't think that it's very strongly weighted towards "transferability toward other real-world concepts". The modern GUI interface doesn't seem to share many characteristics with non-computer parts of the real world.
GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks) TUI/console is very good for interoperability…
>GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file... You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use. The concept of a context menu that pops up at the mouse position when clicking button number two is not intuitive or discoverable.…
> they often require more resources, are less powerful and hard to automate via scripting That's not a problem with the GUI paradigm, that's a problem with the current implementations of it. Current implementations of CLI/TUI programs have many problems themselves: lack of undo, poor discoverability, low intuitiveness, no previewing (e.g. in the equivalent to file browsers), poor documentation (which makes the discov…
This is more common with CLI than with TUI, and its largely because the former are generally aimed at lower-level use than TUI or GUI applications.
Why is it that we're so much better at consistency in GUIs than programs? We all know ctrl+c/cmd+v and friends. We all know right click. We all know where preferences tends to live and what people are likely to put under the file or edit dropdowns. Compare that to learning new non-GUI tools (shell or libraries), and you start from square one. The only thing I can think of that's universal is "--help"
Meanwhile, new and inconsistent GUI interfaces tend to drive away non-programmer users...which results in a competitor eating your lunch.