Live data from Hacker News

Printf debugging is ok

polymonster.co.uk

11–20 of 152 posts

Re: Printf debugging is ok

#11
post #3

Whatever works so I can fix it and be home on time. I will even print (in paper) the code and step through it with a pen. Again, whatever works. Also, will we ever move forward from these sort of discussions? Back when I was a mechanic no one argued about basics troubleshooting strategies. We just aimed to learn them and apply them all (as necessary).

Based on the "lucky 10k" and the size of the internet, likely not. I'm sure if you find a mechanics enthusiast forum you will in fact find these relatively trivial arguments. It's just the nature of the beast.

Re: Printf debugging is ok

#12
A trace log of single-character print statements or equivalent is sometimes the simplest and most effective way to debug flow. This is particularly true for recursive functions, where anything more becomes too much, too fast.

Re: Printf debugging is ok

#13
post #8

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime without accidentally committing prints to the repo. There are specific types of projects that are very hard to debug (I'm working on one right now), that's a valid exception but it also indicates something that should be fixed in our stack. Print debugging is a ha…

What is the difference between print debugging and logging? With most deployments setups now days you can pipe prints to some logging solution anyways.

Print is ephemeral by design.

Logging lets you refine the level of printing and is designed to make sense in the long term. There are many technical differences (structured logging, MDC etc.) that I won't get into but they are important.

To me it's mostly about the way you write the logs vs. the way you write a print. A log tries to solve the generic problem so you can deal with it in production if the need arises by dynamically enabling logs. It solves the core issue of a potential problem. A print is a local bandaid. E.g. when print debugging one would write stuff like "f*ck 1 this was reached"... In logs you would write something sensible like "Subsystem X initialized with the following arguments %s". That's a very different concept.

Re: Printf debugging is ok

#14

all the rest of the stuff is okay but seriously? 2 finger typing? as a programmer? you're gonna be there for AAAGES and your keyboard probably runs a sidebusiness with how long it takes you to type I know I'm stirring up shit here but there really are benefits to touch typing (I mean just think about it, using 10 fingers instead of 2 is gonna be so much faster assuming you have 10 dingers)

> dingers

I'd suggest practicing your touch typing a bit more.

Re: Printf debugging is ok

#15
post #8

Earlier quoted context omitted.

What is the difference between print debugging and logging? With most deployments setups now days you can pipe prints to some logging solution anyways.

Print is ephemeral by design. Logging lets you refine the level of printing and is designed to make sense in the long term. There are many technical differences (structured logging, MDC etc.) that I won't get into but they are important. To me it's mostly about the way you write the logs vs. the way you write a print. A log tries to solve the generic problem so you can deal with it in production if the need arises by…

totally agree re: structured logging. my intro to that was w/GCP Logging and it changed my mind on when and what to log. proper structured logging and keying metrics/alerts from those metrics is extremely satisfying and legitimately useful.

Re: Printf debugging is ok

#17

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime without accidentally committing prints to the repo. There are specific types of projects that are very hard to debug (I'm working on one right now), that's a valid exception but it also indicates something that should be fixed in our stack. Print debugging is a ha…

Agree. Safety critical kernels do not even have printf.

Re: Printf debugging is ok

#18
post #3

Whatever works so I can fix it and be home on time. I will even print (in paper) the code and step through it with a pen. Again, whatever works. Also, will we ever move forward from these sort of discussions? Back when I was a mechanic no one argued about basics troubleshooting strategies. We just aimed to learn them and apply them all (as necessary).

Based on the "lucky 10k" and the size of the internet, likely not. I'm sure if you find a mechanics enthusiast forum you will in fact find these relatively trivial arguments. It's just the nature of the beast.

I’d say programmers are taught to nitpick away at arguments by default. The nature of the code review is to verify that the code I wrote meets certain (opinions) standards. Hence nitpicking is built into the profession. Maybe one day it’ll improve. Till then, I’ll continue arguing about everything there is :-)

Re: Printf debugging is ok

#19
post #3

Whatever works so I can fix it and be home on time. I will even print (in paper) the code and step through it with a pen. Again, whatever works. Also, will we ever move forward from these sort of discussions? Back when I was a mechanic no one argued about basics troubleshooting strategies. We just aimed to learn them and apply them all (as necessary).

eternal september; people new people are continually learning new strategies.

You're correct, the real issue comes down to

1. making sure those printf statements don't wind up in prod, spilling potentially sensitive data or corrupting a data stream

2. making sure that non-printf tooling is built so that only printf debugging isn't used

We tend to get caught up in false dichotomies.

Re: Printf debugging is ok

#20
I have a very specific technical (UX) reason for using `print()` to debug sometimes.

In VS Code, if you want to run debugger with arguments (especially for CLI programs), you have to put these arguments in launch.json and then run the debugger.

This is often tedious to do, because I usually have typed these arguments and tested in terminal before, and now I have to convert them into json format, which is annoying.

To make it worse, VS Code uses a separate window for debug console than your main terminal, so they don't share history/output.

So if I know what to look at already and don't really need a full debugger, I often just use print() temporally.

Post reply on HN