How Would You Improve Today's Debugging Tools?
redelvis asks: "I recently came across an article by MIT's Media Lab on 'The Debugging Scandal and What to Do About It'. It's a few years old now, but it really got me thinking about how little the debugging process has improved over the last 5,10 or even 30 years. I have developed applications using modern IDE debuggers such as Borland's JBuilder, Microsoft's Visual C++, as well as standard tools like gdb and jdb. Despite the slick graphical interfaces, nice thread stack traces and local variable browsers, I still make sure I have on hand plenty of notepads, graph paper, pens and pencils so I can try to build up a picture of what state the program is in and to help me play detective in pinpointing what is going wrong with my (or other peoples) programs. Do other developers have similar problems? Do they find modern IDEs and debuggers have shortcomings in helping track down bugs? What would make a better debugger? Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?"
Why do you think so much effort been invested in areas such as advanced modelling tools but so little in improving debugging tools?
Easy. As anyone who's ever tried to use software knows, nobody uses debugging tools anyway.
-JDF
Dont debug.
Eventually someone else will find the bugs and fix them for you at their own expense.
This is how the Open Source programming model works.
I don't need no instructions to know how to rock!!!!
No dancing girls!
Add one or two beautiful dancing girls to every debugger, and they'll sell like hotcakes.
... about Debugging Tools. He felt that engineers should just learn to write software without bugs in it.
I wouldn't let the retards at microsoft work on any more code for the IDE. Then at least it wouln't get any worse.
Clippy!
If you mod me down the terrorists will have won
"The attitude is easy to explain: VB sucks ass."
Whoah, I'm glad you showed up! My opinion of VB has completely changed now that you've tuned me in to that little fact. I didn't fully realize the scope of the problem until I realized that my ass would be sucked!
I just need the "why" command..
=)
"...Program control. More cooperation with the code itself. I'd like the debugger to provide a library against which I can link my code so that the code being debugged can control things like which variables are being watched and which breakpoints are active. I could then easily have breakpoints that are enabled only under certain conditions...."
You know, that's actually a great idea -- and if you think of the logical continuation of it, it would only be a matter of time before you needed a debugger for your debugging code. How cool would that be!
-Fatty
If you don't have another programmer handy, try the practice of Rubber Ducking.
This is where when you are completely stuck, you take a little break. Then you come back, pull a rubber duck out of your drawer, and put it on your desk. Then you turn to it and say, "Rubber duck, here's my problem," and explain your troubles to it, just as you would to a fellow programmer.
About two thirds of the time I try this, I stop half way through and say, "Aha! That's the problem!" And even if the solution doesn't occur to me, the process of explaining the problem makes me go over it in an orderly way, so that I always think of new places to look.
It runs during installation. To activate it, click 'I do not agree' when some incomprehensible gobbledegook called a 'EULA' is shown. A EULA is a kind of bug. Unless you refuse to accept, it will bug you again and again. Don't confuse bugs with viruses, however: Microsoft's debugger can't handle viral licenses, which is why they don't like the GPL. Once activated, the powerful EULA non-acceptance debugging option leaves your system bug-free.
- undoware.ca