In my eyes Kibana / Elastic logging is even better, basic logging is useful for local-only dev work, but once its getting deployed, a more serious logging setup is infinitely more useful. You can log all relevant data down to a specific event or request and really dig into things as needed. If you use log levels correctly, you can get drastically more detailed by getting all the "debug" logs. This was the bread and butter at a former employer.
Printf debugging is ok
41–50 of 152 posts
Re: Printf debugging is ok
#42Earlier quoted context omitted.
I use both my thumbs on the spacebar to assert dominance on every word. But now I'm curious, which thumb do most people use on a keyboard?
My spacebar(s) are very smooth and shiny on the right compared to left.
By the same measure, looks like I use my left thumb by far the most. I'm left-handed.
Re: Printf debugging is ok
#43Earlier quoted context omitted.
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 find the key thing to avoid arguments is to not make the options adversarial. Present them as options. "If you like X, you may also like Y." Leave it to the audience to discriminate when to apply the tool.
Yes, good approach. Do you ever feel like the internet has been turned adversarial? Flame wars are as old as email but not the default.
Re: Printf debugging is ok
#44If using the debugger is less efficient than using printf then it's a symptom of a wider problem. To be clear though, "printf debugging" is not the same thing as adding structured debug logs to your service and enabling it on demand via some config. Most production services should never be logging unstructured output to stdout. Printf debugging is just throwing out some text to stdout, and it generally means running unit tests locally and iterating through an (add printf, run test, add more printf) loop until the bug is found. Unfortunately it's the default way to debug locally reproducible bugs for so many engineers. So while I don't see the point in not using printf for purely ideological reasons, I avoid building software where this is the simplest option and use the service's structured logger if not easily reproducible. I also generally think it's bad to default to printf debugging in the way I have defined it here and find that competent use of debugger is more often a faster way to debug.
Re: Printf debugging is ok
#45I find that a lot of this discussion just melts away if you are aware of the options that are available and then take your pick. Why, sometimes I've switched between debuggers and printfs as many as six times before breakfast.
If you don't know what a debugger does though that's something you should really get on ASAP. Likewise if you can't figure out how to get log messages out of your thing. Really all there is to it, figure out what you want to do after than and spend your time actually doing something productive instead of getting in a stupid holy war on the internet about it.
Re: Printf debugging is ok
#46Earlier quoted context omitted.
> 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. I’ve found before that sometimes I can’t see what’s wrong with the code on my screen but I can when I print it out. I think the printed page activates different regions of the brain compared to looking at a computer screen
You should try other things that force the brain to begin interpreting something again as new input; e.g., I have found success with changing the font, or the colour scheme, or looking at a diff rendition of a change, or looking at the file with less(1), or even reading the thing in reverse order, provoking a similarly new context where I see stuff I won't have seen staring at the editor for an hour previously. Anoth…
I increase the font size and just stare. Tends to work, too. Maybe we should be compiling them somewhere …
Re: Printf debugging is ok
#47I 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. T…
Yes, this is extremely frustrating sometimes.
Re: Printf debugging is ok
#48all 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)
Touch typing is objectively better, but 2 finger is enough to have a career at programming, it's not what is going to hold you back. I'd be more concerned about RSI than speed. You _really_ don't need to type fast for programming. If you do, your tools should be helping you do boilerplate more.
> Touch typing is objectively better
Even that depends on what exactly you mean. I agree with the literal meaning of the words, but for too many people "touch typing" means "home-row touch typing". Which I find extremely awkward and difficult. But literally just typing by touch, I'm self-taught due to StarCraft multiplayer back in the 90s and early 2000s, and have a style that confuses home-row typists when they realize what I'm doing.
So it's more like, you need to type smoothly enough that you're not thinking about typing. As long as your hands are pretty much moving automatically to get your thoughts into the computer, you can use any number of fingers at (almost) any speed, and you're good.
Re: Printf debugging is ok
#49If you have a reproducible test case that runs reasonably quickly, then I think printf debugging is usually just as good as a "real" debugger, and a lot easier. I typically have my test output log open in one editor frame. I make a change to the code in another frame, save it, my build system immediately re-runs the test, and the test log immediately refreshes. So when the test isn't working, I just keep adding printfs to get more info out of the log until I figure it out.
This sounds so dumb but it works out to be equivalent to some very powerful debugger features. You don't need a magical debugger that lets you modify code on-the-fly while continuing the same debug session... just change the code and re-run the test. You don't need a magical record-replay debugger that lets you go "back in time"... just add a printf earlier in the control flow and re-run the test. You don't need a magical debugger that can break when a property is modified... just temporarily modify the property to have a setter function and printf in the setter.
Most importantly, though, this sort of debugging is performed using the same language and user interface I use all day to write code in the first place, so I don't have to spend time trying to remember how to do stuff in a debugger... it's just code.
BUT... this is all contingent on having fast-running automated tests that can reproduce your bugs. But you should have that anyway.
Re: Printf debugging is ok
#50Whatever 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 1: the recent iTerm2 fracas. Yikes.