Print debugging is the only way in a distributed system the way we are building micro services these days. We just call it logging.
Edit: ..and do it in production
The unreasonable effectiveness of print debugging
11–20 of 366 posts
Re: The unreasonable effectiveness of print debugging
#12I stopped doing step debugging at all many years ago. For me it looks the same as visual vs. text programming. Text and text search tools are just miles ahead of clicking buttons.
There's always gdb/lldb from the command line.
Re: The unreasonable effectiveness of print debugging
#13ITT: a non-controversial opinion shared by most programmers.
Print debugging is fast in many cases and requires little mental overhead to get going.
But for some/many systems, there's a huge startup and cooldown time for their applications - and compiling in a print, deploying the service, and then running through the steps necessary to recreate a bug is a non-trivial exercise. Think remote debugging of a deployed system with a bug that requires select network and data states that are hard or impossible to replicate in local/dev.
For things like this, being able to isolate the exact point of breakage by stepping through deployed code, and doing immediate evaluation at various points to interrogate state can't be beat.
This post strikes me as either (a) a younger programmer who still thinks that tool choice is a war rather than different tools for different jobs (b) someone making a limp effort at stoking controversy for attention.
Re: The unreasonable effectiveness of print debugging
#14Why "unreasonable"? There's nothing unreasonable nor wrong about print debugging. Moreover, it's a great first step towards logging and testing.
It’s “unreasonably effective”, meaning that a cost/benefit analysis is very clearly tilted towards benefit.
Re: The unreasonable effectiveness of print debugging
#15For python: i specifically recommend https://github.com/zestyping/q a lot, which is like print debugging on steroids:
All output goes to /tmp/q (or on Windows, to $HOME/tmp/q). You can watch the output with this shell command while your program is running:
tail -f /tmp/qRe: The unreasonable effectiveness of print debugging
#16IDE vs Text editor. OOP vs Functional. Logger vs debugger. The holy wars that shouldn't be. Why can't we all be friends and accept that Vim is better than emacs.
Re: The unreasonable effectiveness of print debugging
#17ITT: a non-controversial opinion shared by most programmers. Print debugging is fast in many cases and requires little mental overhead to get going. But for some/many systems, there's a huge startup and cooldown time for their applications - and compiling in a print, deploying the service, and then running through the steps necessary to recreate a bug is a non-trivial exercise. Think remote debugging of a deployed sy…
Probably explains why java has such a rich set of logging and debugging tools. Startup time, plus the idea that printing to stderr/stdout doesn't help you figure out where that goes in many java environments :)
Re: The unreasonable effectiveness of print debugging
#18IDE vs Text editor. OOP vs Functional. Logger vs debugger. The holy wars that shouldn't be. Why can't we all be friends and accept that Vim is better than emacs.
I heard the latter sentiment earlier today, but I don’t think anyone is actually passionate about what editor others use. Opinionated sometimes.
Re: The unreasonable effectiveness of print debugging
#19I stopped doing step debugging at all many years ago. For me it looks the same as visual vs. text programming. Text and text search tools are just miles ahead of clicking buttons.
So (for instance) in PowerShell my code breaks right as it is about to fail, with the state intact (ErrorActionPreference Break) which allows me to effectively fix whatever problem is about to occur and immediately have the state at the time of failure.
I dont understand how printing text could EVER approach this given I can test my assumptions right away and generally only need 1 error to happen to understand the totality of the circumstances.
Re: The unreasonable effectiveness of print debugging
#20Qt Creator debugger fails on me constantly, it's 2021 and the leading C++ plaf. is completely unreliable in that many more cases. That's why 'I must' use print debugging, because the 'powers that be' still provide a broken, half-baked solution 30 years in. Print debugging is however so powerful, I think there almost should be a mechanism built into languages and tooling around it so that it becomes part of the proces…
This kind of thing actually got added to a Microcontroller and its native SPIN language.
There is "SEND" which can be used as an ad hoc comms channel, aimed at a program method.
And a debug system that can both stream data, text and graphics to a client, as well as capture and report on the state of the 8 CPU cores possibly running.
https://www.parallax.com/propeller-2-graphical-debug-tools-i...
The debug output is something like using an xterm with Tektronix emulation turned on, and with all the lower level bits packaged away. The use can do a lot, from a "print" type operation to sophisticated graphics, static or animated.
On the capture side, a sort of supervisor region of RAM is reserved to for an ISR to capture processor state, or anything in memory really. Can be time, or event driven.