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 
the days.


More information about the spug-list mailing list