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 cleverThe real problem is that the majority of software that is written is fairly lousy. People often code to moving requirements, push code in directions it was never intended to go in, and work with designs that are in desperate need of landing on the compost heap.
Honest debugging is most useful when something is being developed in the first place. Domain knowledge is what is most useful when ancient and decrepit software is being modified to do something it shouldn't.
Software applications should be thought of as prarie lands. From time to time, lightning strikes, and burns out a huge chunk, which is all replaced by newer and healthier stuff. You need talented people to make sure the new code will work well with what's already there - but the end result is that the application will be healthier if frequent refactoring is done intelligently.
Education is the silver bullet.
Debugging is difficult primarily because debuggers do not appear to use any kind of intuition.
Let's say I have a break point on an if statement. The debugger should automatically show me the values of any variables in the condition, as well as the truth values of the individual expressions in that condition.
A debugger should have an "intelligent" step button that steps into code that has debugging symbols, but steps over system calls. It should also automatically skip to the end of loops if desired.
Debuggers should have "sanity" checks for values. Any time a pointer is null, or an long integer is set to some really wild value (like -3492883773642) that is nowhere close to the values that it originally contained, or a string doesn't have a null terminator, the debugger should alert you with a little icon, even if you aren't actively watching that variable.
One thing that sucks about debugging is when programs behave differently in the debugging environment than they do once compiled. We had several problems related to event handling in Visual Basic only occured if the program had been compiled. In debug mode, it worked fine.
Debuggers should keep a "state" history, especially for loops or recursive functions, so you can see the entire progression of a set of variables until the point of failure. This eliminates having to write in a bunch of printf statements to get a snapshot of each loop iteration or function call.
The debugger should be integrated into the IDE so you don't have to switch back and forth. Also, it would be really nice if debuggers executed under some kind of virtual machine that allowed you to more easily freeze execution, rewind it, tinker with it as it's running, etc. Visual Basic allows you to do some of this, but certain code changes require you to restart the whole program. I'd like it if you never had to restart, and the line between "debug mode" and "design mode" were almost entirely blurred.
Just my $0.02.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
Sure, 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
Since my favorite language is VB
Personally, I think of VB as a scripting interface for Windows GUI work rather than an actual programming language, but that is also its strength. There is no perfect programming language - they all have their pros and cons, and while VB is slow compared to C++ for calculations, VB is extremely handy for operating a GUI - an area where C++ is tricker.
One shouldn't try to drive a screw with a hammer just because the hammer is more 'elite' - use the right tool for the job.
That's one I've actually wanted before. I'd like to see something where you could specify a list of "Watch" variables, and snapshot points. then let the program run. It takes snaps of all variables at each point. you can then go back and review what happened. Get a nice grid of variable values by point in time.
It's a lot faster then setting watches and breakpoints and having to write or remember what happened at each point.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
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
Doesn't work very well with recursive functions. Especially recursive functions that call other recursive functions. Ever tried to write a recursive descent parser? Next to impossible without a good debugger. You need to be able to step through the code line by line and watch variables as they are loaded on to(and popped off) the stack. No way are print statements going to be nearly as helpful.
No, Thursday's out. How about never - is never good for you?
Testing is to identify if there is a problem, and hopefully under what conditions they will occur. Debugging is to identify the cause of that problem, and what needs to be done to fix it. One is most definatly not a replacement for the other.
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.
"Interpreted" is not the same as "dynamic". You can have both speed and a productive environment.
Programming can be fun again. Film at 11.
Wow, you really hate VB. Before I answer your post, let me say that I hate VB's syntax, the fact that it's not truly object oriented, and the weird, back-asswards way it does things. So I'm not totally against you on this. I'd rather be working in C++ or even C, so take the following in context, ok?
VB *CAN* be used for relatively larger projects, BUT, it depends on what kind of programmer is involved. I've inherited some semi-large VB projects, including a three-tier client-server setup built from VB programs, MTS dlls, ASP pages, and a pretty big database, with a lot of lines of code (not just a page). Luckily for me, the original programmer had an engineering background, so his code was pretty tight and the project was in pretty good shape. I made beaucoup changes to it, updating it to account for a number of policy changes. I had to totally redesign chunks of it because of changes in the way a number of pieces of data were going to be handled in the future, etc, and of course I had a great deal of bug-hunting to do. But, overall, despite the fact that this was a big, complex project, it all went pretty well. We're now moving into a phase where the system's going to be expanded again, to add features. It's growing, in other words -- bigger and bigger. And, it's not giving us that much trouble in the process.
I think where large projects run into trouble with VB is when they are run by people who do NOT have a solid computer science background. All too often, a secretary or clerk is sent off to a VB class, baptized as a programmer, and handed a copy of VB, Professional Edition. Then this clueless person is expected to be able to handle a large project. No knowledge of data or file structures, no knowledge of relational database design or algorithms, but they're given the tools and admin access to a test database, plus a big project. Naturally, the person A) shits his pants and runs to Border's to buy a VB picture-cook-book with lots of yummy recipes in it, B) makes a good faith effort and totally fucks it up, and C) doesn't know what the hell hit him when the project implodes the day before the deadline (or am I being too harsh here?).
But don't blame VB for it; blame the manager who's too stupid to know that computer programming is an engineering task requiring more than a six-week VB course to learn how to do properly. I feel sorry for the poor noob who gets flattered into thinking he's a programmer; he's the one that takes it in the shorts, generally.
Sorry for the elitist rant, but...
Farewell! It's been a fine buncha years!
I've been writing vc++ for a few years now, but one feature I'd REALLY like to see would be to be able to easily set conditional breakpoints on a particular instance of an object. In fact, more object awareness across the board would be nice. I'd also like to be able to be somewhere in a windows message handler, and be able to see where the message had come from. I'd like to be able to call functions from the watch window like I could in DEC FORTRAN. I'd like to see the VC++ debugger be able to enumerate over collection objects using for_each, and examine COM properties as if they were variables. I want the VB watch and immediate windows for VC++.
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine