GUIs kick CLIs' asses
blog.garlicsim.org
blog.garlicsim.org
He's missing the most obvious reason. Programmers love... wait for it... programmable interfaces. A GUI doesn't generally allow me to programmatically define its behavior or pipe the output to a different GUI of my choice.
Incidentally, Windows' command prompt sucked for a very long time due to its limited scriptability. (Today, the Windows PowerShell mostly solves the issue if you know what you are doing.)
Also, I think that most of the work that people do, even programmers, is spent doing simple tasks. The median shell command is more like a `cd` rather than a triple-piped command. So use GUIs for the common tasks, and when you need something more complex, use the CLI.
The general point is that I'm pitting the very best GUIs against the very best CLIs.
When I can "pipe" the output from one component within a GUI program to another (of which there have been a few interesting research ventures), or even from one GUI program to another, and also automate this whole process with things like loops and conditionals on a whim (not just from scripts stored in files, but invented on the spot as needed) without resorting to writing a plugin to a program-specific API, then we will be on the same page.
GUIs don't have as useful of a REPL, but this could be fixed. GUIs don't have a programmable shell[1] that provides the conditionals and loops needed for automation, but this could be fixed.
Just post it to Hacker News when it is fixed!
[1] edit - Well, myself and others run stumpWM; which, being Common Lisp based, does provide a bit of a programmable shell and REPL, but this is not the norm for KDE, Gnome, etc.
But the real benefits lie in automation of tasks like git-flow allows you to. Sure, it's theoretically possible for GUIs to provide interfaces that allow a similar level of customization and automation, but I can't think of a good example.
GUI dialogs take longer to construct and display than command line stuff. When I hit "Ctrl-O", I wait a bit for the dialog to be presented and become ready for input. Then I start entering commands. Then I hit enter, or tab to the OK box and hit enter, or whatever. Then I wait for the GUI to do its cleanup. Then I wait for it to actually run the command, and then give me a really nice shiny GUI with the same data as the command line, except it takes a couple of second rather than happening basically instantly. You might spent fewer keystrokes in a well-designed GUI, but you're still going to spend more time waiting on things to happen.
GUIs don't have command histories. Most don't have macros or shell scripts. They frequently have sucky keymapping support. You end up having to press tab twelve times to commit a dialog without having to touch the mouse. I can't easily pipe GUI output to grep or gzip or whatever.
Most seasoned programmers prefer the CLI for shell-type operations because it's actually faster and more productive, and gets in your way less, not because we collectively have some disconnect from the reality of how we interface with our machines.
Dude, even on my netbook that dialog appears instantly.
Some GUIs are slow, but that means their architecture is wrong.
Since my comparison is between the best GUIs and the best CLIs, most of your points don't hold.
Sorry to "cool-RR" and those who upvoted this, but this is a ridiculously inadequate article for HN, it's total flamebait and brings exactly zero to the table. This is like coming to a website about "travelling while working" and submitting an article by a guy who says travelling and working in China is a bad idea from the net total experience of having eaten in China-town in the West and wandering around some tourist traps in some Chinese mega-city for a couple of days.
Complete trash, flagged.
Then, when I find something interesting in the data, I'll start grubbing through logs with perl and Emacs. [I was happy to be able to open a 1.2 GB file the other day in a few seconds, in my editor. It's tools that /just work/ that make your day, sometimes.]
This is like cats and dogs: A good environment has both! And they should work together well.
[Bruce Tognazzini, an ex-Apple human interface designer, claimed that keyboard shortcuts were on the average slower than using a GUI. I have always disagreed with him.]
When I need to copy a few files from somewhere to another place, I usually know which files I want to move and where to put them. His opinion is that GUI is superior in this case because you can _see_ the files (their icons) and then select them. There are a few flaws in this thinking.
If you know what you're copying, locating and selecting them will take you longer than to type and tab complete.
If you don't know what files you're looking for, then scanning through the list visually will take an incredibly long time. If you just have a few files, this is not a problem in the first place. In general, if I don't know exactly what I'm looking for, trying to find the stuff I need by browsing is too slow. I either know what I'm looking for or I have to find it using an automatic tool like find or grep.
The second problem in the copy file example is less fundamental: it's the simple fact that selecting multiple files in a GUI file manager is difficult. You have to ctrl-click or do something similar (that's definately not keyboard friendly).
It's nice that the author has spent time pondering where GUI's are good, but unfortunately there are still lots of use cases where GUI's are not good enough.
What's positive about the article is that he acknowledges the fact that most GUIs suck - not because GUIs are inherently bad but because some are just so badly designed.
"scanning through the list visually will take an incredibly long time"
Just type the file name.
"You have to ctrl-click or do something similar (that's definately not keyboard friendly)."
On Windows, you use Ctrl-Space and Ctrl-Arrows.
Thanks for the Ctrl-Space tip. I didn't know that shortcut. Seems to work in Nautilus too.
Visibility: there are split windows, syntax and error highlighting, quickfix windows (use similar to dialogs in a lot of cases), file navigation, help windows, clipboard integration and so on that are so touted for the GUI in the article. (not to mention the status bar...) The gui is text/character based rather than pixel based, but that isn't such a bad thing when text and characters are the entire focus of the program anyway.
Speed: vim (and emacs) are well liked because they are very fast and have keyboard usability++.
From a different angle, an awful lot of well loved GUIs actually put a command line into the program. Many CAD programs do this, as do mathmatica (and other mathy softwares matlab, sass and so on), various repl programming environments, high end graphics packages, GIS software and so on. In fact a lot of those "best of" programs feel like they took the best of CLI and GUI and said "why does it have to be one or the other?", and instead smashed them together.
When I have a file in one format and I want to make it into another, I can record myself doing it once and I have faith that Emacs will faithfully do the same thing to the rest of the file.
Apple keeps making pushes in this direction with Applescript recording, and Automator, but they haven't succeeded yet, and I think it is because the problem is hard to solve in a GUI. Or tackled as an afterthought.
Similarly, for a CLI: you can set a script up to do what you want to one file, and then say "now do it for every file that meets these criteria." A more GUI-oriented way to do it might be to do a find and select in the GUI, and somehow apply your process to those files. But I have not yet been shown a GUI that makes this process easier than doing it at the command line.
The OP is right in a sense: you can pick a single task and show that it might be faster to do in a GUI. And the OP has a great point when it comes to discoverability. I would love a GUI that also supports the kind of hardcore every action is scriptable that Emacs does.
Perhaps such an IDE and/or editor exists, but I am too busy reading opinion posts on HN to find it!
- awesome cross-platform window management (tmux, screen etc)
- a commonly used standard: one programs output is another programs input
- program availability (there are many programs that are only available on the command line)
- i can access the history of my previous actions
- less data to transfer when working on remote machines (seriously!)
- i find the CLI-interface to be more visually consistent (less colors, more constraints)
- ... and many CLI-programs are theamable should the previous point not hold entirely true
EDIT: formatting
A straw man to be sure... where's the evidence to that? I'm not sure what the author's background is, but his argument belongs in a high school.
Also, most GUIs (that programmers care about) lag behind the CLI in features (i.e. command-line GDB vs graphical debuggers).
It's still not quite as powerful as doing things at the command line. It does interface better with the OS and lets you write quick graphical apps.
git checkout master
The real advantage of the command-line environment is that it adopts a tool-centric, rather than application-centric approach. Instead of opening Word to read a document, you navigate to the document and run any of a variety of orthogonal programs on it. And instead of individual command-line apps having to spend time adding scriptability the way GUI apps do, this is simply provided by the environment and the expectation that the user uses tools in the environment rather than opening one monolithic application.
There have been a number of attempts to port the tool-centric vision to graphical interfaces. Consider researching Jef Raskin [1] or Apple's work on OpenDoc [2].
[1] http://en.wikipedia.org/wiki/Jef_Raskin#Career_at_Apple [2] http://en.wikipedia.org/wiki/OpenDoc
Alt-F -> W -> F.
I shortened it to Ctrl-Start-F on my own machine using AutoHotKey
GUIs suck for automation. That's the main problem. Us programmers like to do something once and go home.
Text and command line is automation ready.
Going back to the UNIX philosophy: build small tools that work together via standard interfaces (pipes etc). Then strap a UI to it later. Best of both worlds.
1. Paraphrased: GUIs can present so much more information, so readily, and you should always have your eyes open for all that information all the time because you can always do better if you have more information thrown at you.
This is a big assumption. He first illustrates it with file copying, and I think he is incredibly in the wrong there. He seems to think that developers are the kinds of folks who, on the way to copying a file, would like to be distracted with overall system information that they are apparently too clumsy to manage adequately. How often when you're programming do you think "oh, I only have 3 gigs free, I think I'm going to do some spring cleaning!" I'm a task-oriented fellow when I'm programming. I need as little distraction as possible. Everything he described is a distraction. Not everybody's like me, though. I'd like to hear other people's thoughts.
Then he explains how it can help during development with what sounds like the most horrifying GUI imaginable:
If you just got an exception, you should see the running code, the entire stack, the values of all variables, documentation for the currently selected function, system I/O, and on and on.
Dear jesus no - that is so much crap! At best, I want a stack trace, and I'm smart enough to handle myself from there. Documentation on an exception? What does he even mean by "system I/O" - a list of open file descriptors? Ugh. Ugh ugh ugh. More information in your face is not universally better in my humble opinion. Personally, in the systems I debug, almost everything he listed would just get in the way and piss me off.
2. But, but, but… A good GUI can be controlled with the keyboard! A good GUI can be operated completely with the keyboard, and has good keyboard shortcuts for the most common tasks.
See, he starts to have a good point here, but misses why it fails to pass muster versus a shell.
He explains how he has a GUI git program and how it has nice keyboard shortcuts. Which is lovely.
He didn't mention the effort taken to switch programs so you can use those keyboard shortcuts. You have to alt-tab, locate the window, and context-switch your brain over to using a different program. Every time you have a task requiring a different program.
In the shell, I can do almost all of my daily tasks that I don't otherwise choose to do in the browser (though those could all be done from the shell if I wanted, and all those webapps have extensive keyboard shortcuts). I don't need to think about how to do something in this program or that program - it's one, programmable environment.
If you're not currently interested in the information, don't look at it, and then when you might be interested in it, you can look at it. If you have big screens this is not an issue.
"You have to alt-tab, locate the window, and context-switch your brain over to using a different program."
Sure, but it's on about the same par as using `cd`. And if you're using a good IDE, you have to do much less window moving and have fast shortcuts for moving to exactly the right window instead of Alt-Tabbing.
Having too much on your screen is not solvable by "don't look at it". Suggesting otherwise flies in the face of everything we know about interface design.
As to saying that changing programs being equivalent to typing "cd", I don't see how that makes any sense. When you change programs you need to remember how that program operates, it's shortcuts, its features, and so on. Does this Program autocomplete or not? What's the shortcut for "send email" again? It's a heavy context switch. "cd" is not. And since this post is advocating GUIs, that means specialized programs with guis for different tasks. Email, editing code, vcs, file manipulation, and on, and on. That's a context switch for every task and a new environment to work with.