Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Rambling about debuggers

by zek152 (Pilgrim)
on Jul 26, 2011 at 14:59 UTC ( [id://916787]=perlmeditation: print w/replies, xml ) Need Help??

Recently I have been using C# (ducks to avoid projectiles) in my work. I have also been doing some "glue" work in Perl (thankfully). Visual Studio Express is the IDE used for all the C# development. Emacs is the editor for all the perl scripts.

Something I have noticed as a result of using these two very different languages (coupled with past experiences with other langues) is that the "usability" of the debugger has a remarkable impact on the way I code.

Visual Studio has a very nice and usable debugger. I like being able to see what is in every array and object. I find myself using the debugger all the time.

With Perl (and C) I find myself using the debuggers much less frequently. I don't remember ever using a C debugger and I only used the Perl debugger when I was just learning the language.

(Get to the point you say?) I find that my style of programming changes greatly in languages where I find the debugger easy to use. In C# I find myself throwing code at something and using the debugger to see if it did what I wanted. In C and Perl I will spend more time actually thinking about my code. It will crash and burn often but when it does I generally find little things in my code that could be better when I am looking for the root cause. In the end it doesn't take me longer to develop the code and it generally is better written because I don't use the debugger as a crutch.

I am not trying to say that debugging is bad. I have to debug my code regardless of the language. I had just noticed some habits about how I write software based on the debugger.

I am interested to hear people's thoughts on debuggers (not debugging) and possible changes in how they write code.

Update: changed title to read "debuggers" rather than "debugging" to more accurately represent the contents.

Replies are listed 'Best First'.
Re: Rambling about debuggers (design)
by tye (Sage) on Jul 27, 2011 at 06:16 UTC

    I appreciate a good debugger, including Perl's, and use a debugger more than a lot of programmers I talk with. But if the presence of a debugger has that much impact on how you write code, then I think you probably could benefit from some discipline to counter your penchant.

    "Design by debugger sessions" sounds like a really bad idea.

    However, the latest toy I've built (which will surely soon become a module on CPAN) has afforded some surprising uses. One of these is alarmingly close to "just throw code at the debugger" and yet it was viewed by a coworker and me as perhaps a good tool for enabling a corporate "best practice" of test-driven development.

    But I think I can resolve my cognitive dissonance by saying that my toy supports fleshing out a clear design that has been laid out by writing test cases. So I can condone the use of the debugger to work out some implementation bits so long as you don't short-circuit your time by avoiding the process of iterating your design, which is usually required to come up with code that is "well factored" and becomes easy to maintain.

    My new toy was written to allow easily stubbing out of tons of modules that I didn't have installed and suspected would never actually be used in the test cases I needed to work on. It accomplishes this in large part by just asking me what should be returned if and when any calls are made to subroutines from a stubbed-out module.

    After a while I realized that this could be really useful in TDD. You write the test suite and then auto-stub the module that you will next write (the module that will implement what the test suite tests). You can write some subroutines and then run the test suite and see which tests pass, which tests fail (meaning you have to make changes to code you wrote), and which tests ask you questions about stuff you have not yet implemented.

    That last situation offers you two choices. You can quickly fudge up some responses in order to finish that test case, probably because it is testing code you have written that just depends on the unwritten bit (which might not be the next bit you want to work on, yet). Or you can just start writing that missing bit right then, while your test suite waits for you.

    When you think you are done writing, the auto stubber sees if your proposed subroutine compiles. If not, you get to edit some more. If so, it gets appended to the source code for the module and gets loaded into the current Perl interpreter and execution simply continues.

    - tye        

      Sounds really interesting, but do I lose syntax highlighting if I postpone the coding this way? I can't quite picture it, but if I'm writing code straight into the debugger, then I think I'm losing a lot of advantages that my editor offers.
Re: Rambling about debuggers
by koolgirl (Hermit) on Jul 26, 2011 at 15:32 UTC

    Well, I guess both sides of the coin have a few cons/pros, while "throwing code at a debugger", even if it hasn't been thought through all that well before hand, theoretically sounds like bad practice, having your variable contents, etc. given to you by a debugger, still in essence helps you better understand and think through your code.

    Personally, I never used a debugger in Perl, I never could quite figure them out, so I ended up littering my code with print statements like

    if (logic = $whatIthoughtitdid) { print "Entered into 1st if statement";
    and also following every instance of strings/arrays by print statements giving their contents to me for the umteenth millionth time.

    So, whether you think long and hard about your code before hand, or you have an epiphany after the debugger shows you your mistakes, you're still learning what your mistakes were, so once again, the Perl hacker just can't seem to avoid progression.

      Mine tend to end up looking like this:

      print STDERR "Debug message\n" if $debug > 0;

      Where the number may change, giving me several levels of debug statements, and $debug gets set by a command-line accumulating switch. I also tend to leave these in production code: Removing a debug statement is a change in code, and any change in code makes it possible to add a bug, after all.

        You can achieve a similar result, but with more flexibility by using Log::Log4perl. In most of my scripts I usually write something like:

        use Log::Log4perl qw(:easy); use Log::Log4perl::Level; Log::Log4perl->easy_init( {'level'=>$DEBUG, 'layout'=>'%m%n'} ); sub doSomething { my $logger = Log::Log4perl->get_logger(); $logger->debug('some message'); }

        As written above, all the logging messages will go to your console, which is the right thing for small scripts that you are actively debugging. Later on you can reduce the log level to $WARN, so that normal debug statements are suppressed, but warnings and errors still appear.

        If your script evolves into something larger or mission critical, then you can take advantage of the expressive grammar available in Log4perl configuration files to have different log levels in different functions, to send logs to files, databases pipes etc, to send you emails on fatal errors, and to change the log level used by a running script, so if it miss behaves in production you can investigate without downtime.

Re: Rambling about debuggers
by chrestomanci (Priest) on Jul 26, 2011 at 15:40 UTC

    Interesting meditation.

    I agree that the ease of use of the debugger affects how you program, but IMHO, that ease of use is subject to how familiar and skilled you are with the debugger in question. As I wrote in a recent post, I am very familiar with the perl command line debugger, and I tend to throw code at something and use the debugger to see if it did what I wanted. For me it is other languages where I find the debugger harder to use, and as a consequence do less hacking and debugging, and more thought.

    One debug feature I miss though is the way Java debuggers will use the toString() method on an object to summarize it. Many years ago, I was working on a Java project using Eclipse. I noticed that in the Eclipse debugger if you hovered the mouse over a variable, it would use the toString() method on that variable to show you the contents. Obviously this is the correct thing to do for objects that can trivially be converted to strings, but I found that it helped to add the method to all of my own classes so that I could quickly see a summary of any object.

    This is a feature I would like to see in Perl. Sometimes it is enough so see the contents of the blessed has that is a class instance, but often there is too much detail. It would be nice if there was a standard way for a perl class to provide a method to view an object, and if all perl debuggers would use that method by default to view the object.

Re: Rambling about debuggers
by hominid (Priest) on Jul 26, 2011 at 15:33 UTC
    I primarily use C#/Visual Studio for development these days and I do appreciate its debugger. I haven't noticed a big change in my development habits, though I am more likely to use the debugger now as opposed to tracing through my code mentally and/or using print statements to watch a variable. It's simply much faster to use the VS debugger. I only used Perl's debugger once or twice when I was really stumped on a problem and it was worth the time trying to figure out how to use it.
Re: Rambling about debuggers
by zentara (Archbishop) on Jul 26, 2011 at 20:28 UTC
    Have you tried Devel:ptkdb, because I wonder how they compare? Is the VS ide debugger superior in someway? I have to ask you, because I hardly ever run Windows, and sure wouldn't pay for an Windows IDE. :-)

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh

      As I have never tried Devel:ptkdb I can't comment as to a comparision. I will note that I did not pay for a windows IDE because I am using the Express edition of Visual Studio.

      But I was mostly commenting on how not using an integrated debugger (when I use Perl and C) leads me to write code differently. I'm not trying to start a debugger war (however anteaters might be the best debuggers ever).

Re: Rambling about debuggers
by Jenda (Abbot) on Jul 28, 2011 at 14:12 UTC

    Considering the quality (method GetFoo() : returns a foo. Fullstop.) of C# docs, debugger is quite often the only sensible way to find out what the heck is the method returning and where in the object it returns I might find the snippet of data I'm looking for. Generated documentation is just great ... in 98.7491% of cases you get as much information as you would from reading the name of the method and the parameters.

    Enoch was right!
    Enjoy the last years of Rome.

Re: Rambling about debuggers
by GotToBTru (Prior) on Jul 27, 2011 at 14:35 UTC

    I use the Perl debugger alot. I postponed learning about it, and am now sorry I did. I would really encourage those who have code liberally sprinkled with print "Did I get this far?\n" to invest the half hour to read through perldebtut and try a few things. You will gain back that time, and much more, next time you have to debug something.

Re: Rambling about debuggers
by cdarke (Prior) on Jul 29, 2011 at 14:15 UTC
    I have been using Visual Studio since it was Visual C 1.5, and its hard to find a better one for debugging C. I even managed to integrate Perl within it in VS 6.0, but could not figure how to do that with the .Net versions.

    A language like C, with a large application, really needs a decent debugger, although I guess it does depend on how many bugs you write. I have used line-by-line C debuggers like adb, sdb, gdb, on UNIX/Linux and breathed a sigh of relief when the development plan brought me back to VS.

    With Perl I have had to use the line-by-line debugger a few times, usually with obscure, deeply nested, bugs. It's not difficult to use if you have an idea where the bug is (a good reason for functional decomposition). I teach Perl, and it is sometimes useful when a student has a bug and yet the code "looks right". Mind you, after ten years of doing that I have a good idea of the most likely bugs they produce.

    It is unfortunate that many Perl IDEs have a steep learning curve. Eclipse with e-p-i-c is quite nice, but can't be put in front of a newbie. Padre also appears to be very good, if only I had time to figure out how to configure it to use different Perl versions. It has to be said though that VB programmers are singularly unimpressed with vi, but your average Linux developer considers even kate (KDE text editor) to be a bit "nancy".

    Talking of VB programmers, I have met quite a few that can't really tell the difference between the language and the IDE ("in VB you do this-and-that"). Here's a thought, would Perl be more popular if it came bundled with an IDE, hopefully a better one than Python's IDLE (e.g. Padre)?

    Throwing code at a debugger and seeing what comes out is, I guess, a sign of the times and of RAD tools. My heart says "yuk!", but my head says, "what the heck, if it gets the job done".
Re: Rambling about debuggers
by sblanton (Sexton) on Jul 29, 2011 at 19:27 UTC

    Eclipse with the EPIC plugin has a VS-like debugger. You can always see your breakpoints when editing code, there is a grid of variables that changes in real time as you step line by line through the code, and the standard debugging stuff. I find drilling down into objects to view their attribute values very useful.

    I used to use VS and Eclipse simultaneously on the same desktop to switch between VC++ and Visual Studio with Perl and Java in Eclipse.

Re: Rambling about debuggers
by DrHyde (Prior) on Jul 27, 2011 at 09:33 UTC
    When writing the sort of code in perl that would benefit from use of a decent debugger, I tend to write much better unit tests to make up for the lack of one.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://916787]
Approved by Corion
Front-paged by Corion
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-05-27 21:20 GMT
Find Nodes?
    Voting Booth?

    No recent polls found