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?

  • 53
    Oldschool printf style debugging as far as I know :-) Commented Jan 16, 2013 at 21:55
  • 25
    In the days before IDEs, we used debuggers that either attached to a running process or wrapped the process to allow stepping or introspection of the program state. (gdb, perl -d, etc...) The integration of debuggers into IDEs makes it convenient, but they do exist separately. Failing debuggers, logging... just make sure the logging doesn't change the state of the program for when it is taken back out and reintroduce the bug you were trying to find.
    – user40980
    Commented Jan 16, 2013 at 22:01
  • 7
    command line debugger, (several IDE debuggers are based on them) Commented Jan 16, 2013 at 22:17
  • 16
    Slowly and carefully. Commented Jan 16, 2013 at 22:24
  • 3
    While prints is quite common its use can hide some bugs that are more subtle such as race conditions.
    – James
    Commented Jan 17, 2013 at 3:03

9 Answers 9


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.

  • 20
    +1 for "By using a debugger". The I in IDE stands for "Integrated" :) Commented Jan 17, 2013 at 1:12
  • 1
    If you write in Python, pdb is actually better than any IDE debugger that I've found.
    – asthasr
    Commented Jan 17, 2013 at 2:28
  • 1
    @syrion And ipdb is better than that ;)
    – Izkata
    Commented Jan 17, 2013 at 14:40
  • Excellent -- I didn't know that existed, Izkata. Thanks.
    – asthasr
    Commented Jan 17, 2013 at 15:06
  • @joshin4colours integrated != collection, no?
    – Cole Tobin
    Commented Jan 18, 2013 at 22:19

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

  • 7
    This. Absolutely this. I find, that at least for me, problems tend to be logic errors or interactions that a debugger wouldn't make any more apparent. You have to understand why something is going wrong, not just what.
    – Fake Name
    Commented Jan 17, 2013 at 5:41
  • 2
    +1 entirely for going backwards. I often have the experience: "Hey - waittaminute, this isn't the right value! How did this become this?", and have to go back and forth in the output while reading the code. Debuggers are bad at backwards.
    – Izkata
    Commented Jan 17, 2013 at 14:43
  • yea, gdb is good for examining dumped core, but in situations like that, I found that gratuitous use of print statements really helped. Commented Jan 17, 2013 at 19:01
  • Debuggers are usefull but ephemeral. With a good logging framework I find I can build-up my debugging session. Use the debugger to help understand the situation, complement with print statements to make the debugging session permanent. I find that with time I sue the debugger less and less and become more and more productive
    – Newtopian
    Commented Jan 18, 2013 at 16:15
  • Yes, thinking with a piece of paper or whiteboard or just in your mind is the best way to debug. It often corrects your thinking process. Debugger sometimes is an easy way out which might not solve the original problem as to why bugs happen in your program :)
    – Nishant
    Commented May 19, 2016 at 7:19

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.

  • 1
    +1 The other option of course is to set colour scheme and keybinds on the IDE's editor, and pretend :)
    – user31713
    Commented Jan 17, 2013 at 4:08
  • 1
    @darvids0n, I have been using IDEs for something over twenty years, and I have YET to find one with an editor that even begins to hint at thinking about maybe possibly someday hinting that it might sometime next century think about trying to begin to try to hold a candle to GNU Emacs. Commented Jan 17, 2013 at 20:20

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.


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.

  • "It is worth noticing that comprehensive testing displaces debugging." -- I would say reduces, rather than "displaces". There are definite occasions where running code through a debugger is beneficial, even when performing TDD -- e.g. when a test provides a completely unexpected result, finding out exactly where it went wrong can be very useful -- admittedly, unless it's in the small chunk of code you just wrote, that means you've missed an edge case in your previous testing, but that does happen...
    – Jules
    Commented May 19, 2016 at 16:46

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.

  • 3
    "There was a time when it took too long to recompile and link a program, but today it takes just seconds". Depends on your language and size of the project. If I change a header file in my current project, it will take around 65 minutes to rebuild on a 32-CPU machine with 256GB RAM (I am not kidding) Commented Jan 18, 2013 at 16:32
  • People don't have "aversions" to debugging with print statements, they just prefer a debugger. I know a lot more "printf people" who never use debuggers than "debugger people" who never debug using printfs. Commented Jan 18, 2013 at 20:48
  • 1
    It is surprisingly hard to use a debugger for a sufficiently distributed system, but it is (with some imprecision due to clock sync issue) possible to correlate logs. If your software system is composed of binaries running on 100 different machines, logs/"printf debugging" may be easier than using debuggers and trying to keep everything in sufficient lock-step that you're not introducing other problems.
    – Vatine
    Commented May 19, 2016 at 9:48

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.

  • 4
    could you please explain in more details how does that answer the question asked?
    – gnat
    Commented Jan 17, 2013 at 6:49
  • You're right, by itself it does not answer the question. I felt that @jimwise's answer was a good answer to the question, but didn't include any information on where to find a command line debugger for Windows. So I figured I'd tack on an additional answer for those that come across this and are wondering how to do it on Windows. I will update my answer to say as much.
    – Drew Marsh
    Commented Jan 18, 2013 at 21:58

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.

  • The original question was about Go, not Python.
    – TMN
    Commented May 19, 2016 at 17:12
  • Right, I missed that somehow. It came up in my search when I was checking for a Python debugger.
    – Nishant
    Commented May 19, 2016 at 17:29

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