Hacker News Reader

Comment by marssaxman | Hacker News Reader

Sometimes the print statement is the best tool for the job; sometimes it is the only tool for the job. If you know how to debug by adding print statements, running a test, and reading the resulting log, you can solve any problem, in any environment, on any platform[1]. Other tools may well provide faster results in specific situations, but one has to balance the time spent learning & managing fancier tools versus the time spent getting the job done.

1) Well, okay, there are exceptions. Perhaps you have to find a spare IO pin attached to an LED, and make it blink at you in morse code, because your serial port hasn't come up yet, so you can't print to the console; but it's the same idea.

View on HN

I haven't coded for a while, but here's a weird situation where print() worked better in some cases for me -- you know how people say "I have better learning retention when I take notes by hand"? I found that sometimes the act of writing the print() statement helped to focus my mind and think about what I was trying to debug. For example, what specific aspects of the data structure do I need to see and why? How do I want to frame the relationship between two or more variables? Stuff like that would sometimes lead to the discovery of the bug before I even completed the print() line.

Seeing the state is faster with a debugger is probably faster, but the process is an analog to explaining the situation to a rubber duck.

Unless you write in some crazy, rapidly changing env.

Then you learn debugger like once? twice? thrice? And still they are not this complex

>but one has to balance the time spent learning & managing fancier tools versus the time spent getting the job done.

There is funny saying which goes like this

You can save 2h of reading debugger docs with 12 years of using prints

Maybe I'm weird, but when I'm debugging, the problem could be in my code, library code, runtime code, or kernel code. Usually the first two can use the runtime debugger, but the runtime code needs a different debugger (usually gbd/lldb), and the kernel needs a third debugger (if you even get one). And sometimes I care about the frontend, so there'a a web debugger and maybe a windows debugger for the browser. Thankfully, I've never needed to debug the windows kernel, that would be a whole nother level. Sometimes I'm working on projects with multiple languages, so then I need to debug in Erlang, Perl, PHP, Javascript, hopefully not much Python, userland C, kernel level C. My degree from the printf school of debugging works on all of those. But still, sometimes, printf isn't enough, and you've got to spend the half day figuring out how to get the debugger to work in your current environment, and then the situation often just pops right out (but sometimes it doesn't and you're still just wondering... but now in a much more powerful and dangerous tool).

Personally, tcpdump is my favorite debug hammer, but printf is second. FreeBSD's kernel debugger is pretty neat (especially over an IPMI serial console), but fills me with dread when I need it.

Sometimes even poking a spare IO pin is insufficient! I once encountered a hardware issue where a single instruction was being executed twice and this was only revealed by routing the least significant bits of the program counter onto IOs. Only after counting the number of cycles that the offending instruction took revealed the issue.

>Perhaps you have to find a spare IO pin attached to an LED

Maybe just a spare IO pin and an oscilloscope.

>Perhaps you have to find a spare IO pin attached to an LED

I made a write-only UART on an ST7. Clocking worked out to 500kbit because that was the first configuration I found where I could make the mark and space bits take an equals number of cycles. I still remember thinking: why in the world is the timing for each of these instructions so different?

I would be glad even having printf when debugging glsl shaders.

I found that using the final pixel color as your “printf” works wonders. You can turn any proposition into a color and directly see the debug pixel values on screen. A simple example is displaying your normals as RGB.

Reply on news.ycombinator.com