Why do people use Command-line instead of IDE?

Question

Hi I am learning C++ and at the very beginning used a Command-line... then I started using Xcode (and since then couldn't switch back to command line) and was just wondering some specific reasons/situations to use Command-line instead of IDE...

Answer 1

You use command line when you want to automate your software builds. That's typically done when you are ready to release your software, and you need to do other things such as installer packaging in addition to software compilation before you can deliver the software to the users.

Beyond that you should always use an IDE for debugging, compiling and code editing purpose.

Answer 2

More efficent for large systems - Try opening a VS solution with a 100 projects and 10,000 files.

Simpler for a lot of tasks, you edit in one window, run make in another, have gdb in a third.

Easier to automate tasks, often easier to work in teams or cross-platform if everyone has gcc and vi (or emacs)

Answer 3

A big one for me is the editor. I really love vim, and it's pretty rare that an IDE has good vim emulation - especially since I use dvorak and have to remap a lot of the keys. For a lot of other people, they'd say the same thing except that they'd choose emacs.

Most IDE editors pale in comparison to the like of vim or emacs. There are features that you miss out on or are a lot harder to get to work well. For instance ctags definitely helps you be able to hop to the definitions of functions in vim, but it is nowhere near as good as a lot of IDEs can do since they actually understand the language. And of course, debugger integration and project management and the like aren't going to work as well in vim or emacs because they're not full-blown IDEs (though you can do a lot of that stuff with them). But often, the power of vim or emacs overshadows whatever the IDE has over them.

Also, as far as command-line editors go, they can be run on the command-line when you don't have access to an environment with a GUI, so there are plenty of situations where that flexibility is a big plus.

Of course, it would be great if you could combine all of the great features of vim or emacs with a full-blown IDE - and there are some attempts to do so - but there are always problems with it, and even the best attempts are far from perfect. So, you're often still stuck with the choice of vim or emacs and the features that they bring or an IDE with the features that it brings.

EDIT: Going into why vim or emacs is far more powerful in many respects than your typical IDE could get quite lengthy, and there are already several questions on SO which cover that.

This is a great answer on emacs: http://stackoverflow.com/questions/35809/why-are-vi-and-emacs-popular/35929#35929

This is a good article on vi that seems to get linked to frequently: http://www.viemu.com/a-why-vi-vim.html

For a quick attempt on my part to give some reasons why vim is more powerful:

Your typical IDE is basically a souped up notepad from a text-editing standpoint. You type in text and use your mouse to navigate around (which while sometimes quite useful, it can be quite a bit slower than just using your keyboard). They add code-specific features like code completion, automatic code indenting, the ability to jump to function definitions, refactoring tools, etc. (hence why IDEs can be so useful) But their basic text editing abilites are generally pretty poor. They might add some useful features like ctrl-d to delete a line, but what they add is generally very limited compared to what you'd get in vim or emacs.

Take deletion (a very basic operation) as an example. In vim, you can use the delete operation with any motion command, making for a potentially staggering number of ways to delete things.

• dd Delete an entire line.
• 5dd Delete 5 lines.
• dj Move the cursor up, deleting everything to the left on the current line and everything to the right on the line above.
• dG Delete everything from here until the end of the file.
• 7dgg Delete everything between here and line 7.
• d% Move to the brace or paren which matches the next paren or brace (whichever comes first) and delete everything between here and there, including the brace or paren that you jump to
• dw Delete everything between here and the next beginning of a word
• de Delete everything between here and the next end of a word
• D Delete everything between here and the end of the line
• d0 Delete everything between here and the beginning of the line
• d^ Delete everything between here and the beginning of the first word on the line
• dty Delete everything between here and the next occurrence of y on this line (or nothing if there are no y's between here and the end of the line)

The list goes on and on. And that's just for delete. The same goes for a whole list of other basic commands. And that's just basic commands. There are many, many more commands which are more advanced and quite powerful. Vim can do so much that most people who use it use only a fraction of what it's capable of.

Most IDEs don't even have a fraction of a fraction of such editing capabilities. They have many other programming-specific and language-specific features which vim and emacs either lack or in which they are much harder to get to work - such as good, context-sensitive code completion, refactoring tools, project management, etc. But as for text-editing capabalities, most IDEs just can't compare.

Answer 4

Commandline builds can be automated, and using standard tools such as CMake for your commandline builds make such builds cross-platform (note you can build an Xcode project from the commandline using xcodebuild, but that only works on Mac OS X with Xcode). Automation is incredibly important, because it allows you, for example, to create a "hook" for your version control system to build the project and reject code that doesn't compile or to have a continuous integration server periodically build your project, so that you can easily tell when breaking changes to the code have been made and fix them quickly.

In addition to portability and automation, the commandline is just faster. If you are using a Makefile project or something like the C++ Project Template which uses CMake but has a Makefile wrapper, then all it takes is the simple command "make" to build. The second time you build, you only have to hit the up arrow, and then hit ENTER for it to rerun "make". Although beginners with the commandline may be not be very fast and may find the GUI / IDE easier, once you have used the commandline for a while, it becomes much much faster than doing it with a GUI, and all those mouse movements and clicks seem slow and a waste of effort.

Answer 5

At least in UNIX, the command line tools are mature. The bugs I have to deal with are highly obscure at this point. vi, make, gcc, gdb - these tools are, in some cases, 20 years old or more. Tried, tested, proven.

Also, they are ubiquitous. Everyone has vi, make, gcc. I don't have to worry about not having my tool-du-joir. I can go to virtually anyones box, and no problem, I can compile, write, debug without any need to learn some fancy tool.

Answer 6

First, there's the increased choice. If you use an IDE, you use the tools that are specifically compatible with it, which may not be the tools you prefer. There are a lot of things that you can get in an integrated package or as components, and people go both ways.

Second, lots of developers got used to Unix tools, which are mature, very powerful, and meant to be used by themselves. There isn't a tradition like that on Microsoft Windows, and IDEs have ruled there since Turbo Pascal. (The big advantage Turbo Pascal had was that, in the days before any sort of multitasking, it wasn't necessary to start and stop the editor, then run the compiler and linker separately before running the test.)

Third, it's really, really easy to automate anything you'd do from a command line. It's harder to do such things in a GUI of any sort, both in that the tools are much harder to develop and in that they're harder to learn. Again, there's a culture gap here, as the Unix tradition is to deal with complicated procedures by automating them, and the Microsoft tradition is to build GUIs and wizards.

Fourth, for handling complicated systems, there's still no method clearly better than a human-readable text representation. The syntax of Unix makefiles is bad, but it would have avoided the issue I had recently, where the configuration of an after-build step in one setup of a Visual C++ project file was wrong in one case, and it was hard to spot. Using a makefile and vim, I can simply and reliably change how a given project will compile and build. It's a lot harder with Visual Studio.