When you start scripting with macros or automation tools, you've just left the limits the GUI imposes for a CLI environment, with all that entails. That's not a disagreement, that conceding the point.
Nothing stops a "GUI app" from having a CLI or vice versa, though I observe that generally an app can be fairly cleanly identified as considering one or the other the "primary" interface, with the other a clear afterthought/second priority.
> you've just left the limits the GUI imposes for a CLI environment
Not all macro and automation systems are text-based. Automator and Photoshop actions both let you create user-defined behavior by combining primitives while still taking advantage of the discoverability and spatial layout of a GUI.
In other words, GUI apps can and do incorporate CLI elements. But CLI apps cannot incorporate GUI elements like click-to-select. So would it be accurate to say CLI apps are more limited than GUI apps? Or is the point in the article about forcing people to use CLIs so that they have to know about the more powerful features(or give up trying to use the program)?
Or does he mean it's a good thing to replace the car's interface with a bunch of strings like a guitar that allow you to steer, brake and accelerate and change gears and this will allow for more creative driving? As I said, the article is not even wrong.
Too strong. You've defined "GUI" as something that can include CLI elements, but then turned around and defined CLI as being unable to include GUI elements, so you end up in a tautological circle.
A "CLI app with a GUI" is something like emacs in X11 or gvim, where the GUI is clearly a second-class citizen/afterthought, but it is there. Alternatively, you can look at something like the various Linux apps for ripping DVDs, which are mostly nothing but GUI shells around various transcode and mplayer commands, and it shows. To the point that I once bashed one of them into doing what I wanted it to do, rather than what it wanted to do, by exploiting a command-line injection in the so-called "GUI" to inject a command-line parameter that superseded one of the earlier ones the program jammed in without asking me. (Subsequently I scripted up a simple rip that meets my usual use case, but the GUIs are nice when I want to save subtitles or something and it's harder than just one mencoder call.) Considered as a system, these are GUIs around underlying CLI apps that do the real work.
A GUI interface can include CLI elements because it is technically capable of showing a CLI interface.
If a CLI interface can include a GUI, can you use it over in a SSH terminal? Or on a Linux box without X(or the equivalent) and all it's bloat being installed? Or on Windows 2008 Server Core? You're pretty much redefining CLI at this point and cutting away some of it's advantages too, like being able to run on very low power devices like routers etc.
"If a CLI interface can include a GUI, can you use it over in a SSH terminal?"
Yes, you can use every bit of functionality in all the software I cited over SSH, you just don't get the GUI. (Excepting anything purely GUI-specific, like opening a new window in emacs, but that's a small set of targeted commands.) That's why I cited those examples as CLI apps with GUI overlays. I could cite some others, too, like fetchmailconf, a GUI for fetchmail that is optionally used for configuration of an otherwise fundamentally CLI app. Unix is full of these things.
Nothing stops a "GUI app" from having a CLI or vice versa, though I observe that generally an app can be fairly cleanly identified as considering one or the other the "primary" interface, with the other a clear afterthought/second priority.