Debugging the Old-Fashioned Way

I can usually see people making fun of using "print" statements to debug code. "That's so old-fashioned: haven't you ever heard of a debugger?"

Debuggers can be fine things. And if you're going to be working with a language a lot, pays take time to learn its debugger.

But the other day I was asked to debug some Perl code for someone. This group had been stuck, for a couple of months, not being able to process some important data because they couldn't figure out how to get this program to handle it.

I haven't worked with Perl for a dozen years. I think that I recall it has a debugger, but I have no memory of how to invoke it, let alone what its commands are. But I looked the code over and inserted a print statement.

Hmm, that's not the problem. Insert a second print.

Nope, not that either. Insert third print.

Bingo! An entry had to be made in a secondary file before the code would process the new data.

It took me less time to find the problem than it would have taken me to figure out how to bring up the Perl debugger and set a breakpoint.

Sometimes, grandpa's way is the best way.


  1. Back in the dark ages I once wrote a preprocesser to insert printlns in blocks of code between special comments. It would echo each line of code.

    But a break point debugger is the greatest programming tool ever invented!

    1. Ken, I am all down with debuggers. I once proved to Convergent Technologies that their C compiler had a bug by stepping into assembler:
      I had written:
      return(x + y)
      I showed that they failed to push the result of "x + y" onto the stack. (They tried to claim that I "ought" to have written:
      z = x + y
      My only point is that print statements have their purpose.

    2. Ha! Your code is legal C for sure. K&R would have sneered at using a "return variable" z!

  2. That would be identical almost to making fun of log files. Which would be insane.