My name is Ram Rachum, and I'm a software developer based in Israel, specializing in the Python programming language.

This is my personal blog. I write about technology, programming, Python, and any other thoughts that come to my mind.

I'm sometimes available for freelance work in Python and Django. My expertise is in developing a product from scratch.

GitHub profile

Personal Website

6th September 2011


GUIs kick CLIs’ asses

Or, "Hey programmers, did you know you can use a GUI with the keyboard?"

This post is part 1 of the Unpopular Opinions series. In this series I will present a few opinions of mine that go against what most other software developers think. If you disagree any of these posts, you know they’re working. Please stay civil in the comments— Criticizing my opinions is encouraged, as long as it’s done in a constructive and respectful manner.

One of the big things that have been bugging me ever since I became a professional developer is that most developers shun GUIs.

As a developer, I often get to hang out with other developers and see their tools and work processes— Sometimes in person, and sometimes online. I quickly found that almost all of them hate GUIs (Graphical User Interfaces, i.e. visual programs with windows, buttons, menus, dialogs, etc.) Most programmers much prefer working with CLIs (Command Line Interfaces, i.e. a textual shell.)[1]

imageI found this baffling. Why would anyone enjoy working in front of a command-line interface, where you can’t see shit and have to remember a ton of commands and flags by heart? Surely the programmer community is intelligent and passionate enough to pick the very best possible tools, so perhaps they have good reasons for preferring CLIs?

After thinking about it for a while, my conclusion is that there are two main reasons that most programmers prefer CLIs to GUIs:

  1. Most GUIs suck. And when it comes to proper keyboard support, most GUIs suck terribly.

  2. Most programmers are ignorant about good GUIs.

But before we get to that:

Let’s compare GUIs and CLIs

There are a bunch of parameters that we can measure GUIs against CLIs on. The two parameters that are the most important for heavy computer users are Visibility and Speed.[2]


The first parameter we’re going to look at is visibility. This is the 800-pound gorilla that most programmers seem to ignore.

For the sake of an example, let’s take a simple everyday task: Say you want to copy a bunch of files from one folder on your computer to another.

If you were to do this with a CLI, you would do something like this:

 cd ~/source_dir cp file_1 file_2 file_3 ~/target_dir

On the other side of the ring, if you were to do this with a GUI, you would navigate to the source folder in your explorer/nautilus/whatever, select the three files, copy them to the clipboard, navigate to the the target folder and hit paste.

Alex E. Proimos on flickr.comWhen you take the GUI route to copying files, you get to see a lot of stuff. Some of it may not be relevant to your current needs, but some of it might be. You will get to see all the other files in the source and target folders. You will get to see how much disk space all these files take. You will get to see any sibling folders that the source/target folder might have. You will get to see the file size of each of the files you’re copying.

When you take the CLI route to copying files, you’re not seeing anything except the next shell prompt waiting for your next command. Sure, if you got everything right, you wouldn’t really need to see anything, because your 3 files just got copied and you completed the task. So what do you care about seeing all the data you would have seen in the GUI route?

Because keeping your eyes open is important.

Maybe when looking around the source folder, you’d see that there was another file that you forgot to copy? Maybe you’ll see that for some reason the target folder has more files that it should, which might indicate a problem with your system? Maybe you’ll see that some impolite package-management tool that you previously ran left a bunch of build folders that you should delete?

When you take the GUI route, you’re exposed to all of that stuff. You’re more likely to catch possible problems, or have ideas about how to improve the system.

So the scoreboard for Visibility is:

GUI - Medium to High (depending on GUI quality)
CLI - Low to Medium (depending on CLI quality)

And when our task isn’t to copy files, but to write or debug a computer program, this point becomes crucial. There’s so much shit that’s helpful to see when you’re developing! 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. Each of these pieces of data might help you solve your problem in seconds instead of hours.

imageNow sure, you can obtain all of that data on the shell too. But having to explicitly ask for it by running a command is such a chore! And what more, every time you ask for more data, it pushes the previous data up and away, as if that data wasn’t important anymore!

Do you know what this reminds me of? It reminds me of old text-based games, where you would tell the computer “Go west”, “Look around”, “Fight monster” etc., and it would tell you things like “You have killed the monster” or “You are in a room with exits to the north and east.” Aside from the nostalgic feelings, playing a game like this totally sucks! You want to see how many exits the room has! You want to see the monster you’re killing, in all its gory detail! And this is true whether that monster is a grue or a segfault.


Now we’re getting to our second parameter: Speed. The opposite of speed, when it comes to computing tasks, can be called friction. If you have to click in seven different places to finish a task, then that’s a lot of friction, and that makes for a slow process and a sad user.

Speed is obviously a crucially important parameter. When you spend 8 hours a day doing tasks on the computer, the speed with which you do the tasks makes for a night-and-day difference. Sometimes you manage to shorten a 10-second task to a 2-second task, which is nothing short of an orgasm for a productivity-minded developer. But even cutting a task down from 3 seconds to 2 seconds is a considerable improvement. Remember— We’re sitting in front of that freaking computer all day long.

It’s important to note that speed is important not only because of the time you save, but because computer tasks are usually done in order to achieve some greater goal. That greater goal often requires a bunch of subtasks, and as each of these subtasks becomes more complicated and slow, you lose sight of your original goal. Doing tasks fast allows your train of thought to go faster.

