Hacker News Reader

Comment by supermatt | Hacker News Reader

No doubt there is a place (or indeed a need) for debug (or trace) logging in environments where you can’t simply pause execution.

However, in development environments you would be foolish not to use the (vastly superior) tooling available.

I think many developers shy away from debuggers simply because they haven't taken the time to understand how to use them effectively, whereas everyone knows how to write a log statement. In previous roles I have given guidance on usage to fellow team members. It makes a vast difference on the resolution time of reported issues.

View on HN

> However, in development environments you would be foolish not to use the (vastly superior) tooling available.

The debugger being vastly superior is highly dependant on what environment you are running in.

I have had cases where it takes ~2 hours to hit a bug case. You cannot afford that time waiting for the debugger. You must achieve that with logging. You might be able to figure out, with that logging, how to hit the bug faster and then you can use the debugger to step through, but I have found the use of a debugger to be beneficial in fewer than 20% of bugs I am trying to solve.

That sounds like exactly the sort of situation where you really want to use a debugger! I'd rather wait 3 hours to hit the bug and have full access to everything than wait 2 hours and realise that I didn't log an important variable and have to start again.

Debugger usage has been non-monotonic with time for me. When I first started coding I would print. Then I discovered debuggers and experienced a massive improvement in productivity on bug fixing and problem solving tasks. But over time I found myself reaching for the debugger less and less often as I became better at solving problems. In the last 5 years I have to admit I've barely used debuggers at all.

There are two situations that I encounter that make step through debugging difficult or impossible, and for a lot of my work both apply.

A) When developing for a microcontroller (however large or small). Stepping debuggers are limited, and sometimes unavailable at all. Most are clunky. ARM is the best here.

B) Running real time things. E.g. you can't step through a Bluetooth comms process because the moment you hit a breakpoint you aren't servicing a link and everything falls over.

There are some good tools like reverse time debuggers (e.g. https://undo.io/) that deal with the real time thing, but nothing deals with the combination. Plus a well maintained set of log outputs often tells you exactly what went wrong with just a cursory glance through the logs.

I will add

C) debugging signal handlers is somewhere between tricky and impossible depending on the scenario because of how debuggers work.

D) debugging optimized code. -O2 or -O3 code will have everything executing out of order, all variables are optimizes out, everything is inlined, etc.

Oh yeah, most definitely - tooling isn't just debuggers, after all. I often use network traffic monitors, packet analysers, etc. No doubt in the microcontroller and EE world theres specific tooling too. That includes the humble logger :)

I've used lots of debuggers and debugging tools, have a thorough understanding of their capabilities and have written and extended such tools myself. Print statement debugging will always be a tool in my arsenal. Sometimes - surprisingly often - it's just the fastest way to figure something out.

Hm. If its a timing issue, regular debuggers affect that and will perturb the experiment.

Fast, lightweight logging can be a necessary tool.

I can think of a single case where the debugger changed timing enough to make a problem I was working on not show up. I can think of dozens of times when logging did, though. I guess it’s dependent on the type of problems you work on.

Lots of ways to do logging. Create a circular buffer of tags and values at critical points - takes just a couple machine cycles to add an entry. When the problem occurs (break in the debugger) the table records the last N significant actions.

Debuggers are great (even when I have to resort to running GDB over SSH with no GUI help) but sometimes you have to debug compiler-optimized code, or asynchronous or long-term problems, and then logging can be a quick and effective alternative.

Sometimes you have to debug distributed solutions, and like you say you may have to do it in an optimized environment. You may also have to do it in an environment for which you have no other access than console output. I've been working in these kinds of environments for so long I've practically forgotten how to use a debugger!

I know your list is not intended to be exhaustive, but it's missing my main reason for using print: because the debugger can be really slow (at least in Python).

For some operations, running them in debug mode means they are 10 times slower, turning a 30sec operation (such as parsing big files into memory) into 5 minutes. If I'm relatively certain of what the problem is and I solve it in less than ~5 tries, I saved time.

Python, AFAIK, doesnt have a 'debug' mode, so its likely the IDE that is slowing down your debugging experience. Im not sure how you work around that - some IDEs do a lot of superfluous stuff when 'debugging', and may have settings to toggle features.

You can also just import the debugger where you need to use it, in which case you shouldn't get any slowdown.

> in development environments you would be foolish not to use the (vastly superior) tooling available.

I don't know. Learning and using a debugger adds an additional layer of cognitive load. Instead of thinking about the bug, you're thinking about using the debugger and trying to think about the bug. I have found their value to be limited with the code I normally write.

Sometimes an interactive debugger gets you lost in the trees so you can't see the forest. Not always the best option.

Sometimes threading issues are hard to debug, because attaching the debugger will impact the code behavior. Logging is a tool in the toolbox, I wouldn't dismiss it

If you can show me a debugger that will work on a PHP application in the Symfony framework, runs on Mac, and is not built on Eclipse or a similar lumbering monstrosity, I will gladly give it a try. (Hell, I tried PHPStorm, but it's just so painful to use...)

Until and unless such a thing appears, debug logging is pretty much what I've got.

(And given the complexity of the project in question, and the fact that I'm basically its only developer, debug logging is still pretty vital for running down the bugs the users run into in production. Good thing it's just a free hobby project!)

I dont personally use PHP so I cant really vouch for it, but I just asked a friend and he uses Xdebug in vscode (on an M1 mac).

Hm. I'll give that a try and see if it's worthwhile. Thanks.

Was that a conscious invocation of Cunningham's law? :)

IMO the "vastly superior" comment here hurts the credo of your argument.

Reply on news.ycombinator.com