Submitted by “It’s one of the more popular culture wars in the free software community: GUI versus CLI (graphics versus the command-line). Programmers, by selection, inclination, and long experience, understandably are attracted to textual interactions with the computer, but the text interface was imposed originally by technological limitations. The GUI was introduced as a reply to those problems, but has undergone very little evolution from 1973 (when it was invented at Xerox PARC) to today. So why can’t we do better than either of these tired old systems?”
In the first part, the author basically shares his frustration:
(Bolding mine.)
My loose, imperfect analogy is Assembly programming vs. 4GL programming. You may be able to pump out neat applications much more quickly in, e.g. PowerBuilder (?), but you lose several orders of magnitude of flexibility and precision.
I say the analogy is imperfect because many geeks are much more productive on the CLI than having to point and click repeatedly. The point is: CLI is more flexible and precise, while GUI is supposedly more productive and definitely more friendly. That’s life.
In the second part, the author offers up some pretty cool ideas. I actually liked the “Trainer” Terminal prototype. I’m not sure it satisfies the innovation he is looking for, but it could help bridge the gap between GUI and CLI for many folks.
edit: fixed unprintable garbage from quote
Edited 2008-02-08 21:11 UTC
The CLI is completely programmable, while the GUI is just a mapping of a subset of possible CLI operations onto graphical controls.
Just imagine the following task:
You have a bunch of image files. First, renumber them with the current date. Then pick those with a geometry x > y and rotate them 90 degrees, put those that have been rotated into a separate directory, and output a list of the files to the printer.
You could realize it with a composition on the command line, but it’s hardly possible to realize this with a GUI application. The CLI provides facilities to add relations, data transmission from / to programs and (conditional) concatenation of program calls.
For GUI applications: The developer has to think about which options and possibilities of use he implements, while the CLI leaves this choice to the user, just providing the basal means.
In most cases, complex tasks involve complex ways of operations. It’s up to the user which tool he choses to accomplish them. Some take more time, others take more need for interaction. Every tool where it belongs to.
Interesting approach.
(I know you meant this rhetorically, but I like a challenge, forgive me from doing this off-hand……)
Win+F, select directory(s), tab into screen, App+R, “* – %d”, shift-tab one back into the filter screen, “X > Y”, tab back into selection screen, App+O, choose the program that’ll rotate them (don’t know which would be best off hand), Ctrl+C, App+N, name your directory, Enter, Ctrl+V, Alt+E, L, Win+No, Ctrl-V, Ctrl+P.
I do it by typing pic_i[TAB][ENTER] on my machine; but the point here is, that you can not generally automate the WIMP software.
Edited 2008-02-11 10:43 UTC
Actually you can – by using tools such as Tk and Tcl. DejuGNU (build on Tcl/Tk) does this quite well to produce fully automated GUI test suites to ensure GUI components work well.
I think the bigger issues comes down to that a lot of programmers don’t like writing GUIs, so they avoid them – despite the fact that GUIs are a lot, lot friendlier to end-users.
You can do almost anything with a GUI. But ‘plugging’ different applications together through GUI components is a bit harder – but, as I said above – it can be done. You just have to adjust your toolkit appropriately, which may mean learning another programming language that can do the job (like it or not).
I do not believe into orthogonality of GUI and textual interfaces, because text is graphics and images convey meaning. I wish people would see over the implementation details and understand, that the goal is to mimic normal human conversation, not draw pixels or walk the rodent around the keyboard.
If 50 years ago textual interaction was limited to console with one-line edit buffer, it doesn’t mean that the proponents of language interfaces still want to force fixed-width green-on-black ASCII characters down people’s throats. We just want to at least retain the functionality we always had so we don’t get lost as our clients are.
GUI applications are wrong because designer is forced to reinvent the interface for every single application, because the application is tied to the pretty picture you draw to the end-user, because you limit your application to a certain platform and the single way you physically access it, because your application becomes monolithic and because it becomes unautomatable.
What you mention about Tcl/Tk is nice, but the implementation is still wrong; I want to talk to the computer, not gesticulate to it.
I kinda agree, and I kinda don’t. Let me try to explain…
Every program sets out to accomplish a given task. Some tasks are better for users via GUI and some via CLI. It doesn’t mean that you can’t implement them as either – just some are better suited one way or the other. As such, users will be able to use the program better when its UI is the one that is better for that task.
That said…I try to provide both kinds of interfaces for my programs. Why? Most users like GUIs better – it’s more natural to them, so providing a GUI is good. However, at the same time CLIs are better for scripting and other tasks that admins and some (not all) developers like. So there’s an audience in providing both. Providing both pushes the core of the tasks to library APIs, so you get better, more extensible code architecture/design too.
Some systems (e.g. IBM AS/400) do things the old Green-Screen way – for that you need to interface appropriately, and provide transitions appropriately. (Yes, I’ve done worth that way!)
Also – there is no reason to be tied to a single platform with a GUI any more. There are a number of toolkits out there (Gtk, WxWindows, Qt, KDE/Qt, SDL, etc.) that enable software to cross the platform barrier from a single code-base. Furthermore, it’s very easy to do.
It doesn’t help to stay stuck to CLIs, nor does it help to go overboard on GUIs. There’s uses in both.
True, GUIs do provide more information as the graphics used have meaning to the user. However, as DejaGNU and other toolkits do provide – they can be automated.
I’m not going to say CLIs are the end-all-be-all. They aren’t. And a GUI does not necessarily mean a big monolithic application – it doesn’t.
A GUI will typically be a bigger application than a CLI as there is a lot of code for handling events from the GUI. However, ClIs are not that small either b/c they have to parser the I/O a lot more – and that is a lot harder to do than in a GUI, and often results in a lot of redundant programming too.
In either case there is a core functionality. You don’t have to reprogram that core functionality every time you have a new program – that’s what libraries are for – whether using shared, static, or convenience.
As the saying goes – there’s more than one way to skin a cat. 😉
I find it odd that the author chose to use Blender as an example here. I agree that it is geared towards ‘power users’ in many ways but so are a good number of graphic programs. I often see Blender hailed for it’s ease of use and intuitiveness. It is a great application for beginners and pros. This is the case for a lot of graphics applications.
Whoah, that weird because I’ve mainly heard the opposite. Even on Blender’s own forums the main topic that keeps coming up is usually user complaints about its unconventional user interface. In-fact the next version of blender is getting major rewriets in the interface so that it could accomodate more convetional interfaces for users if they wish. What everyone does agree about blender is that if you do take the time to learn the interface (which frankly is way better when it was opensourced) its once of the fastest interface for artists around. Almost everything can be done with shortcuts with a very minimal interface. Unfortunately not many take to the time to learn the interface and rather blender look, and act like an opens source version of 3dsmax or Maya, which I think is stupid, if you want Maya stop being cheap and buy Maya. While I do agree that there are issues with the UI its most due to the fact that you can’t really configure the way you wan, in-terms of shortcuts and the like, but that is being worked on.
the cool thing about blender is that its has an extremely active community (and that is an understatement), with a project leader who knows what direction he wants to take the project in and with a very enthusiastic community of artists behind the project.
The article here uses Blender as an example and they are right to a point but one thing that is not mentioned is that many other apps that are not OSS have issues with interface, especially in the 3d application world where features are crammed into shortcuts and menus without regard.
3dsMax is a nightmare and it was nightmare at version 5, it now at version 9 and very little has changed because of the modular nature of 3dsmax (it uses plugins for features) Autodesk main upgrade strategy is to buy and include 3rd party plugins, the softwrae itself usually sees very little work and at this point is just a mess.
Maya is a also a nightmare, its a very powerful application that has many features, a lot of thise features are usually accessed through menus and shortcuts, the issues is that there are way too many of them. The list goes on and on. Zbrush, LightWave (which belnder resembles the most, imo) Wings3d, even Softimage XSi whic I think is the most intuitive 3d application on the market as issues with its ui.
3d applications 9or any app for that matter) usually start out with very simple easy to use interfaces but as features get added things start to look a bit messy. Blender is at this stage right now where things are looking messy, luckily the team behind the application have realized that and are rectifying the issue, you can’t say the same for Maya and 3dsmax, which every major release are starting to look more like point upgrades.
Making the commandline more accessible is all fine and good but what really matters is that the candy on top remains transparent in that there is an easy way to translate between visual and text representation.
He also seems to advocate visual programming.
Judging from my limited experience with Labview I won’t touch that with a ten foot pole.
Having to connect wires and push boxes around that got in my way all the time when I could’ve just written a couple of lines of Python was one of the most annoying things I’ve ever done.
Maybe a line at the bottom of every app that displays the text command associated with every GUI action performed would make things mor accessible. That way you could have the advantages of a GUI (not having to read the manual) and a text interface (easy scriptability).
Yes, I have to agree with you. For argument sake, you even have Visual Studo and C++ Builder…Why use the provided GUI to draw the interface and just double click and it takes you to the event handler when you can simply spend 10 hours writing even handler declarations for each object in the include files + their method body definitions in the source file…Things would be so much easier. Yeah right…
Back to reality, visual programming is the greatest things programmers have ever implemented HOWEVER *not* knowing how it works and how are things connected is big negative for the programmer. Still it really depends on the programming language used and the things that you are programming. Some are suiatble for visual progamming and some are not.
Edited 2008-02-08 22:23 UTC
autogenerated code like event handlers and crap, are really not limited to “gui’s” – in fact i dare say, people have had applications to do this long before anyone made it in a fancy smancy gui IDE.
Oh, I wasn’t talking about visual programming _environments_, I was talking about visual programming _languages_.
Guess I could have made myself clearer…
As for the environment I couldn’t care less how the event handling boilerplate is generated, by a visual or text based tool. I’m sure Visual Studio is a fine product although I’ve never used it.
Anyway, I guess I should make one thing clear:
Labview doesn’t actually prevent you from editing code the old fashioned way, iirc. My main criticism with visual programming languages is that all the “Klickibunti” (click-y-colorful-y) diverts attention from more important things such as core language design.
Unfortunately, that’s more common than you might think. I’ve seen commercial, expensive, 3d engine toolkits expecting me to waste 4 click to make a stupid IF statement. When the logic gets complex that’s a royal PITA.
This is something I could see in a computer lab where the users were sitting infront of CAD workstations. When they began their work, they were traveling the menus to locate the features they wanted to use. On the bottom of the screen… uh, no, it was a separate screen… the respective commands were displayed. I was surprised to notice that after a certain period of time most users were entering the commands manually on the keyboard, using the mouse for view rotation and placement and not for menu selection anymore.
I think editors like gvim do follow a similar approach: You can use the (usually much faster) vi and ex commands, but you can use hierarchically sorted menues, too.
most gui software have hotkeys for often used tasks, but im guessing what your talking about (given your use of gvim as a example) would be something like midnight/norton commander…
as in, at the press of a keycombo or similar one would get a cli area onscreen attached to the gui one was working in at the moment, it would allow one to enter a string of commands one wanted performed, maybe send of data to other programs, fire up a scripted sequence of commands and so on.
hmm, im left thinking of something like ion, but where you can say attach what happens in one window/area with another, so that one could have man running in one area 24/7 and have it present the manual for whatever your working on in another area.
hmm, or what about the fish cli? isnt it supposed to have expanded tab completion? as in it can even present the user with tab completion for switches the current program/command have available?
i have also mentally played with the idea of having a cli as the “background” of the desktop, and have some kind of scrolling message ticker up top. launch a image viewer and it will float on top of the cli history and so on. and if one use the virtual terminals that most *nix’s provide one with, one of those could work as a kind of holding area for the “windowses” that was open.
and didnt plan9 allow for the manipulation of windows via the use of the cli? this by having a dynamic dir tree that basically was the cli representation of the desktop at any one time?
hell, i would love to have a gui area that would graphically show me the flowchart of a advanced cli pipe setup as i was typing it out. but setting up something like that using gui would be cumbersome imo…
You are mentioning two different aspects:
Hotkeys and key combinations to access menues and often used functions (open file, save file etc.) are very important to keep the work flow. For example, if you’re creating a text document, your hands sit on the keyboard most of the time, and it’s “uncomfortable” to use the mouse just to save the file or to generate a printed preview. Missing hotkeys are a no-go.
Another no-go are hotkeys that do not work. For example, the menu displays key combinations to call a certain function, but if you press this key combination, nothing happens.
Applications like gvim combine the hierarchical menu traveling option with the classic commands of vi and ex. The Midnight Commander (by the way, my favourite file manager) unfolds its power mainly by its keyboard functions. The mouse options like drag and drop are seen as a “bonus” by most users, but to be honest, I’ve not seen anyone yet using the MC with the mouse.
This is what the integrated command line of the MC or gvin’s vi / ex mode realizes, correct.
This would be an interesting way of interaction within a GUI where the “old stuff” you know from the CLI (data piping, conditions etc.) can be used with the GUI controls.
Using the X ressource control, you can still manipulate windows via the xset command. But this is a bit complicated.
i think plan9 made it very simple.
so that if you wanted to alter the height of a windows you could just echo a new number into the “height file” found under the windowname dir or something like that…
and yea, i have a bad habit writing posts in stream of thought mode, where one thing flows onto the next one and so on…
First, a GUI doesn’t have to be limited to mice, although mice are a nice backup. I don’t use CLIs, but surprisingly to most people who don’t use Windows, I don’t use mice. Keyboards are not the mortal enemy of the GUI, the old Macintosh System 1.0’s mentality (“point and click, drag and drop shall be the whole of the interface”) is.
Second, I’ll argue that GUIs have been advancing, but not in the arena that the author is talking about. Instead, let’s take a look at another arena, with similar (different, yes, but similar) constraints: the conole gaming system.
Anyone who has grown up since, oh, 1980 can identify how video game consoles GUIs and toolshave been advancing steadily — from the simple ‘push pause to hit the hidden menu screen’ menu systems, to context-based game controls (especially popular now that Halo’s doing it right), to modern MMOs, such as Final Fantasy XI (where the control list, if printed out, would make emacs and vim seem as straightforwards as Mario I). And because game developers are even quirkier than OS developers, crazy new ideas pop up much more often in the game world.
And unlike the controls, where the keyboard and mouse are still largely the way that Xerox’s PARC (and, more to the point, IBM’s Selectric) set them with the occasional (incidental) addition by Microsoft, to the point where we still have a scroll lock key for pete’s sake, video game consoles have been advancing with every generation. For a time, computers and consoles were similar — the days of paddles and joysticks, and of home computers also being home consoles and vice versa — but they unfortunately diverged sometime in the late 80s. Which is too bad, because while our computer’s controls still haven’t advanced much beyond what the C64 had available to it, video game controllers have been adding extra buttons, shoulder switches, analog controls of all varieties, force feedback, and in general have been getting input and user feedback not down to a science, but to an art.
And now the Wii, which you can also use like a lightweight mouse, is adding a crazy new option — for new games (like Super Smash Brothers Brawl), you can actually store info like how you like to use the device in a device, so if you take your controller around to other consoles, it works just like on your own home machine. Try that with your mouse!
Operating systems would be much different today if the developers of the Macintosh had picked up a NES pad instead of a mouse and said, “Let’s use this.”
Edited 2008-02-08 21:58 UTC
You’re right, a good combination of keyboard and mouse (or other pointing devices, such as tablets) can improve a GUI’s easyness of use. For example, I’m using WindowMaker as my main window manager, and a Sun type 6 keyboard. I can point into a window – the window gets focus – and press the “Front” key – the window gets into front, or “Back” – and the window goes into background. Rolling up windows, hiding them from the desktop or maximizing them is pssible this way, too, without needing to have several buttons on the title line (-, o, ^, v, x, _, ?).
I’ve seen bad examples, examples how not to implement a GUI, for example, no access to the menu via the keyboard. This is definitely not how it should be.
Which works in FreeBSD to scroll the console / VT output. 🙂
You make me think of a possible alternative reality… interesting thought, interesting implications…
You can use Shift-PageUp and Shift-PageDown in Linux virtual console.
Yes, that’s common knowledge. 🙂 The same key combination can be used in an xterm (on any Linux, BSD or Solaris, as far as I’ve experienced) where the ScrL key does not work (or at least does not have its native function).
Everyone has ideas about how GUIs could be better. The limitation is that implementing these things is a lot of work. The FOSS community is superb at collaberatively producing code, but less good at collaberatively designing software (most design happens within traditional hierarchical organizations producing OSS code).
It’s interesting that none of the ideas in this blog post is entirely original. They are truisms, that crop up over and over but never get further than the drawing board. Someone usually cites some academic research which determined that nothing is more effective than the WIMP GUI. I think most people realise that that can’t be the case, but the work to create an alternative is never done because no one person has the skills and energy to conceive and implement a better alternative. Look how long it took something as simple as Fluxbox to reach maturity.
I think the time is ripe for a website where people can share, discuss and develop ideas for next generation GUIs. If people can discard their egos and work together to come to some level of agreement, we could really work through all the ideas rigourously and end up with genuinely useable designs instead of hot air.
These days, people seem to be obsessed with the most “flashiest” graphical interfaces.
Like OSNews, It looked “fine” before.. now it looks like it was beaten silly with a fugly stick.
On my workstations.. I use X, I’m not a monk… but I don’t use KDE/Gnome or “XFCE”.
I use my own custom fluxbox theme… anything more would be useless clutter.
I just lost a big comment … so i summarize
cli like shells are nearly perfect :
data flow (pipes)
operators (anything that pipes in and out)
homoiconic user composition persistency (scripts)
+ contextual symbols database (autocompletion aka fast search in the possible existing inputs)
many highend software ( nr shake, discreet flame, alias maya , sidefx houdini … ) uses 2D pov of the same ideas :
dag aka composition of nodes and dataflow evaluation
computer languages too have the same concept … (lazy evaluation in fpl)
we could surely find some minimalistic way of interacting with computers there
so cli is perfect but .. linear .. it doesnt scale , and TUI are discrete lo-def (its a matrix of rectangles)
here come the gui .. we have 2d ( and Nd in fact ) and freeform shapes but problems are :
– these dataflow / operators ideas stayed out of sight … for a lot of people ( even teachers ) a MSOffice gui is some kind of state of the art of what a GUI should be. they start with their mind creativity crippled.
– on top of that comes the oldfashioned concept gui frameworks that makes you write tons for few results ..
imperative and even oop gui frameworks are not well suited for ergonomy and interaction expressivity.
I guess value oriented semantics will lead the way ( like xml / js / css can demo actually . they created fancier gui inside a browser than in richclient apps )
or maybe some ND interaction calculus for generic data can be developped …
– then 2d is nonlinear… an advantage and a disadvantage too : good 2d interaction is not simple. good 2d data layout is hard too. especially dynamic live data , with semantic relation between them.
lets see
My idea: What if we could incorporate CSS into GUIs outside the browser?
Since the only people who really take CSS seriously are web designers (the ones who create the blog websites with text gradient logos using CSS and Photoshop, among other features), what if we let the CSS folks work on the GUIs of applications outside the browser?
CSS, as a young stylesheet language, is engineered towards design and presentation of any markup-based web interface (XHTML, SVG, XUL, etc). Furthermore, the future iterations of CSS, like the CSS3 working draft, are being developed to give the web designers more say in the presentation of their websites, even though they are a long way from usurping some of the roles that web developers (those who use JavaScript frameworks like jQuery and Prototype) currently possess.
I know that, as of 2008, only Firefox-based browsers (using the Stylish extension) have the ability to customize the browser’s own interface using CSS “userstyles”, even though it goes only so far. This is because of Mozilla’s XUL (XML User Interface Language) framework, which supports most other standards that are compatible with the XML standard.
Giving CSS designers control over the GUIs of applications, IMO, will allow for the development of better, more intuitive user interfaces. It’s a natural evolution for graphical interfaces, that they should be designed (within the constraints of the programmers, of course).
isnt this more or less what microsoft stuffed into vista?
or at least, i could have sworn that one can do gui’s using a xml based language there.
sadly they havent seperated the ui from the rest so that a creative person can go about and radically rewrite the ui if he wants to (that i know of).
but then, thats what the kde people did with kde4, no? so that all the variants of desktop clocks that they have use the same “engine”, but each layout is rewritten on top of that?
You mean XAML?
It says here ( http://www.windows-now.com/blogs/rrelyea/archive/2004/03/31/2893.as… and http://www.simplegeek.com/PermaLink.aspx/b7e02709-0112-4977-9b73-1a… ) that they originally thought of supporting CSS (or CSS-like stuff), but then decided to pull it out for various reasons.
Actually Qt 4 (and through that all of KDE 4) does have Style Sheets (based on CSS) for apps.
See: http://doc.trolltech.com/4.3/stylesheet.html
“(…)the text interface was imposed originally by technological limitations.”
Every good thing that was ever invented came out of limited environments. Limits are the fuel for the imagination. But enough cheap poetics…
The CLI may look old fashioned, but it gives the user a language (as in human language, not programming language) to really communicate his intentions and wishes to the machine.
GUIs, on the other hand, are grunts and gestures… A way for people that don’t speak the “language” to, at least, get something done.
The only interface that could kill them both would have to be a concise and expressive language requiring no previous knowledge. More gestures and grunts (multitouch, 3D, whatever) won’t cut it. That would probably be a natural language interface, either spoken or written, or both. And we all know that we’re not even close of having this actually, really, working.
in my psychology studies, I had a similar inspiration. Imagine a child, let’s say, a 1 or 2 year old one. It cannot express in a spoken language, so the only way to communicate his wishes is to… guess what it is? Point and “ga!”, which is equivalent to a click. And a doubleclick would be “gaga”. This “baby speak” of course serves the intended purpose: The child gets what it wants. On the other hand, the child develops, it learns to speak step by step. After few years, the child does not point and click anymore, it expresses in complete sentences that follow a grammar.
Now you could conclude: While the CLI is equivalent to the expression in a language, the GUI is just pointing and making “gaga” baby sounds (or how they are called in English respectively). And now you can see why mainly GUI driven computers don’t benefit the development of communication and social capabilities.
Don’t take my comment too seriously, please, but notice the truth within. 🙂
Basically i agree with CrLf.
The book “In the Beginning… was the Command Line” from Neal Stephenson as a really true sentence: “We need a command line for the same cause that only children read picture-books, only the human language is powerfull enough to express complex issues”
The GUI is a really good tool to allow many users to work with the computer. But it will always be limited because you can never put every possible option into an icon or something visual.
Let me try an comparison: If you want to express your thoughts you will always have to write them down. We will never have a “GUI” with all possible words so that you can create yout text by point-and-click (you can’t put a “selection-dialog” with all possible word on the screen). If you want to express your thoughts you have to write them down. The same is true for complex tasks in the computer world.
Maybe some day the command line can be replaced by a voice-interface (so that you can talk with your computer) but you will always need a real language to be able to execute complex tasks.
GUIs are a nice simplification for many standard tasks but it can never replace a language based interface for complex tasks.
I agree with you and I’d like to add: The CLI emphasizes the method, the way towards the goal you want to reach. You don’t (or cannot) tell the computer what you want to have in the end, instead, you tell the particular steps, their relations and their conditions. Furthermore, there are many ways to realize one task, so it’s up to the user to choose which way is the most convenient one to him. (Put into CLI terminology: some like aliases, others like scripts; some like pipes, others like fifos.)
This is correct. As it has been pointed out before, GUIs map a limited subset of the previously named steps, relations and conditions onto graphical objects that can be read and manipulated, but still, this mapping is incomplete. Most GUI driven applications concentrate on the result of a task, not on the steps to reach it. Please get me right: This is nothing bad! But as I said before, it is limited and may reach the point where an intended and imaginable goal cannot be reached. It’s up to the developer to think about what he implements and what he does not implement. It may be seen as taking the ability to choose off the user: He may only choose among a subset of the possibilities.
Actually, I think it’s the other way around. The CLI is mostly about stating what you want in the end.
For instance, to produce a list of all MP3 files ordered by time:
– With a CLI, one would say “list me all .mp3 files ordered by time” “ls -lt *.mp3”;
– With a GUI, one would say “list all files” (open the folder), “show me all MP3s” (by filtering the view or searching within the current directory), “order by time” (click the time column).
Okay, that is a vaid way to see it, too. You’ve given a good example. Maybe I needed to express more precisely. I was thinking of something morew complex, like piping informations through different programs. This creates a “sentence” that formulates the processing way, such as
for DIR in `cat ${INPUT} | awk -F “:” ‘{print tolower($2);}’ | sed ‘s/ //g’`; do [ ! -d ${CHDIR} ] && mkdir -pv ${DIR}; done
This construction contains iteration, a conditional, processing and substitution. The sentence is formulated first, then, after completing it, action takes place. No interaction is needed afterwards.
Inside a GUI setting, such things would be hard to realize, because the developer of the respective program would need to have integrated all these relations. The “sentence”, if any can be seen, is divided into parts (according to your example), these parts are executed one after another, this needs interaction.
Speaking from a natural grammar, CLI enables you to create complex sentences such as the ones I’ve written up to this point, including subsentences and punctuation. GUI is different. Here only simple sentences. All sentences short. Sentences not in relation to others. Take one sentence out. Cannot tell purpose anymore.
By the way, you see one advantage of the CLI way: You can simply transfer the command text to someone else, and he can mark and copy the command from his mail window into a terminal. If you use the GUI way, you would have to preproduce images that show where to click, what to drag – always hoping that everything looks the same on the other side -, or you start describing pictures and moves, which can be very hard if you’re missing something that you assume to be obvious, someone else doesn’t.
Master Foo Discourses on the Graphical User Interface
One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful.
“The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.”
Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master’s hand.
“I don’t understand you!” said the programmer.
Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window.
“What are you trying to tell me?” asked the programmer.
Master Foo pointed at the programmer’s head. Then he pointed at a rock.
“Why can’t you make yourself clear?” demanded the programmer.
Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan.
As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him.
At that moment, the programmer achieved enlightenment.
Forgive me this impertinent fullquote, but I found this small discussion linked from within the article most amusing. I hope more programmers get enlightened this way. 🙂
Source:
http://www.catb.org/~esr/writings/unix-koans/gui-programmer.html
/* Edit: Added source and corrected malformed quotation marks */
Edited 2008-02-09 03:27 UTC
I think one of the main problems is that CLI is batch-oriented, while GUI tends to be interactive. This is important, because the concept of pipes is easier to use with unidirectional information flows. That is, it needn’t be linear, you can have ramified pipes, but you need to send the input and get the outputs at the other end. Function calls are also batch processes: you send the arguments and get the results, which you can feed to another function.
I think one of the best combinations of interactive behavior and one-way information flow are spreadsheets. So, I wonder whether a desktop environment could be designed as a “multimedia spreadsheet”, where you can have “movie data types” and the like. A problem with this may be that interactive edition (like cutting parts of a movie) needs destructive updates. You would have to replace the original movie with the edited movie for further edition. That seems to be the problem that functional languages have tackled in different ways, like monads and uniqueness types. I think something like uniqueness types could be adapted to spreadsheets, such that you can model a side-effecting function as a pure function that takes as input your user input (in cell A1) and a state data structure (in cell A2) to shield results in cell A3, and then link the A3 (output) cell to the A1 (state) cell with a “destructive update” type of link, so that A1 is destructively updated each time you change the A2 (input) cell.
Another concept is that it should never let you change the data in a way that makes the output inconsistent, that is, type checking during edition, for a more responsive and helpful editing interface.
Sorry, guys, I wish I could draw a sketch in this forum, but this is yet another limitation of current user interfaces
With text CLI we can meta-prorgram. We can use a script, or use a script to call a script many times, and even pas parameters. We can pipe, process, slice and dice tools (ls | grep | sed | xargs).
Take a common example. Rename all files by removing a common middle bit of text “abc-song-def.mp3” -> “abd-def.mp3”. With a text CLI this can be done in various ways.
Now some of you will be saying “but I have a GUI tool that does this”. Sure, but there will be many different tasks you want to solve in future which don’t have GUI tools for dealing with them.
And this leads me to my conclusion as to why CLI has not been overtaken by GUI because … GUI are not easily meta-programmable as CLIs are.
First it said “posting as anonymous”.
So I spilled my my brain, my spleen, my guts.
“anonymous posting not allowed” said the next.
my terrible wisdom consigned to oblivion
A good GUI shouldn’t lie.
A waste of effort this, said I.
(you can bet I copied this terrible wisdom to my clipboard this time)
Could I ask the good site developers — if anonymous posting is disallowed, please remove the form controls for posting.
Good GUIs shouldn’t reveal developer laziness — or, if it’s temporarily broken, it’s permanently broken.
that even as the fps games become more and more advanced, they still have one interesting feature, a drop down cli
this was introduced with id sofwares quake 1 (that i know of) and have stayed around in one form or other up to this day (half-life 2 have it i belive).
in game it acts as a combo of message history, admin terminal and more. often the more advanced settings of the game can only be reached by using it.
and recently there have been such drop down cli’s introduced in both kde and gnome i believe. i have yet to try one tho.
and then there is apps like quicksilver on mac, katapult on kde, and similar for windows and possibly gome to. they all have one thing in common, a focus on the use of the keyboard as a gui tool. you hit a key combo, enter part of the name of the app you want to launch, a math formula you want to calculate or some other “command” that you want performed, and the program does it right there.
then there is the late jef raskin and his “humane interface”, and archy. the latter can probably be described as a gui cli
all in all, i suspect the future is a marriage of the two, not this forced separation that we see today. even microsoft have gone back to the cli with its powershell. all we need now is for apple (jobs) to see the “light”, and things could turn out interesting. or maybe they/he already have, given that search feature that could very well expand into a quicksilver like feature given time.
heh, maybe one could say that todays separation between the cli and the gui is a bit like a romeo and juliet story. i just hope it do not have the same tragic ending…
acme from plan 9 is worth study.
See http://en.wikipedia.org/wiki/Acme_(text_editor)
If you want to try an entirely different editor/shell/OS, start here http://code.google.com/p/acme-sac/downloads/list
All valid points about the greater expressiveness of CLIs compared to GUIs, and I particularly liked the gesture vs language analogy (although of course there are languages communicated entirely in gestures, something to think about there.)
So why are people so fearful about using the CLI? Well, to be honest, the Unix-style command line interface is utter crap for a beginner. Unnecessarily terse bordering on the cryptic, inconsistent (in naming of commands but especially with options), ugly, and unforgiving (why doesn’t ‘rm’ move to recoverable trash by default?). The help system is slow and to load up and navigate, and just don’t get me started on editors.