I'm looking back at the debugger kerfuffle that broke out a couple of days ago - Giles "disagree with me and no comment for you" Bowkett dug the hole deeper in his updates:
- Debuggers encourage a backwards workflow
- Debuggers are a historical artifact of C pointer mechanics and primitive flow control
If he's ever seen a debugger and actually understood what he was looking at, he wouldn't have such ideas. Let's go back to C for a moment, since he brings it up. I spent my time in the C dungeons years ago, and I used both "printf debugging" and a decent symbolic debugger. When you have a pointer error, not using a debugger is just an invitation to waste time. You can argue that the error should not have happened at all - and sure, having a good test suite will prevent a lot of problems. Bottom line though, you end up with pojnter bugs - even if your code is perfect, the code you integrate with is something else again. Maybe Giles enjoys pounding his head against the keyboard; I don't.
Let's move on from C though, to better languages like Smalltalk and Ruby. I did a screencast of the Smalltalk debugger in action, doing TDD. Never mind the TDD part for a moment - just consider what I was doing: I was writing code in the debugger, with all the application context and state available to me. Ask yourself: when you are crafting new code for something, is having that information helpful? Yes, you should have tests, but that doesn't matter - having the tests and the context is highly useful.
The way Troy put things in the comments echos something I've said for years: with most debuggers (and I suspect that this is all Giles has had experience with), you're a forensic pathologist. The patient is dead; the best you can do is figure out what killed him, and prevent the next version of the app from dying of the same thing. With Smalltalk, you're a surgeon: the patient is sedated, and you have him on the table. You can not only figure out what made him sick - you can fix it and let him walk off under his own power.
That's a huge thing, and it's one of the keys to Smalltalk's productivity. The "fix and continue" support in Eclipse and VisualStudio are pale imitations - your ability to fix things is highly constrained. In Smalltalk, you can do whatever you want: add new instance variables to classes (which will modify all extant instances), add new code, modify existing code, anything. You can do as complex an operation on the patient as you can imagine. Oh - and when you get an exception while debugging, you get another debugger - as opposed to being tossed out of the debugger.
Even that doesn't get at everything though. There's an internal discussion going on here at Cincom, as to whether the term "Debugger" really captures the entire idea for us. This is actually a good question, because the tool is far more than a debugger. It allows you to look at all system state at any time. One of the things I did when I was first learning Smalltalk was to hit ctrl-c (ctrl-y now) and just walk through the UI code: it allowed me to look, in real time, at how the system operated. I do this with code I don't really understand now, too. When I look at Seaside, I often drop into the debugger to look around - because it's easier to look at the real state of the system than it is to try and imagine it all in my head.
And that's the problem with Giles' "Debuggers are harmful" thesis: he somehow expects developers to keep all state in their head at all times. You know what? One of the promises of computers is that they allow us to offload a lot of the drudgery to the system - because it doesn't mind handling it, and it's pretty good at it. It's no longer 1975 - we don't have to stack up the punch cards, run the mental tests over and over so as to prevent a botched (and expensive) run: we can ask the system to explain itself.
Technorati Tags:
development, debugger, debugging, tdd
Previous Topic
