Don’t look down on print debugging

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.

Absolutely true that not all runtimes and languages have the same level of tooling. But the state of tooling has dramatically improved and keeps improving.

I use PyCharm for my projects including Python, for instance, and it has absolutely fantastic debugging facilities. I wouldn't want to use an IDE that lacked this ability, and my time and the projects are too valuable to go without. Similar debugging facilities are there for Lua, PHP, Typescript/JavaScript, and on and on. Debuggers can cross processes and even machines. Debuggers can walk through your stored procedures or queries executing on massive database systems.

Several times in this thread, and in the submission, people have referenced Brian Kernighan's preference for print versus debugging. He said it in 1979 (when there was basically an absence of automated debugging facilities), and he repeated it in an interview in 1999. This is used as an appeal to authority and I think it's just massively obsolete.

As someone who fought with debuggers in the year 2000, they were absolute dogshit. Resource limitations meant that using a debugging meant absolutely glacial runtimes and a high probability that everything would just crash into a heap dump. They were only usable for the tiniest toy projects and the simplest scenarios. As things got bigger it was back to printf("Here1111!").

That isn't the case anymore. My IDEs are awesomely comprehensive and capable. My machine has seemingly infinite processor headroom where even a 1000x slowdown in the runtime of something is entirely workable. And it has enough memory to effortlessly trace everything with ease. It's a new world, baby.

Wait, there is another way?

Looking at the comments here, I'm going to have to try to figure out how to use a debugger in pycharm on Monday!

Any tips or good videos on this?

I think print debugging is a symptom of an underlying problem.

There is nothing bad about print debugging, there is no reason to avoid it if that's what works with your workflow and tools. The real question is why you are using print and not something else. In particular, what print does better than your purpose-built debugger? If the debugger doesn't get used, maybe one should look down on that particular tool and think of ways of addressing the problem.

I see many comments against print debugging that go around the lines of "if you learn to use a proper debugger, that's so much better". But in many modern languages that's actually the problem, you have to invest a lot of time and effort on something that should be intuitive. I remember when I started learning programming, with QBasic, Turbo Pascal, etc... using the debugger was the default, and so intuitive I used a debugger before even knowing what a debugger was! And it was 90s tech, now we have time travel debugging, hot reloading, and way more capable UIs, but for some reason, things got worse, not better. Though I don't know much about it, it seems the only ones who get it right are in the video game industry. The rest tend to be stuck with primitive print debugging.

And I say "primitive" not because print debugging is bad in general, but because if print debugging was really to be embraced, it could be made better. For example by having dedicated debug print functions, an easy way to access and print the stack trace, generic object print, pretty printers, overrides for accessing internal data, etc... Some languages already have some of that, but often stopping short of making print debugging first class. Also, it requires fast compilation times.

I use a mix of strategies depending on the target platform. Right now, for nearly all of my hobby projects, the target platform is an old processor running on a weird game system without enough memory to run a real debugger and with no ability to expose that debugger's state to the PC. In these cases, I can't even really use printf (where would it print to?) and must instead rely on painting the debug information to the screen somehow. It's a wild and wacky set of techniques.

Of course, I pair this with a modern emulator for the target platform where I can at least see my disassembly, set breakpoints, watch memory values. But when I'm working on some issue that I can only reproduce on hardware, we get to bust out all the fun manual toys, because I just don't have anything else available. On the very worst days, it's "run this routine to crash on purpose and paint the screen pink. Okay, how far into the code do we get before that stops happening? Move the crash handler forward and search. (Each time we do this we are flashing an eeprom and socketing that into the board again.)"