How does a CLI-oriented programmer's workflow differ from a GUI-oriented one?

Question

I've heard a lot about the advantages of doing less programming work in GUI apps and using more command-line tools (especially with regard to getting things done more efficiently). However, since I don't understand how my workflow would be different if I depended more on command-line tools, I can't readily evaluate whether there's enough of a payoff for me personally to invest time and effort learning a new toolset and changing my workflow.

Right now:

• I code some side projects in languages like C/C++/D/C#/Java/Python using Visual Studio, Eclipse, etc., and run them by setting up the build settings, and pressing F5 to build/run.

• I'm developing a web program at work, so that involves using Django to set up a server, connect to a database, etc... almost all within the SciTE text editor.

• For launching regular programs, I use Launchy... still no terminal. :)

• For copying files and whatnot, I use a regular find/move in the graphical file manager (Windows Explorer, Nautilus).

• Debugging: I use either Visual Studio or Debugging tools for Windows (if I'm on Windows). I haven't done much debugging on Linux, but for the things I've done, I've used Eclipse (also for Java on Windows).

• At work: To connect to the build system and set up a project, I just use tools that have been integrated into Eclipse for my use -- no need for a terminal or anything (although I'm certainly welcome to use a terminal if I indeed want to)

What is it like to do these things in CLI? Which parts become more/less efficient? Which aspects of my workflow would need to be changed to get the greatest advantage from a shift to working mostly in CLI? In other words... If you magically transformed me into a command-line guru, how would my new coding workflow be different from my current, GUI-centered, way of doing things?

Answer 1

I don't think that this is true anymore. CLI has a specific advantage- if you know in advance what you're looking for, then you can type it faster than you can navigate to it in a menu. This means that if you explicitly want to issue commands to the program that have little context, then it's mostly faster. However, there are two problems.

Firstly, GUI programs can infer context for you. For example, Visual Studio's Go To Definition feature and Intellisense. How could you replicate those features in a CLI?

Secondly, GUI programs can display a lot more back to you. For example, the Visual Studio Parallel Profiler, which is a graph of CPU usage across multiple cores over time. How could you display that in a CLI? It just wouldn't make sense. As soon as your data would be better expressed as something other than text, CLI is instantly lost. Another easy example is breakpoints. In Visual Studio, you click in the margin of the line you want broken on. What are you going to do in a CLI, try to find the file and line number and enter that command? That's going to take you a relative decade. That isn't even counting some of the newer GUI innovations, like the Debugger Canvas.

A GUI might be slower if you want to spend your time pushing Debug over and over again, but as soon as the use cases become more complex, then there's no way that CLI can keep up.

Answer 2

I think the biggest difference doesn't lie on the individual tasks but on two things:

First and foremost, automation. CLI is inherently scriptable which is usually harder on Windows. I've heard things improved with PowerShell but I haven't used it.

Second, the UNIX philosophy of "separation of concerns". I can write a small readline-based interface to something and using emacs M-x shell use it inside emacs GUI. This makes simpler to leverage other tools and existing functionality.

For debugging gdb works well but I usually prefers VS debugger. It's probably the best piece of software Microsoft ever did.

For building and running things: make. Or bash. Wherever.

For development: emacs (recent convert from vi, oh shame!). Vi if doing work through ssh.

I really can't get used to Eclipse. I think it's a "shape of mind" problem: it doesn't fits mine.

Answer 3

For me, switching to a CLI workflow from Visual Studio involved memorizing a lot of *nix commands. It also involved some headaches whenever I messed up a SVN checkin.

But the biggest difference in workflow for me was that I gained a better understanding of how an operating system works. With a GUI workflow, it was just clicking buttons and waiting for the program to respond. In command-line world, I feel like I'm telling the computer directly to do something.

In other words, a GUI workflow was the computer communicating back to you, while a CLI workflow seemed more like you're communicating directly with the computer.

One isn't better than the other, but making the switch from a totally GUI based environment into the terminal was definitely a trip.

Answer 4

Here are more observations from a programmer who has lived in both worlds. I won't repeat points already made in other answers:

CLI-based development tends to use a variety of programs, each of which performs 1 function. GUI-based development tends to use 1 big program (the IDE), which performs dozens of different functions. This one difference has several consequences:

Because an IDE is intended to be your one "home" where you work all the time, they may use a proprietary (perhaps binary) format to hold your data. Compatibility isn't a big concern, because they don't expect you to work in 2 different IDEs on the same project. CLI tools, on the other hand, generally just work with plain text files.

With CLI-based development, you can incrementally switch out tools, or integrate new tools into your workflow, more easily. Choosing an IDE is more all-or-nothing, and switching your IDE is more painful.

Using a CLI build script, rather than an IDE's built-in "Build" menu, makes it more likely that you can walk away from your code for a few years, come back to it, and build it without fuss. With GUI-based development, it's likely that you are running a completely different IDE by then. Perhaps the one you were using when you wrote the code doesn't even run on your current OS.

In an IDE, building your own tools means learning a (probably large) plug-in API, and perhaps using a specific language. When using the CLI, nothing special is needed to make custom tools.

On the other hand, the advantage of an IDE is that it is, well, "integrated". So you can click in your editor window to set debugger breakpoints, and so on.

Another point: your choice will also depend on the development platform, OS, and language(s) which you use. On certain platforms, IDE-based development is deeply ingrained in the prevailing development culture. In others, CLI-based development is prevalent. If you are using a platform where IDE-based development is prevalent, it is likely that CLI tools will be poorly developed and poorly supported. The converse is also true.

Answer 5

Most of my childhood was not spent on a computer since we did even have internet out on the farm. I started programing late in high school and basically worked in GUIs all the time. In college I met a guy who grew up on CLI and did everything that way. So I decided to setup a linux server rather than listen to the prof. After a few years my buddy was watching me write some embedded code and could not believe how I wrote.

I basically use half CLI half GUI. There are some things that GUI bundled environments do much much faster and more efficiently. And the same is true for the CLI. Most of my text editing is done in VIM as the advanced CLI editors VIM/EMACS (no wars here please) make text manipulation the most efficient. Things like Embedded debugging using GDB on the other hand, is as painful as editing text without a keyboard. Sure its powerful and sure with enough time you will find the information your looking for but having a nice GUI window with instant access to any memory block is invaluable especially when trying to compare it to another memory block.

Anyways what I am really trying to say is that it should not be GUI vs CLI but rather what is CLI better at and what is GUI better at. Because in the end if your IO is slower than your thought process there is a problem.

Answer 6

"converted into a CLI guru overnight?" Aye, there's the rub. Well-designed GUIs tend to be more discoverable than CLIs, and more forgiving to the newbie.

My workflow, recently enhanced by a tiling window manager (dwm), consists of a lot of typing. My laptop is now actually usable without plugging in a mouse (The trackpad is adequate for what's left of pointing). I keep a lot of apps open and switch with alt-tab. I don't waste time moving and resizing windows.

Most of the time, I use a browser, vim, and a bunch of terminals. SSH gives me a lot of flexibility as to where I work (physically). Remote desktops may offer a better experience when we all have 10Gigabit pipe to the net, but I won't hold my breath.

I haven't learned vim well enough to take advantage of its complex features, but I am leaning in that direction -- I want to have vim jump to the right line # after a failed make. (Technically vim is a Visual Interface, even though it runs in a terminal, but I drive it with a keyboard, not a mouse.)

The real problem is poorly designed interfaces. Well-designed interfaces are hard to create, so they don't happen very often in either camp. But since more non-ux-wizards are designing GUIs today than CLIs, ....

(My other big pet peeve is bloat. When it takes a 19MB program to help me accomplish the same task as a 200kB program, something is wrong. XTree Gold for DOS enhanced my productivity more than any modern file manager. Windows 2.11 used only tiled windows. Turbo C was an awesome IDE. Why does my Nook seem to run slower than a Mac classic? Why does the kernel alone now take up more disk space than the entire system used to take?)

Answer 7

With graphical user interfaces, you are forced to interact with the program repeatedly to perform the same operation over and over again. With a shell, you can automate things more readily, and have programs work together through piping – which could for instance be used to output matches to regular expressions in a set of files or network packets. As said, it is faster for many operations.

Programming in the terminal is perhaps not so much better than in a graphical editor, unless you use SSH.

I personally found the unix shell much more approachable than the typical Windows command line, and am now very immersed in it on a Linux system with a tiling window manager and lots of terminals.

Answer 8

All of your examples are pretty much a one step process. In most GUI environments, if you wanted to move a file that had nothing to do with the current application you're in, you could do if from the file menu without leaving the application. No sense going to a command prompt. If you wanted to copy the file and give it a different name, on a command-line you can do this all at once. To put this in a batch file, you at least need to know how to do this, but you could then execute the batch file from the GUI if you wanted.

I've had a similar debate over keyboard commands v. the mouse.

Answer 9

The way I work favours GUI by far.

Typical usage:

• Three IDEs for three different platforms. Also a Notepad++ window for some scripts. There's simply no way I would be able to remember commands for all those build systems. The problem with CLI is you need to know a lot of details just to get a build working. Modern IDES normally have some appropriate options in there by default. You can always have a closer look when the time comes.
• SVN or Git integrated. There's so many options for a program which is ancillary to programming, and most of the time I'm only doing commit or update.
• Network stuff: Lucky me, I get to do all the network setup in our office as well. Most of the network boards will give you a load of CLI commands, but if there's one thing where you need an overview of state, it's firewall and routing. For routing I can just about live with command line, but firewalls get complicated, and if there's one thing GUIs are good at it's displaying lots of info.
• Generally there's a lot of moving from one thing to another. Contexts switches are easier with a visual context.

As for the main benefit of CLI, scripting, I barely ever do that. The repeated tasks we have are just cron job apps that's we've thrown together in c# and not often changed. We do have ways to get things running in Linux, but mainly it's ported (boost), so messing about with files and such things are minimised. And if things get hairy, there are good IDEs for Linux too.