BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Debuggers considered Harmful?

Debuggers considered Harmful?

This item in japanese

Bookmarks
Giles Bowkett writes in Debugger Support Considered Harmful:
Asking why Ruby has weak debugger support is like asking why a dolphin doesn't have gills. Ruby has weak debugger support because Ruby programmers shouldn't be using a debugger. Ruby supports TDD and BDD better than any other language except possibly Smalltalk. Debugger support is for languages that you can't run tests against gracefully.
Note: TDD refers to "Test Driven Design/Development", BDD to "Behaviour Driven Development".

The article caused a wide range of responses, many among them from the Smalltalk community. These are particularly relevant, as Smalltalk and Ruby are close relatives. James Robertson, of Cincom Systems, went as far as recording a screencast, showing the usefulness of the Smalltalk debugger while doing TDD:
I wrote a test, ran it. It failed. I debugged the test, had the debugger create the missing method for me - whereupon I wrote the code for the method in the debugger, and ran the test again. That's not a crutch: it's taking TDD to the next level.
Avi Bryant, creator of the Smalltalk Seaside web framework, chimes in:
What Giles glosses over is how you come to understand the code in the first place. Nothing helps you understand code - whether you wrote it or someone else did - better than stepping through it in a debugger. Since Giles is a sometime screenwriter, maybe this analogy is appropriate: reading the code is like reading a screenplay. Writing tests is maybe like drawing storyboards (they help you visualize the final product). Using a debugger is like actually watching the damn movie. With a jog wheel so you can slow it down.
Blaine Buxton weighs in with another view of the role of the debugger:
Debuggers are great for exploratory programming when you are just trying out a new framework and seeing how it works. I like to walk line by line. I did this when I was learning Seaside and it was better than any documentation. Besides, watching beautiful code unfold in your debugger is nothing short of reading a great book. And when you're dealing with some ugly code, a debugger has shown me things that my eyes deceived me on when just looking at the code. Why dissect the dead animal when I can see how its organs work while it is still alive?
Ben Matasar comments that the name "Debugger" might be the problem:
I think the name debugger gives people the wrong idea about what it is, at least in Smalltalk. When I first came to Smalltalk in December of last year I tried not to use the debugger, and I did think of it as a crutch. Now I use it all the time to get my bearings around a codebase. In fact, I write quite a bit of my code directly in the debugger, often with my web browser spinning in the background waiting for me to send the response.
I now think of it as a method context browser, where you have an active REPL at every step of the call stack. This is nice because you can send messages to the objects, to poke them and figure out how they're going to respond to messages.
With this in mind, the classic debugger is the tool allowing to suspend execution via breakpoints or at arbitrary times and allowing to look at current state. It can be thought of as part of a group of tools that help the developer to understand how the system actually behaves at runtime - as compared to only looking at the source code. Other tools in that category would be coverage tools (eg. rcov) profilers, tracers, or loggers.

Another aspect of the original blog post is the suggestion that Ruby debugger support is lacking. It's not quite certain  what this refers to, though. The Ruby interpreter has debugger support, both slow versions written in Ruby and faster ones such as ruby-debug. This is also true for  JRuby, where  the faster solution (jruby-debug) is currently in the works. Other Ruby implementations, such as Rubinius have low-overhead debugging or use the underlying VM's debugging support.

Of course, the debugger implementation is just one part - a user interface for the debugger must be available too. But this too, is available in the Ruby space. All major and modern Ruby IDEs support debugging. RDT (now part of Aptana) has had debugging support for many years - the recent Netbeans' debugging support is based of the same codebase as RDT . Eclipse DLTK Ruby has debugging support, as well as the other - non Java based IDEs - such as Sapphire Steel's Ruby in Steel IDE, Komodo, etc.

What are your experiences with debugging Ruby?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Debuggers considered Harmful?

    by Philip Schwarz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Uncle Bob's words In Debuggers are a wasteful Timesink

    I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, *then* you may need a debugger.

  • Re: Debuggers considered Harmful?

    by Werner Schuster,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I see the point... but still, I don't see how "a few well placed print statements" are better than a few well placed breakpoints. Even better: automate the debugger by scripting it - debuggers inside Eclipse can be scripted with JVM based languages (such as JRuby) which allows to automate setting of breakpoints, breakpoint handling, etc.

    Also: they're just absolutely indispensable as exploration tools... there's no faster way to understand how a complex or very dynamic system is implemented than setting a few breakpoints and stepping along to see what's involved. This is my experience, eg. from implementing support for programming languages in Eclipse - if I wanted to see what goes on when I hit Ctrl-1 in the Java editor, I set a few speculative breakpoints (ie. I'm guessing which classes/methods are involved), then a) see where this goes and b) know exactly what kind of objects and data are involved. With a system as extensible and modularized as Eclipse, this is the quickest way, much faster than trying to piece together the specifics from the source files.
    This is the same way that doctors use X-Rays, MRIs, or other similar tools to diagnose a patient - they still have the option of staring at the patient for a long time and trying to guess what's going on...

  • Re: Debuggers considered Harmful?

    by Cedric Beust,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Big +1 in favor of debuggers as well, regardless of the language.

    Someone who uses judiciously both println statements and debuggers will always be more productive than someone who only uses println statements.

    I wrote a rebuttal to Rob's position on debuggers here some time ago:

    beust.com/weblog/archives/000055.html

    --
    Cedric

  • Oh, this silly field

    by Thiago Silva,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think there is something really wrong when people promote blindness and guess-work over observation. This attitude is not intelligent. By (misleadingly) insisting on the exclusive use of static specification of the program to understand its behavior, they do nothing but indulge in a lower kind of smartness.

    The way I see it, if one is having visual problems to read a book, hand him glasses. If he refuses, because in his view, he will be more intelligent if he tries to guess what is written in the book, well...I don't know what he means by "intelligent".

    If anything, over reliance on a debugger is a symptom of trying to tame something overly complex for one's mind. And logs and prints are but a poor man's debugger: simple-minded tools that show only a little bit of the dynamic behavior of a system. If one wants to learn about the dynamic behavior of a system, observe it; why the fetish to be economic about what's to be watched? (also, the argument that one should compute the system on one's mind is weak: a professional must understand how computation is carried out; but if you believe you should be able to read source code and execute on your mind as precise and efficient as the computer, why are you writing programs to compute what you can compute better? Just let them hire you to do what the computer was supposed to do; systems are expensive, I'm sure there is real money to get here).

    But if reading is difficult even with glasses, what is asked for is better education, not the condemnation of the glasses (since we are at it, let's ban the use of calculators, compass, rulers, telescopes and every other tool that aids humans in understanding phenomena -- they just makes us all dumb, right?).

    Cheers,
    Thiago Silva

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT