The fact remains that when we think of debugging tools we tend to build monolithic debugging environments rather than unix-style primitives that do one thing well. Thinking deeply about when prints work best and how we can ameliorate their drawbacks is a fertile place to change this. A couple of concrete ideas:<p>a) For a while now, I&#x27;ve experimented with editor macros to comment&#x2F;uncomment code that insert a special marker after the comment leader (like say &#x2F;&#x2F;? for C++ or Java) that allows me to programmatically distinguish real comments from commented-out code. An immediate benefit is that I can select large ranges of text and enable&#x2F;disable prints without messing up interspersed prose. A more subtle benefit is that it lets me leave prints in version control for weeks of time and watch which prints I use most often when debugging. I&#x27;ve also experimented with a couple of subsidiary experiments: a1) highlighting &#x2F;&#x2F;? comments differently (much less saliently) than real comments, so they don&#x27;t bother me as much in my editor, a2) having my comment macro set&#x2F;increment a per-line counter which provides even more fine-grained telemetry about how my codebase is used. It&#x27;s illuminating to save all the prints you made while debugging a problem that ends up being just a one-line fix. Even if you end up deleting all the prints immediately in the next commit. And if you think it makes merging harder, well that&#x27;s just a task for another simple unix-like tool: to filter out commented-code before merging, and add it back in afterward.<p>b) A big problem if you do a lot of printing is to find the right prints that help you debug your problem now. Print too much and it becomes easy to get lost in all the verbiage. I&#x27;ve tried battling this problem with a &#x27;zooming editor&#x27; which reads a potentially huge log but displays only stuff at the highest level of abstraction, letting the user selectively click on lines to expand more and more detail around them. I can even bring up this zooming editor automatically when my program dies in debug mode: <a href="http:&#x2F;&#x2F;akkartik.github.io&#x2F;mu&#x2F;html&#x2F;090trace_browser.cc.html" rel="nofollow">http:&#x2F;&#x2F;akkartik.github.io&#x2F;mu&#x2F;html&#x2F;090trace_browser.cc.html</a> [1] This is an incredibly useful tool, because it turns a two-sided problem into a one-sided one; instead of having to walk the tightrope between too much logging and too little I can just log everything and poke at it in my leisure.<p>Not all these ideas are good. I gave up on a2) above after a few months, for example. But there&#x27;s lots of room for questioning conventional wisdom and trying new things.<p>[1] Details on my literate format: <a href="http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;wart-layers" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;wart-layers</a>