Let me concur with your statement and add a few cents on my part. I too started out with 'just print statements'. And, oh boy, it was getting on my nerves many a times. I did print statements since the very first time I started coding (at age 13 I believe) with BASIC. I then used prints in Pascal code (I didn't have a good debugger back than). Even when I moved to C I used prints. In many cases it's 'alright', but nothing more.... just about 'alright' to use. However, (and I assume for many it would seem like a mute point) I didn't find putting random (well, at least the first time I need to work on a piece of code that I've never 'debugged' that way before) print statements as helpful and efficient as setting a few breakpoints throughout my code and letting the program run until these points are reached. The problem that I experienced with the print statements was that I'd always have to re-run the code a number of times to just get my print statements placed in the right place and output just the right stuff to get at the root of a bug. This wasn't good for me. Recently (when I started working full-time) this wasn't good for my boss since I found myself wasting too much time playing with prints etc (on systems exceeding 30,000 lines of code in particular).

So, a few years back when I first started with Perl, I thought that this is the one language where I'll try to do it right (and different!) When I had my first look at perl interactive debugger, I immediately thought "Who in the world could you such a horrible and complex tool?!". Well, to sum up, I was utterly wrong. Once I played with it a bit more, I figured that it was more useful to my productivity as a programmer than my old limbo with prints etc. I frankly find it hard to understand marlyn and others who say that doing away with prints is much easier. See, I was in your camp at one point as well. However, how easier could it be to simply place a few break pionts in your code and let the program run until these points are reached and do your testing (on 'faulty/suspicious' data) right there, poke it around, execute different variants of a program statement that you suspect might have a bug, etc. There's really that much use in a debugger. Now, I'm not even talking of those point and click debuggers. I don't like those in particular. However, perl's interactive debugger (where I can get away with not using my mouse) is superb for many debugging needs one might have. It's pretty quick.... there's much I could say about various debugging techniques that the perl debugger allows for and that I've come to appreciate.


"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith

In reply to Re: (tye)Re: Are debuggers good? by vladb
in thread How to debug unknown dynamic code? by gaspodethewonderdog

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.