Every time I look for an IDE (currently i'm tinkering with Go), I find a thread full of people recommending Vi, Emacs, Notepad++ etc.
I've never done any development outside of an IDE; I guess I've been spoiled. How do you debug without an IDE? Are you limited to just logging?
By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI.
On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx.
To get an idea of what debugging looks like / feels like from the command line, you can look at the gdb manual.
As in other areas, using a debugger from the command line requires learning a syntax and a set of commands, but brings with it a lot of flexibility and scriptability. On the other hand, if you are already comfortable working in an editor such as vim or emacs, you may find that your favorite editor has a plug in for your favorite debugger.
I used a debugger for several years while I was writing graphics drivers. I had a second computer that ran the debugger against the first one (because the screen in the primary computer wouldn't work when the graphics driver was broken). It was critical to be able to stop the code and step to the point where I hung the hardware so I'd know what was happening.
For purely software problems, I find that thinking about the problem and testing the system to learn more about the problem is much more useful than stepping through code line by line. With print statements, I have a list of everything that happened at the command line or log file that I can look at and reconstruct what happened, going backwards and forwards more easily than I ever could with a debugger.
The hardest bugs are usually solved by understanding the problem away from the computer. Sometimes with a piece of paper or whiteboard, and sometimes the answer reveals itself while I'm doing something else. The trickiest bugs are solved by looking carefully at the code like playing Where's Waldo. All the rest seem easiest with print statements, or logging statements.
Different people have different styles, and different styles are better for different tasks. Print statements are not necessarily a step down from a debugger. Depending on what you are doing, they can even be better. Especially in a language that doesn't have a native debugger (does Go?).
Some people use gdb at the command line, or a plugin. There are also standalone GUI front ends to gdb, like DDD. Depending on your language, there are language-specific standalone debugger GUIs, like Winpdb for python, or jswat for java. Because these projects focus only on debugging, they are often superior to integrated debuggers.
The other dirty little secret about IDEs is all of them worth their salt let you specify a custom editor, so you can use parts of the IDE for certain tasks, but use a decent editor for editing. It's not uncommon to only fire up an IDE to use its debugger, especially if that's what your colleagues all use.
Some languages offer a REPL - that is, you can write and execute code line by line as you write it, which can be a first step in verifying a piece of code. Many of these also offer debugging facilities. The GHC for Haskell comes with GHCi which can be used to interactively debug a program in the command line, similar to how an IDE would do.
jimwise answered the question quite well, but I thought I should add that, should you choose to work without a full IDE, the Microsoft provided command line debugger for Windows is called CDB. CDB comes with several other tools, including WinDBG which is the GUI equivalent, when you download the Windows SDK.
There's no reason why you can't use the debugger in an IDE alongside a standalone text editor. I used to use !Zap to edit, JBuilder to debug on another machine, and a fileserver in the basement. Traditionally debuggers were standalone programs without dragging along an IDE, and that works too.
It is worth noticing that comprehensive testing displaces debugging. It is worthwhile considering a reported bug to be a bug in your testing rather than in your code.
There's also printf. It can be useful to create a large amount of "logging" and search through it, rather than stopping for every line. I find particularly useful if you can modify library classes that you wouldn't be able to modify in production, for instance using -Xbootclasspath/p: to hack Java library classes.
I don't understand why there is an aversion to debugging with the use of printf statements. There was a time when it took too long to recompile and link a program, but today it takes just seconds. I find it very easy to debug using cout, printf, qDebug(), etc. type of output. Printf statements give you a running history of everything the program did, that you can analyze after the fact, whereas running in the debugger causes you to have to manually remember the flow of the program as it runs. With printf's, you can convert the value of variables to specific units, display them in hex, decimal, whatever. The printf statements can list the names of the routines and variables, and line numbers as well. You can list only certain array elements depending on other variables. You can follow indirections. You can control the output very easily, put in counters, only print certain times through a loop, add and remove print statements as you debug, have different levels of debugging output, write to files, etc. It's much easier to see the history of your program written to a file than to try to remember all the places you stepped through manually, and maybe have to write down the contents of variables as they change through time, in order to discover what the program has done. And finally, with printf statements you can leave them in permanently, to be turned on and off, for future debugging.
I don't usually use a debugger, maybe once every couple weeks but it's not the first thing I go to.
The most important tool in my job is so ubiquitous that I almost forgot to mention it--stack traces. Over 90% of the problems I encounter can be solved by examining a stack trace. This tool isn't always very helpful depending on your language, but when they are implemented well by a language they can save you an amazing amount of time.
I guess the second most common way I detect simple problems is that it's probably the code I just changed. I run unit tests quite often so I generally know what I just broke.
For more complex development and debugging I might add some debug or trace level log statements. I consider development problems a good guide to help me place production trace/debug logging information, which leads me to:
You don't always have a debugger handy. In production it might be impossible to run a debugger (Heck, it might be impossible to access production machines except for logs depending on how secure your company is). There are also languages where hooking up a debugger just takes too long or maybe there just aren't good debuggers available.
If you have been coding all along using logic and debug/trace level logging it can simply be the case of examining your excellent log statements (Possibly increasing the log level) to figure out the problem without even accessing the hardware.
Although I think debuggers are a powerful tool, don't let them be the only tool in your toolbox!
Agree that best of problems can be solved away from the computer with a pen and paper or just thinking about the problem. This is more helpful than using live debuggers. It often corrects your thinking process.
You can use pudb which is a console based with a simple user interface. You can chose your preferred debugger like pdb or ipdb if you want to enter a REPL and examine in more detail.
Also please check PythonDebuggingTools Wiki for a more comprehensive collection of tools available.
