Are we really having the GUI vs CLI holy war on HN? Here's how to deal with this question.
1) Design a nice DSL to express whatever it is you want your users to be able to command.
2) When you build the GUI, have all the gestures correspond to a particular DSL expression.
3) Add a shell where the user can type arbitrary expressions in your DSL (and for that matter, load files with DSL commands and execute them).
You're done. People who want a GUI have one, people who want a CLI have one, and there's a nice clean upgrade path from the GUI to the CLI. In fact, that's where this approach really shines: when a GUI user decides he needs to automate something, you can give him a single clear expression to type for each gesture he's used to making, and at first he'll probably just memorize those and use your product in exactly the same way with the CLI as with the GUI. Once he gets used to the CLI itself, he'll probably start tweaking the basic expressions you gave him and eventually feel comfortable enough to write his own. It's a nice security blanket for people who are basically learning to program to have a set of magic spells they're confident they can use no matter what.
This is basically exactly what Emacs does--every single GUI action, be it a keyboard shortcut, a menu item, a mouse click or even a touch gesture[1] maps directly and very unsubtly to an elisp function. This means you can go from just using Emacs like a normal text editor do doing really complicated things with elisp in a relatively straightforward way.
Coincidentally, I don't see how Emacs is a CLI program, even if it does have a text-only mode: the text-only mode just draws the GUI elements with text the way other programs draw them with pixels. Of course, it's a tool heavily optimized for power users, but that's a different story.
But the argument here seems to be that forcing users to use the CLI will make them use the more powerful features that they won't otherwise use with a GUI that's good enough for them. Or something like that. The useless analogies in the article don't help.
That's my point - in my book this is a solved problem. The GUI vs CLI thing tends to be a religious argument, which (in computing) always means that you actually want both.
I agree the original article is pretty nonsensical, I was just trying to prevent my having to read an overly familiar argument again.
1) Design a nice DSL to express whatever it is you want your users to be able to command.
2) When you build the GUI, have all the gestures correspond to a particular DSL expression.
3) Add a shell where the user can type arbitrary expressions in your DSL (and for that matter, load files with DSL commands and execute them).
You're done. People who want a GUI have one, people who want a CLI have one, and there's a nice clean upgrade path from the GUI to the CLI. In fact, that's where this approach really shines: when a GUI user decides he needs to automate something, you can give him a single clear expression to type for each gesture he's used to making, and at first he'll probably just memorize those and use your product in exactly the same way with the CLI as with the GUI. Once he gets used to the CLI itself, he'll probably start tweaking the basic expressions you gave him and eventually feel comfortable enough to write his own. It's a nice security blanket for people who are basically learning to program to have a set of magic spells they're confident they can use no matter what.