I found this piece very interesting. The main advantage of the CLI seems to be the fact that it only shows the user information relevant to what is currently going on. This makes it far less intimidating to new users than a multi-process windowing operating system where the screen can have hundreds of buttons on it at one time.
I myself have experienced this problem when teaching new users: people who haven't grokked the basic logic of GUIs find it extraordinarily difficult to infer what to do next in a particular situation. And all of us who design GUIs have grokked this, so we can't help the people who haven't.
>> The main advantage of the CLI seems to be the fact that it only shows the user information relevant to what is currently going on.
Really? When I open bash it doesn't show me anything. When I am trying to muddle through a grep it gives me 0 feedback. Unlike say Regex buddy that gives quite a bit of feedback. GUIs may have the problem of overwhelming the new user with too much feedback but the CLI suffers from too little feedback. It is much easier to simplify the GUI than it is to beef up the command line.
Many CLI programs are written to be used by other CLI programs, which is considerably more difficult when the the primary interface to the program is a GUI. If you keep the interface simple and textual, though, you can still write a GUI wrapper.
Too true, RegEx Buddy certainly helps me with regex's but it doesn't help me get them into any other app where I actually use regexs. To me GUIs are REPL while CLI is compile and wait. CLI is much faster(especially if you know what you are doing) at the end of the day but when I don't have a clue as to what I am doing(most of the time) large buttons that say try this and try that allow for experimentation with immediate feedback,with the caveat that it doesn't lend itself to integration.
I think that we're talking past each other - I'm talking about expressiveness (once you know the system, you can easily ask the right questions and get rapid, informative feedback), while you're talking about discoverable interfaces (if you've never used it before, can you figure it out?). There's a certain point past which having a discoverable interface is overrated. Complaining about a system advanced as (say) AutoCAD not being intuitive is a bit silly, IMHO.
drscheme, allegro lisp,squeak,dolphin smalltalk,idle. Most of the REPLs I use aren't CLI and are the better for it. I certainly don't see this as a discoverable vs expressive debate. It is expressive(the app) vs expressive(the user) debate. A GUI allows the App to be more expressive. CLI has only one way of expressing anything to the user, slabs of text.
Your point is roughly "it doesn't give me information relevant to the situation." The point you are responding to is "it doesn't give information irrelevant to the situation." Both points can be right, and, in this particular case, both points are right.
"[I]t only shows the user information relevant to what is currently going on." I agree this makes it better for newbies. It also makes me wonder about all those who actually like GUIs, like having multiple things going on at once. It's like they're embrasising their ADHD side, and the GUI rewards that, rewards those who are constatly flicking from one thing to another. Those people may, consequently, find singular concentration harder. Whether that's absolutely good or bad, I'm undecided.
I think one of the major things that the CLI has in its favor is the ease with which an experienced user can guide a new user. The experienced user only needs to the tell the new user what to type, and when to hit enter, which can easily be accoplished via phone, email, IM, etc.
Navigating a GUI over the phone is a skill that few possess.
Recently I had to perform a very simple image manipulation: given two images, I wanted to use the second one (which was all grayscale) as the alpha channel for the first one. I spent quite some time googling for things like [gimp alpha channel] and reading various tutorials, which were very nice with screenshots etc. and still I couldn't really replicate the process. Then in a flash of genius I replaced "gimp" with "imagemagick" in my query. The first page Google took me to contained a command line which I copy-pasted and it did exactly what I needed.
There are some points in the article about how a CLI is very focused, it does one thing, and only exactly what you tell it to do, which can be nice for overcoming some sort of fear of breaking stuff and losing control.
However, research has shown again and again that GUIs are better at most tasks, but not all. One obvious example would be photo handling or sorting, I'd rather do that sort of thing in Picasa where I can see and drag and drop, than through the command-line where I'd have to move the images by remembering their filenames.
As always, what the "best" interface for something is depends enormously on what tasks you want to perform. If the task is simply to overcome your fear and having the computer do something, anything, then sure, a CLI might be a good idea.
I especially like what he says about manpages - the FSF trying to phase out manpages in favor of its proprietary texinfo system has been a real pain. (I hesitated to use "proprietary" here because of its open-source-world use as the opposite to free, but no other word actually fits as well).
In partial defense of Texinfo, manpages are terrible at the kind of documents the FSF is trying to write with Texinfo. (man zshall, for example, is spastically organized and tries to be reference and tutorial at once, which doesn't work well). But you do need the man pages as well for quick reference.
This is great. I almost avoided reading this because I thought it was going to be something along the lines of "everyone should really understand how computers work and using CLI allows people to understanding arguments, etc..." instead of "CLI is actually more similar to the way people think in many ways."
Also, there is an interesting point here. Its not that graphics are bad, but that the CLI is a better starting point. This means (I think) that people should be happy pulling up GUIs from the command line. E.g. it might be easier to type
vlc "My_Birthday_Part.avi"
then opening vlc from the desktop and searching around for the file. If you think about its, not even very intuitive that you click "File --> Open" since most people don't think of the movie as a file. It's only a file in our (sorta wacky) jargon. <edit>Also, I don't want to "file an open" I want to "open a file."</edit>
Finally, this might lead to a better UI design. Something graphical but sequential could be good for many people.
I myself have experienced this problem when teaching new users: people who haven't grokked the basic logic of GUIs find it extraordinarily difficult to infer what to do next in a particular situation. And all of us who design GUIs have grokked this, so we can't help the people who haven't.