3 ms·
I think we need to differentiate between printf style debugging and considered, comprehensive logging. Ideally logging with logging levels. While the latter mig
by llm_nerd 2y ago
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.
- lolinder 2y ago> 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.