Item — HN Reader

The Practice of Programming (Kernighan and Pike 1999):

"As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places..."

It's a view that I came around to.

3 comments

It's a view with which I am familiar. In general, I agree that a programmer must reason about code execution, and that a debugger does not replace this process. However: with all due respect, a symbolic debugger is invaluable while trying to figure why inherited, legacy, spaghetti-ridden code which relies on pearls like parallel arrays in multiple different data structures being in sync crashes at 3 o'clock in the morning.

When I used to hang out in the workstation room at grad school, around midnight, I'd see guys feverishly trying to complete their beginning programming assignments. Invariably, some poor schmo was stuck trying to figure out where they went wrong with a doubly linked list implementation in C. They'd sit transfixed, staring at their code concocting all sorts of wild theories. I'd go up to them and tell them they should really try GDB. They'd always declare that they didn't have the time to learn it. Then at about 3:00 in the morning, they'd be desperate enough to try it. Most of the time, we'd find their bug within a few minutes.

Both debuggers and printf()s have their place. I use both heavily with debugging; DDD's data graph view (http://www.icewalkers.com/scr/n1350/ddd.jpg) is especially invaluable when debugging data structures in C.

Agreed. Stepping through your code in a debugger is SLOW and tedious. Make a change, run the code path again, make a change, run the code path again... boring.

It is much easier to print data in the area you suspect is wrong, then write a small script to get the program to call that code. You make a change and get nearly-instant feedback.

Stepping through in Smalltalk debuggers is (usually) easy and delightful. I had one student in a Smalltalk class (he was a quant, heavy math dude) declare the VisualWorks Smalltalk debugger came from God!

The debugger is so responsive, I routinely have 2 or 3 debugging sessions open, and write code in one of them. I'll write some exploratory code, evaluate it in the current stack context, examine the results, then dismiss it after copying the code back into the original debugger context and modifying it into an actual method. Sometimes, people will put a snippet of code in a comment and say, "debug this!" which is often informative and as easy to do as following a hyperlink. There's never a wait for a compile. It's not perfect -- you can get into trouble trying to debug parts of the system used by the debugger itself -- but for typical application programming, it's a joy! Oh, and with Smalltalk Server Pages, you can debug and step through in a completely natural way the rendering of a web page! (Yes, you'll see that HTML element there, then where you step into the message send for the dynamic HTML generation.)