

GUIs kick CLIs' asses - cool-RR
http://blog.garlicsim.org/post/9875143930/guis-kick-clis-asses

======
acangiano
>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.)

~~~
cool-RR
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.

~~~
ordinary
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.

~~~
cool-RR
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.

------
cheald
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.

~~~
cool-RR
_"When I hit "Ctrl-O", I wait a bit for the dialog to be presented and become
ready for input."_

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.

------
drats
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.

Complete trash, flagged.

~~~
cool-RR
If unix shells or powershell give you visibility on the same level as a GUI,
I'd be interested.

------
kabdib
+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.]

~~~
exDM69
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.

~~~
cool-RR
Again, programmer ignorance about using GUIs with the keyboard.

 _"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.

~~~
exDM69
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.

------
gurraman
Other reasons I prefer the CLI (most of the time):

\- 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

------
sophacles
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.

------
drunkpotato
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!

~~~
cool-RR
I use a scriptable IDE called Wing IDE (for Python only.) I wrote about 5
scripts for it and I use them every day.

~~~
drunkpotato
What do you do for Java?

~~~
elangoc
I think most people agree that Eclipse is the best IDE for Java. Granted, it's
not scriptable, per se, if that's what you were wanting to know.

------
mstroeck
Is it just me, or is the entire article 100% hand-waving and ridiculous
assumptions?

~~~
AlexC04
> In this series I will present a few opinions of mine that go against __what
> most other software developers think. __

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.

------
scscsc
He's missing scriptability, modularity and extensibility.

Also, most GUIs (that programmers care about) lag behind the CLI in features
(i.e. command-line GDB vs graphical debuggers).

~~~
scdef
Not to mention plugability -- can't remember the last time I had a GUI feeding
another GUI input through a pipe

------
adamtj
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.

~~~
kabdib
Or, for that matter, with text adventures.

------
jvc26
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.

~~~
drunkpotato
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.

------
Symmetry
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.

------
asolove
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].

[1] <http://en.wikipedia.org/wiki/Jef_Raskin#Career_at_Apple> [2]
<http://en.wikipedia.org/wiki/OpenDoc>

------
beej71
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.

------
asynchronous13
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.

~~~
cool-RR
Pasting from the blog comment:

Alt-F -> W -> F.

I shortened it to Ctrl-Start-F on my own machine using AutoHotKey

------
aredington
This reminds me of [http://steve-yegge.blogspot.com/2008/02/portrait-
of-n00b.htm...](http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html)

------
revorad
This is a flame war topic, but the "zork2" gameplay image made me laugh out
loud.

------
mhd
…for certain values of GUI and CLI

------
adgar
He has 2 general points:

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.

~~~
cool-RR
_"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.

~~~
adgar
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.

~~~
cool-RR
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.

------
pointyhat
My view on things...

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.

------
allcapitalized
I hope you're trolling son.

