>After thinking about it for a while, my conclusion is that there are two main reasons that most programmers prefer CLIs to GUIs
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.)
I came here to say the same. The ability to drive and connect commands programatically is what makes the CLI so powerful. Sure, some GUIs let you extend them via some embedded scripting language, but nothing beats single-use bash scripts in many, many cases.
A good GUI made for programmers, like Wing IDE, will let you write your own scripts for it and extend it to do anything you want.
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.
This is not the same as the main point of the parent comment, which is the bottom-up philosophy of small simple procedures that can be combined to create even more useful procedures with variety and ease... This is the Unix philosophy, and this is what we (the terminal-enjoyers) enjoy most about it.
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.
In the blog entry, you say you compared the "very best GUIs" to the "very best CLIs". At the risk of triggering a holy war, which GUIs and CLIs do you feel fit those categories? It's hard to say anything sensible when we don't know the specifics.
I mentioned some of my favorite GUIs in the post. These are only GUIs that are relevant to my niche, there's a whole world of GUIs out there that I haven't heard about.
Agreed. We could the git example a step further and define an alias for it and make 'git che[tab] master' 'git c master'. With an alias as shell level we could even make it 'gc master'.
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.
I could make a one-keystroke shortcut on the GUI too using AutoHotKey, but I wouldn't because of the usual problems and restrictions (Having to do it, having to maintain these for all your computers, having clashes with other programs...)
If you're generally better with GUIs than your CLI, either your CLI sucks, or you're doing it wrong.
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.
No mention of unix shells, no mention of powershell, no mention of having even used vim or emacs. Screenshot of command.exe.
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.
+1 on visibility. I like real-time graphing for performance data and events, and showing me the gist of what's going on. Configuring triggers on a scope? I'm totally there, GUI-wise.
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.]
Real time graphs and other real time data aside, the example on copying a few files from one place to another is not a very good one to demo the concept of visibility here.
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.
If I knew the file name, I could type it and it would be as efficient with a GUI as with a CLI. However, my initial assumption is that I don't know the file name (or it's location in a directory hierarchy) but I have to search for the file based on name, content, size, modification date, etc. A list view in a GUI can help a little but I still prefer find and grep to their GUI alternatives.
Thanks for the Ctrl-Space tip. I didn't know that shortcut. Seems to work in Nautilus too.
This kind of fell apart for me when he kept strawmanning vim (and emacs I don't know it as well, but it is the same for purposes of htis argument) as a pure CLI. Given the rest of his argument about good keyboard access and visibility, vim falls pretty far on the GUI side of things. Yes, it is designed to run from the command line, yes it is a text based interface, but, it isn't the same as classic CLI stuff he is talking about like the unix shells.
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.
The "killer feature" for me about CLI is related to why I love Emacs, even though there are editors with better integrated support for e.g. Python and Java. That feature is scriptability (aka macros).
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!
The main thrust seems to be that if you think CLIs are better, that's only because you haven't seed any good GUIs. To illustrate the point, the author shows an image of cmd.exe (in which somebody is playing an implementation of Zork written for a CS class.) I suspect the author has little experience with good CLIs.
GUI's also fail to allow you to chain commands, like putting the output of a find command into the cp, or allow you to pipe output to other applications.
Apple's Automator app is quite good at this. I like it for making little one-off droplets, so you can drag a bunch of files onto it and process the batch.
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.
I think the author generally made some good points there, but something important was overlooked in one of his examples.
git checkout master
You might notice there, the front command, 'git'. This wasn't launched from a special git command line, it was launched from the same command line that he was using for everything else. On the GUI side, on the other hand, you either have to to Alt-Tab some undefined number of time -it might be 1 or 5, you have to do it slowly and pay attention to visual feedback. For the CLI, on the other hand, you just type three letters and the correct context appears.
The entire conversation here is missing the distinction between "environment" and "program."
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].
I definitely prefer to use the software that accepts efficient input and provides useful output for a particular given task. That's why in my mind the clearly superior interface is [RIGHT TOOL FOR THE JOB]. When you need to get something done quickly an efficiently, you can always count on [RIGHT TOOL FOR THE JOB] without fail. Take it from me, and I have lots of experience, [RIGHT TOOL FOR THE JOB] is the right tool for the job every time.
Regarding the challenge to find an action in Windows that can be done with the mouse but not with the keyboard: Ever since XP was released it's bothered me that there was no keyboard shortcut for "New Folder". I solved that using AutoHotKeys, but Microsoft finally added ctrl+shift+N in Windows 7.
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.
"More information in your face is not universally better in my humble opinion."
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.
I'm on my phone, so I can't quite properly. But to your first point, if it's as easy as "don't look at it", then you're saying there's no reason to not up as much information on-screen as Possible. In the file browser how about we show inode and sector/block information for every file? Add a button for every possible action?
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.
If you don't find the stacktrace / variable values / whatever info useful at all, then by all means don't keep it open in your IDE. I personally find it useful and helpful in solving bugs.
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.)