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
|
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
