Slashdot Mirror
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?"
One of my biggest problems with people on my current project is the lack of knowledge of how to use even the most basic tools. We program in C++ on Unix and many developers find calling up dbx to be a chore and, even when they get dbx up, have trouble using it. We have many other tools, ddd, other graphical debuggers but people just don't use them, relying on printfs and couts...
main(i){(10-putchar(((25208>>3*(i+=3))&7)+(i ?i-4?100:65:10)))?main(i-4):i;}
I'm a total amateur, but I personally find that software tools can ultimately only go so far in debugging. The two most important debugging tools I'm aware of can't be solved with software: a short break from the project to clear your train of thought, and another set of eyes which might better see what you've overlooked.
----------
Something cleverSure, we all like debuggers with conditional breakpoints and backward stepping, but the more you add to the debugger the less opportunity you will of finding the bug (unless its a 'smack in the face' bug).
The only way of truely solving bugs is to know exactly whats going on in the code (and, also as important, is knowing the language, operating system, and the things going on in the background. IE - in Java, although it appears as if you aren't dealing with pointers, you are, and you should treat all objects like a reference, cause that's what they are). If you can't study the code (cause it was written poorly), it is a terrible terrible thing, because most bugs are not just one line fixes (and even those that are require you to know exactly what all is going on around them).
"Cherry picking" (just tuning up one line and "guessing" that that's the problem) is what most 'amateurs that taught themselves coding' do, and on major/enourmously large projects, this will do nothing more than cause trouble.
The best way to beat a bug is knowledge.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
"Since my favorite language is VB ( watch the flames poor in on that statement )..."
I don't really understand Slashdot's attitude about VB. I don't consider myself a programmer, but I've been able to use it to automate some stuff in Windows. I think it's great, especially when it comes to creating GUIs.
Every language has its strengths. Making of of VB because it doesn't do something another language does is like making fun of cars because they can't fly. Nobody's going to use a 747 to take a trip to 7-11.
the best way to build a skyscraper is not to use CAD programs at all, but a slide rule and pen'n'paper, which force you to think about what you're doing instead of making mistakes and 'correcting them later'.
;)
come on! You can't tell me that to be a Real Programmer one has to forgo color syntax highlighting, automatic indentation, automatic code formatting, automatic brace insertion, etags, man-on-symbol-at-point, folding, autodoc of functions, gcc -Wall -Weverything-but-the-kitchen-sink etc. etc. etc.
Personally I believe that being able to isolate myself to having to indent manually the next line and similar stuff makes me a better programmer, as I'm able to think about structure & what I want the function to be doing vs why the %##*%^ editor doesn't do what I want.
I'd also like to see you 'not put the bugs in in the first place' if you're adding a complex piece of functionality to a 2,000,000 lines program: I can write perfect 'hello world' code on a napkin, but considering doing it for real work is ludicrous.
Debugging is also an art, and I don't think I've ever found a bug I wasn't able to trace via judicious use of the tools currently available on the market right now, which are (from less to most esoteric):
- compile with as many warnings on as you can
- reading the docs/code comments (some bugs are really features
- the mighty printf/cout/cerr
- find/grep
- vanilla breakpoints in your debugger of choice
- tcpdump/openssl s_client/telnet/other packet monitoring stuff
- purify/ad-hoc malloc library
- hardware watchpoints in gdb (saved me a few times)
- sleeping on it/going for a walk (let your subconscious do its thing)
Only thing I'd like that current debuggers on unix don't have is what you can do in windows by inserting a certain line in your code that when is reached it automagically halts and pops up the debugger: when debugging multithreaded/multiprocess stuff that has bugs only when not running singleprocess/singlethread it's invaluable: anybody knows how to do that in unix?
-- the cake is a lie
Ah, but here's the problem. People fail to understand the purpose of VB far too often.
/images/yyyy/mm/dd/hh_mm_ss.jpg then it's a wonderful thing. Add a webcam component, then another for jpg (VB can only save BMP), and in a few minutes it will be done.
VB is great for writing small apps. If say, you want to write a program that takes photos at an interval and automatically saves them in
Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.
Also, pretty much anything that can be done with VB can be done in Linux with Perl and PerlQt, perhaps with some help from other apps. Pretty much the only thing I couldn't find a replacement for is such a great debugger.
"Much of the server-side world doesn't use traditional debugging tools at all- they use small, well defined functions/methods, which are easy to unit test."
Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?
Even when using some fully tested COTS library to solve all of your problems the programmer WILL run into integration issues due to unintended use or misunderstanding.
"I've seen as developers gain experience, they rely less and less on interactive debuggers, and more on automated testing and configurable logging."
I have been coding for over two decades and have yet to see a reason to abandon debugger use. It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon. Black box and even white box testing will only tell you so much. Sometimes you need to see the cogs in motion.
come on fhqwhgads
Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.
.NET languages seem to be minor syntax variations on Java, maybe that's not too surprising.)
Amen. If people knew that whenever they needed write a program longer than a page that they should switch away from VB, I'd have no complaints with it. Instead, it is marketed in such a way that it gives amateurs the notion that they're just as good as any professional programmer. It's as if people thought that buying a Tinkertoy kit made them able to build houses.
I don't know how many projects I've seen where someone has knocked together a prototype in some half-baked language like VB. Then people want another feature and another, and nobody is willing to say: "Stop! We must throw this crap out and start again using appropriate tools."
(For the record, I hear that VB.NET is a big improvement over the execrable VB6. Of course, given that all
Agreed. Since changing from C to Java several years ago I find that I never use debuggers anymore, relying instead on verbose logging to understand what my program is doing. I think in C debuggers help more because you can abuse memory in various ways that you don't need to worry about so much in Java. With a debugger it is really easy to see yourself walk off the end of an array, for example. I also observe that my peers who rely strictly on debuggers don't tend to do much logging. So when their software is in production they are mystified when it acts up. I also notice that they don't comment as verbosely either but I can't prove that's because they use a debugger. Maybe they wouldn't comment anyway.