> 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

> 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 I think that's more a design-problem than actual trait of GUIs. GUIs have evolved that way, but there is no reason why they can't support composing and interoperability too. MacOS, KDE and Web-UI showed how it's possible to do. It's just that nobody ever went to the full way to build a GUI-Framework from ground up that is reaching the same level of automation as shells. > TUI/console is very good for interoperability/automation/muscle memory, TUI and console is not the same. TUI is a GUI inside the terminal, thus usually only with text. Vim, emacs, mc or any curses-app is an example of TUI. And how well can you automate and support interoperability with them really? As I know, all the automation and interoperability comes from the devs adding it on purpose, it's not there by design, or as easy as with a shellscript. > If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info. To be fair, GUIs can also have complex workflows and undiscoverable features. It's just common sense that GUIs have menus for every possible action. A GUI is a canvas, and there are established languages which creates frameworks of content which you should paint on this canvas. But this doesn't mean you speak one of this languages well or even at all.