Comment by lolinder | Hacker News Reader

Comment by lolinder | Hacker News Reader

Parent Full thread

I find that which tools I need changes immensely depending on what kinds of projects I'm working on.

When debugging parsers for my toy programming languages print debugging is less helpful and I make heavy use of all the debug tools you mention. The same goes for most types of business logic—writing a test and stepping through it in the debugger is usually the way to go.

But when troubleshooting odd behavior in a complex web app, the inverse is true—there are usually many possible points where the failure could occur, and many layers of function calls and API calls to check, which means that sticking a debug statement prematurely slows down your troubleshooting a lot. It's better to sprinkle logs everywhere, trigger the unexpected behavior, and then skim the logs to see where things stop making sense.

In general I think there are two conditions that make the difference between the debugger or print being better:

* Do you already know which unit is failing?

* Is there concurrency involved?

If you don't yet know the failing unit and/or the failing part of the code is concurrent, the debugger will not help you as much as logs will. You could use logs to narrow down the surface area until you know where the failure is and you've eliminated concurrency, but you shouldn't jump straight to the debugger.

I think we need to differentiate between printf style debugging and considered, comprehensive logging. Ideally logging with logging levels. While the latter might seem to fall under the same umbrella -- both are printing some sort of text artifact history of execution -- the latter is long-term and engineered, and the former is generally reactionary.

e.g. LOG(INFO_LEVEL, "Service startup") and printf("Here11") are completely different situations.

Indeed, the very submission is arguing for printf style debugging instead of logging. Like it uses it as the alternative.

Real-world projects should have logging. It should have configurable logging levels such that a failing project in the wild can be configured to a higher logging level and you can gather up a myriad of logs from a massive, heterogenous cross-runtimes and platforms project and trace through to figure out where things went awry. But that isn't print debugging or the subject of this discussion.

> Indeed, the very submission is arguing for printf style debugging instead of logging. Like it uses it as the alternative.

Yeah, this is a bogus distinction they're drawing. Logging and printf style debugging are the same thing at different phases of the software lifecycle, which means they can't be alternatives to each other because they can't exist in the same space at the same time.

As soon as your printfs are deployed to prod, they become (bad) logs, and conversely your "printf debugging" may very well actually use your log library, not printf itself.

This. Last week at work I've been investigating an odd flaky behavior. No way to do it with debugger. Add logging to every suspicious place and run all 40 containers of our distributed monolith in local docker. Turned out there is a race condition between consumption of Kafka messages and REST calls.

Have you ever been able to try https://replay.io time travel debugging as an alternative to conventional logging?

Last time I tried it you were able to add logging statements "after the fact" (i.e. after reproducing the bug) and see what they would have printed. I believe they also have the ability to act like a conventional debugger.

I think they're changing some aspects of their business model but the core record / replay tech is really cool.

If your parsers are pure¹, REPR testing and state-transition logging (trying X, X rejected, trying Y, Y is successful with input "abc") will beat any other tool by such a margin that it will feel they aren't even on the same competition.

1 - If your parsers are not pure, you either have a very weird application or should change that.

Reply on news.ycombinator.com