This is not so much puts debugging. It looks like Ruby provides enough introspection that its runtime can be used to debug itself. Even coming from a Python background, I was surprised to see that so much of this was possible.
The only debugger I’ve found to be worthwhile is the one in Visual Studio, for any language (I’ve done C# and JS in it so far) - anywhere else, I’ll just put printfs. VS all the stuff you’d expect and puts it together well.
The fun starts a few iterations in, once you discover that you want to puts something slightly different from what you originally wrote. Then you have to alter the puts, load up the entire application again (which can take minutes, depending on the size of your codebase) and navigate it back into exactly the state you had before. (Hope you kept a lab notebook!)
As another puts debugger (well, print because Python) I’d always wondered what was so great about debuggers that people made such passionate defenses of them, and worried that maybe I was missing some crucial tool or insight.
However, I don’t think I’ve ever had to debug problems other than (a) tools that run deterministically to completion in minutes at most, or (b) production systems where debugging is impractical anyway. So I guess I’m just outside the debugger target demographic.
I agree that it’s not especially practical to attach a “stop the world” debugger (like gdb) to a production process. But this is most definitely not the only kind of debugging tool that exists.
I make extensive use of DTrace to collect data about function calls and other events; both in the operating system kernel and in various user mode software. I can dynamically enable instrumentation to track the frequency of, and arguments to, many different kinds of probe points. For example:
This tracing data can be aggregated into a number of interesting visualisations to assist with reasoning about the dynamic behaviour of a process when running in production without inducing significant overhead. One of the most compelling is the flamegraph. Combining a tool like stackvis with DTrace profiling data, I can generate flamegraphs of different types to better understand what a busy program is doing.
The reason I am so enamoured of these tools is that they allow me to instrument software in production without modifying and redeploying it. Depending on how you use DTrace it can have low, or even near-zero probe overhead when enabled – when disabled, there is generally no overhead. I can even get insight into programs I did not write or compile myself, which has been instrumental in work on the LX brand at Joyent. We often deal with bugs that are not reproducible, or which disappear when the program is modified to include debug output: the extra work of logging can introduce variations in system behaviour. Safe, low impact, feature-rich debugging tools are (in my experience) a vital part of operating a production software system.
Lots of things are too annoying to be feasible if you have a system that doesn’t let you reload files on an individual basis. Doesn’t mean the technique is worthless for people who do live in the 21st century.