Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Isn't this a duplicate of your previous question: programmers.stackexchange.com/questions/82519/… ? –  Charles E. Grant Jun 18 '11 at 21:28
1  
@Charles: Kind of yes, kind of no. Go on chat and take a look at my chat history with a couple of others if you're interested in where this is coming from. –  Mehrdad Jun 18 '11 at 21:30
1  
@Charles It's a new and improved version of that question. Editing the old one would invalidate the answers it got, so we chose starting from a clean slate instead. –  Anna Lear Jun 18 '11 at 22:10
    
It doesn't have to be either-or. For example, you can tell visual studio to build a solution from the command line. The solution and project files are much more convenient to edit through the GUI, but that doesn't mean you can't use them in a command-line build process. –  Steve314 Jun 19 '11 at 3:45
add comment

6 Answers

up vote 4 down vote accepted

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.

share|improve this answer
2  
The first point, equivalents to intellisense and "go to definition" are available both on emacs and vim. The second for debugging I also do think a GUI is more practical. I don't know what Debugger Canvas means so I can't talk about it. –  Vitor Jun 18 '11 at 22:19
    
@Vitor: if you're interested, see msdn.microsoft.com/en-us/devlabs/debuggercanvas for a 5 minute video of the Debugger Canvas –  Carson63000 Jun 19 '11 at 7:02
    
+1 indeed, I can't imagine how you'd have all those of Visual Studio's features in a terminal... –  Mehrdad Jun 21 '11 at 16:30
add comment

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.

share|improve this answer
2  
+1 - command lines are easily automated –  user1249 Jun 19 '11 at 10:53
    
+1, same reason –  Mehrdad Jun 21 '11 at 16:30
    
+1 great answer –  user61852 May 29 '13 at 12:14
add comment

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.

share|improve this answer
    
+1 Reminds me of that Dilbert with the "Unix guy": Here's a quarter, kid; go buy yourself a better operating system. :) –  luser droog May 29 '13 at 1:08
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

"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?)

share|improve this answer
2  
Congrats to Stack Exchange. I just created an account after planning to remain anonymous, only because of their excellent registration user interface. –  Teris Riel May 29 '13 at 0:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.