GUIs are fine for some people who need handholding for infrequent tasks or initial exposure. But CLIs give the advantage of fewer hand movements, and (most important for power users) the ability to script common actions or have programs drive other programs.

One of the most frustrating thing about the Mac for me is that I can't really script anything. Sure, OneClick helps, and AppleScript can trap some of the interesting things, but I really can't tell anything "move the mouse to the topmost file that begins with F, and click there". That's too tricky.

So what we really need is both. GUIs to help the casual or beginning user, and CLIs for the frequent or power user.

Let's also consider one other factor in HCI design. I personally have a brain wiring that makes icons nearly useless, and I understand about 10% of the population are like me. I have to stare at each icon individually and name it, so that the next time I come to that icon, I can recall the name, and then access the meaning of the icon. If you simply present me with a dozen icons or so, I must tediously go through and determine the word for each icon. Thank the maker for tooltips... I just wish they would come up faster!

If a tool has a way of turning all the icons off, I usually do that, or if it has a way of replacing all the icons with words, I even prefer that. So for the 1 of 10 people in the population like me, please, please, please give words near the icons, or provide tooltips. Otherwise, I will swear at you every time I have to use your program.

-- Randal L. Schwartz, Perl hacker

Who says you have to stop scripting to use a GUI? I use scripts every bit as much as I did before. And a CLI is NOT the way humans work. Humans work interactively, based on multiple inputs, and multiple outputs. Humans also multitask. CLIs do not; they accept one input and one output - text - and even with multiple CLIs, you still use only one at a time. Even if you have five CLIs all running different processes, YOU can only look at one at a time. Not true on a GUI.
- email Ozymandias

Maybe it's a matter of terminology, but I bet you aren't scripting the GUI. You are driving the GUI from "command-line" programs that can display graphics widgets.

But let me come along and now try to "script" your application. I can't. I haven't found any decent "scripting language" for your typical "GUI" that let's me say "click THIS button when THAT button turns green". If you have, please help us out here.

Sure, I use multiple windows, with CLIs in each window. I don't call that a GUI. I call the gimp or Photoshop (depending on your bent) a GUI. Try scripting that in a meaningful way. It won't be from the GUI end. Gimp scripting is done because they have a (surprise!) CLI interface specially grafted on to the back end. And Photoshop has its little macro language, and I can tweak at that with some Applescript if I'm desparate. But it's just not the same as taking the output of "ps" and looking for the "httpd" processes.

Imagine if you didn't have "ps", but only the "top" program. (Welcome to MacOS or Windows98 {grin}). This is what I'm talking about. You cannot script a GUI!

-- Randal L. Schwartz, Perl hacker

The GUI is nice not because it flattens the learning curve - it's still a pain to teach someone all the ins and outs of Word or WordPerfect, just as it was in the old CLI versions - but because it's a very nice Least Common Denominator. You can put the tools of the CLI on the GUI, and you can have your other tools at the same time - and it's up to you how you want them to look.