Re: Programming Mantras

[Dominus]

Says dws:

     my $html = $template->expand(\%bindings);
     return $html;

... he was always on the lookout for places where he would later need to place breakpoints to examine intermediate results while debugging...

It seems to me that if you're writing wasteful code because it affords a better opportunity for debugging, the conclusion shouldn't be that the wasteful code is better, but that you need to get a better debugger.

One of my hobby-horses is that the state of the art in debugging tools is really crappy. If you look at the debugger programs of the 1960's, you'll see that they are not substantially different from what we have today. Debugging tools have hardly gotten better in thirty-five years. I think that's really shocking.

I think there's something to be learned from your example, but it isn't that you should write more verbose code to save intermediate results into named variables; it's that the debugger should be improved so that it provides better access to the intermediate results.

You should be able to write something like this:

  return $template->expand(\%bindings);

and then tell the debugger that you want to place a breakpoint after the call to expand but before the return, and examine the value that will be returned. It wouldn't even be hard for the debugger to get at that value; it's right there on the top of the stack.

Why can't you do this now? It's not a technical barrier; it's a social one. We've gotten so comfortable with using crappy debuggers that we don't stop to notice when the debugger is making our lives difficult, or to think about how it might be improved.

I'd like to see folks do more work on debuggers. Perl makes it especially easy to do that, because the debugger is written in pure Perl; you can just make a copy of perl5db.pl and start hacking on it. perl5db.pl is very simple; it's just a big loop with a giant if-else tree that looks to see what command you entered. To add a new command, you add a new branch to the tree. The information about breakable lines and breakpoints and soforth is all stored in straightforward Perl arrays and hashes, and it's all documented in perldebguts.

The change I suggested above might be a little harder, because at present there's no support in the internals for stopping anywhere except at the beginning of a statement. But with a little XS support, you could still extend the debugger to do it; it would only require a little extra expertise.

I'd really like to see more people experimenting with the debugger and finding ways to make it more effective. The current state of the art in debuggers is an embarrassment to the programming community.

--
Mark Dominus
Perl Paraphernalia