SPUG: re:humble print statement for debugging
Marc M. Adkins
Perl at Doorways.org
Tue Mar 23 16:06:38 CST 2004
On Tuesday 23 March 2004 01:03 pm, Andrew Sweger wrote:
> On Mon, 22 Mar 2004, Kristi Anderson wrote:
> > I've just recently added perl to the list of languages of which I know
> > just enough to be dangerous. One thing I've noticed about all of them
> > is that you can almost always easily figure out how to use print or
> > show or display or printf or cout, but to learn the debugger of each
> > is considerably more time consuming.
> But that time pays big dividends. Every person I have taught how to use
> the Perl debugger has exclaimed how they could have saved so much more
> time in the past had they known how to use it. Of course, the same can be
> said for so many other time saving bits of knowledge too.
I find that any new software environment presents a debugger-related learning
curve. I tend to put off learning it until I think that the cost of getting
over the first hump of learning to build a debugger version and the
peculiarities of whatever debugger I'm using (it does WHAT?) will be offset
by time saved in solving the problem. But them I'm just lazy.
Having said that, I think it doesn't apply to Perl. Seems like I used it a
bit several years ago and no fuss, no muss. Yet I still find myself not
using the debugger. I don't remember why I didn't find it compelling, I
remember it working just fine. Perhaps just (bad?) habit.
I do have as an alternative a fairly powerful trace logging system. In
addition to a flexible, low-overhead trace statement filter I use an output
stream that understands timestamps, message types, and indentation. When
properly used, which is pretty simple, it presents a really clear picture of
code execution, especially with complex, recursive code. In production it
allows filters to pull errors out of the log stream for summation,
notification, or display.
Perhaps it's the type of problems I solve with Perl. Right now I'm processing
batches of 10,000 - 20,000 documents at a time. The jobs run forever and
errors may occur in 2 minutes or 2 days. So my only hope is really good
logging (i.e. trace statements).
My all-time favorite debugging environment was the 80's LISP machines. Both
Xerox and Symbolics environments would pop up a debugger window without
actually 'running' the debugger. Everything was symbolic so there wasn't
really any debugger to run. When an error happened it triggered the debugger
window, from which one could twiddle data, edit code, and continue (or
re-executing a containing stack frame) as if nothing had happened. Them were
More information about the spug-list