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

[download]
... 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);

[download]
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

In reply to Re: Programming Mantras by Dominus
in thread Programming Mantras by dws

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.