Okay, so how do CLIs fare against GUIs in the parameter of speed?

Speed is the old standby of CLI-loving programmers. “CLIs are so must faster than GUIs! A GUI is so cumbersome, you have to click here and click there, navigate through menus… With a CLI, you just press a few keys, hit enter, and presto, it’s done!”

I beg to differ.

The scoreboard for Speed, which I will promptly explain, is:

GUI - Low to High (depending on GUI quality)
CLI - Medium to High (depending on CLI quality)

The CLIs’ score of “Medium to High” is, on average, better than the GUIs’ score of “Low to High”; but when it comes to software, where copying costs are minimal, the best program tends to make all the other alternatives extinct. So in the long run we care more about the best program rather than the average program, so GUIs and CLIs end up pretty close to each other on the all-important speed parameter.

"But wait," the Vim fanboy cries, "how the hell could a GUI have anything close to a "high" speed rating?"

If you don’t know the answer to that question, I want you to really listen to what I’m about to say next, and try hard to remember it.

Because GUIs can be controlled with the keyboard!

Phew, that felt good! Now let’s explain.

The reason that programmers see GUIs as so much slower and more cumbersome than CLIs is that they try to operate them with the mouse. Working with the mouse is terribly, terribly slow. When you’re working with the mouse, you don’t have muscle memory. You always have to look at the screen for the next button or next menu item that you want to click. Not to mention that the mouse is more conducive to RSI than the keyboard, and this can be a serious health problem for heavy computer users.

To take a simple example: After you’ve learned to copy-paste by pressing Ctrl-C and Ctrl-V, you don’t need to think about them anymore; those movements become second nature. Your body and mind are good at memorizing these kinds of tasks, and before you know it you’ll be Ctrl-C'ing and Ctrl-V'ing without even thinking about it, like a pianist doesn't even think about which piano keys he's hitting. But if you were to try this with the mouse, it won't work: You'll always have to be on the lookout for the context menu after right-clicking, and then visually search for the “copy” item and click it… Friction friction friction.

Not to mention that when you’re using the mouse, you constantly have to move your right hand from the mouse to the keyboard and back, and that sucks.

And programmers often do tasks much more complicated than copy-pasting, making this point so much stronger.

So we all agree: Mice suck, keyboards rock!

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.

imageFor example, let’s look at a program I use everyday and has both a GUI and CLI interface: Git. Say I want to check-out a branch, something I do dozens of times a day. If I’d want to do that with the CLI, I’d type git checkout master. With autocompletion in place, I will have to make exactly 12 keypresses (namely, git chec{TAB}m{Tab}{Enter}.)

What about the GUI? Sure, if I’ll try using a mouse it will be an epic fail, but with the keyboard I can do {Ctrl-O}ma{Enter}{Enter}, which makes for exactly 6 keypresses. It’s twice as fast at the CLI version, i.e. half of the friction!

Now sure, some tasks can turn out to be faster on a GUI and others can be faster on a CLI, but when you pit the best GUIs against the best CLIs, they’re in the same league.

So why do programmers still prefer CLIs?

Now we can get back to the two items I mentioned at the beginning of the article, and expand on them. Those are the two main reasons that programmers prefer CLIs to GUIs:

  1. Most GUIs suck. And when it comes to proper keyboard support, most GUIs suck terribly. It seems that most developers of GUI apps don’t care so much about keyboard-accessibility. It’s all too common to see desktop apps that simply cannot be controlled with the keyboard. Buttons that cannot be pressed, menus that cannot be opened, scrollbars that cannot be moved with the arrow keys.

    This is annoying enough in mainstream software that’s mostly intended for non-technical people, but the astounding thing is that many open-source programs that are made for developers by developers are not keyboard-usable!

    I find this completely shocking. The same programmers that preach about how Vim is so much more productive than an IDE because you get to use the keyboard, suddenly put on a different face when it’s time for them to make GUIs, for other programmers no less!

  2. Most programmers are ignorant about good GUIs. Because some GUIs are good. Some GUIs have great keyboard support. Microsoft is one company that really shines in this regard. I challenge you to find one action in Windows, or in any other Microsoft product, that can be done with the mouse but not with the keyboard.

    So good GUIs exist. They can be hard to find, but hey, a lot of good software is. Google Chrome has good keyboard support. Mac and Ubuntu have okay keyboard support. Wing IDE has good keyboard support. PuTTY has great keyboard support.

    And of course, these GUI programs usually have much better visibility than their CLI counterparts, making them more productive programs overall.

Final words

I want to stress out that what I did here is a comparison between the very best GUIs and the very best CLIs. It takes time to find good GUI programs that can be operated with the keyboard. That’s tough. It takes time before you can surround yourself in excellent GUI tools to help you do your job. But it’s possible, and eventually, it’s the optimal way to work.


[1] - Actually there are some communities of programmers where most of the members like GUIs, but these are usually communities of developers that work in environments like Dot-Net and Java.

[2] - One parameter that is very important for non-hardcore users, and still somewhat important even for hardcore users, is Discoverability, i.e. being able to easily see all the different options and commands that a program gives you. GUIs obviously beat CLIs big-time in this parameter.

Tagged: planetpython

All content in this website is copyright © 1986-2015 Ram Rachum.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License, with attribution to "Ram Rachum at" including link to
To view a copy of this license, visit: