== Why print-based debugging is so popular

A recent
[[ONLamp article|http://www.onlamp.com/pub/a/python/2005/09/01/debugger.html]]
on the Python debugger included the line:
> The only time we reach for a debugger is when something goes wrong
> or breaks and our standard debugging techniques such as _print_
> statements (or better yet, log messages) do not reveal the root of
> the problem.

This sparked an insight about why _print_-based debugging is so popular.
(It is; a surprising number of people swear by it, and get good results.
The quote got my attention because it made me go 'yeah, the author
understands how I work'.)

In debugging the most important thing is to look backwards in time,
because you are trying to answer the question 'how did I get into this
pinch?'

Print-based debugging builds up information about the history of your
program as it arrives at the fatal point. All the information you
print or log creates a trace record that you can then walk backwards,
determining the relevant bit of your program's past state.

By contrast, debuggers have historically spent a lot of effort on
moving forward in time (single-step, continue to next breakpoint, and
so on) and relatively little effort on sophisticated ways of examining
program state.

If you want to trace your program's evolving state in a debugger,
usually what you wind up doing is inserting print commands in a
language that's worse and more awkward than the one your program is
written in. Is it any wonder so many people skip the middleman and
just put the print statements directly in their program?

In hindsight I don't think it's any coincidence that
[[UPS|http://ups.sourceforge.net/]], my favorite C debugger, lets me
dynamically insert _printf()_s into C programs and is pretty
good at showing program state at a glance.