Comment by schrototo | Hacker News Reader

Comment by schrototo | Hacker News Reader

Kris Rudin, Senior Developer and Associate Partner at digital marketing agency Ascentium says, "One 'lost skill' that I see all the time with new developers -- how to debug without an integrated debugger. When I started programming (in 1986, just after punch cards, using a mainframe & dumb terminal), we didn't have any IDEs and debuggers, we had to put trace statements in our code to track values and execution.

"Today," says Rudin, there are occasionally times with you can't use the integrated debugger in your IDE (usually with some weird web application frameworks and server configurations), and younger programmers are at a loss as to what to do, and resort to hack-and-slash coding to try to randomly fix a bug, using guesswork. Me, I just calmly put in some code to display output values on the web page, find the bug, and fix it."

Oh come on. What he's describing isn't some "lost skill". If you can't figure out to use print statements for debugging you're not much of a programmer in the first place.

Most statements in that article describe really basic, common sense stuff.

I work a lot in PHP, so it's kind of funny that I find that new developers in PHP are exactly the opposite: most of them don't know how to use IDE debuggers with PHP. Instead they have print statements all through their code and they end up veering away from any form of OO or 'complex' code, as it becomes hard to 'debug' this code when there's a problem.

Don't get me wrong: 'debugging by echo' is useful at times, but I would say that 9 times out of 10, a proper debugger is more valuable. In my case. YMMV. etc.

It depends on the environment and personal preference. If I remember correctly, Linus Torvalds never works with a debugger either. A few years ago, when I was still doing desktop software, I used the Delphi and MSVC debuggers regularly. Now I do mostly web-based stuff and I find that unit tests and logging have largely made a debugger obsolete for me.

I find analyzing trace statements to be far faster than setting conditional break points and stepping through a debugger.

I can quickly run a test, grep/skim through the trace output and ignore/drill down into detailed minutia that are irrelevant/relevant to the problem being investigated.

I also tend to write my trace statements in an easily parsible format so if I need to I can write another program to analyze what happened and find the problem. Writing a full on program to process log files happens less often than chaining several unix commands to find the needle in the haystack (usually the program happens when I need to thread together several widely separated trace lines).

This is situational in the extreme, especially when you're interested in specific conditions in tight loops. For example, if you're debugging a race condition in a render loop, it's probably not going to be easy to reproduce when you also start trying to write out megabytes of data at the same time.

The only way to debug real race conditions is to engineer your code from the beginning to avoid them. Debuggers and prints are equally powerless to help you.

Debuggers can help identify race conditions by giving you insight into the state of the process at the time of the break. The reason they're superior to printf's in this regard is that debuggers can signal breaks on conditions without requiring a recompile. In general, debuggers are superior because of this. Good debuggers aso let you ask questions on the fly inside a stack frame, something printf-stuff can never do.

Of course, I didn't say nor mean to say that ALL race conditions are identifiable in this way, only that it can make the results more visible for some of the more obvious cases.

Well, yeah, that's what useful stack traces are for - but stack traces aren't useful in the least when you click on a button and it's supposed to do x but it's doing y; how do you figure out why it isn't doing something it's supposed to be doing without either putting a bunch of log.debug() calls in the code or breakpoints?

With Python, when stack traces happen now, WebError will even give you an in-browser prompt to explore the state of that Python session; so log.debug() calls are only used when the software is working but not working as intended - that is a case where debugging tools can actually come in handy because I hate cleaning up log.debug() calls littered everywhere.

It really depends on the program architecture and what issue you're debugging.

For most single-threaded or simple multithreaded programs, it's easier just to throw a print statement where you need it and analyze that. Even with a large data set, a simple grep will probably get you what you need.

When you're debugging a complex, multithreaded program, on the other hand, an external debugger is much more valuable, because you can break at the exact point where things go wrong, and examine the entire program's behavior at that point. Debugging a race condition with prints can be pretty difficult, especially when the printing changes the timings of the threads.

I've debugged my fair shared of parallel programs (multithreaded and distributed), and I've used a mix of both techniques. The advantage to print statements is that it gives you an execution trace. It's easier for me to reconstruct the sequence of events - which is not trivial in a parallel program. What I give up is full knowledge of any one instant. And that's what a debugger gives me.

It's a trade-off, but I usually start with traces.

I've been debugging plenty of distributed/parallel processing systems by trace statements. It's not trivially easy, but its not too bad (its actually kind of fun).

In fact, I'm not exactly sure how you would debug a multi-process parallel system with an external debugger. Would you simultaneously use multiple debugger instances to attach to each process? That sounds like fun.

For a true, parallel system it's virtually impossible to "examine the entire program's behavior" at any one instance in time. Sure printing changes the timing of things, but unless you are single threaded, you are kidding yourself to think that a debugger also doesn't disrupt timings.

This is a lot because the PHP Debuggers are very time consuming to set up and a lot of people prefer to code in Notepad++, rather than a complex IDE.

I think that it's useful to distinguish between code that one has an intimate knowledge of / intuitive sense of and code where one does not fully understand.

For example, I find printf-like debugging and using stack traces from Valgrind to be very useful for debugging my own code; however, at work, when I have no idea where the problem is, something like gdb or the debugger of Visual Studio really comes in handy.

In the proprietary, NIH world of embedded software, vendor often ship development tools whose quality ranges from flaky to totally broken. With tight deadlines to ship devices that will be obsolete within months, investing time and people to support robust dev tools across multiple platforms is deemed a low priority. printf() debugging is often the only reliable (and portable) option. :(

Sadly, the open world is not immune to this. I've seen Eclipse's remote Java debugger intermittently fall over with bizarre JPDA errors, and spewing to log4j was also my quickest workaround. I'm not invested enough in the success of Eclipse, or Java for that matter, to contribute fixes.

Reply on news.ycombinator.com