IDEs are amber and throw away effort. All the break points, data integration and what not is thrown away after the bug is fixed. Further this IDE effort is not shared between developers. Log debugging is reusable out of the gate. Log debugging can easily be promoted to a production statement if deemed important. IDE developers it seems to me need to work on how all the time and energy IDE developers spend on a bug can be generalized to the point these things can be shipped with the code itself. Until then it is throw away work trapped in the amber of the IDE.
The unreasonable effectiveness of print debugging
301–310 of 366 posts
Re: The unreasonable effectiveness of print debugging
#302Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…
I think the Key phrase from that quotation is "thinking harder". A debugger gives you all of the programme's state as a kind of vast animation, so it's easy to start working with one thinking "Something's going wrong here, so I'll just step through the whole programmme and see when things start looking like they're going wrong". It's then easy to miss the problem due to the vast quantity of data you have to parse. Using print statements, in contrast, forces you to formulate simple hypotheses and then verify or falsify them, e.g. "I think this variable in this function is causing the problem" or "I think everything's fine with the execution up to this point". I.e. the very fact that a debugger works so well at giving you an insight into how the programmes state can itself be part of the problem: it can be overwhelming.
Re: The unreasonable effectiveness of print debugging
#303Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…
The Chrome devtools make adding a logpoint as easy as setting a breakpoint. So instead of adding your print statement, and rebuilding the app you can do it live. I think this is strictly better as you still get to enjoy the mental exercise of deciding where to put the logpoint. Even better, you can run anything you want in a logpoint, my favorite is console.profile/profileEnd() to get a cpu profile between two lines of code.
Re: The unreasonable effectiveness of print debugging
#304Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…
> Personally, I think my biggest reason for using print debugging is.. it works.
I agree.
A similar statement is that using a debugger often does not work.
the sort of ratholes I've run into are: - debug build - proper symbols - interrupts and debugger - kernel and debugger - unfamiliarity with debugger - limitations of debugger
Without a proper debug build, you can't run the debugger effectively. You have to set up a whole debug environment.
Sometimes you need to do broad work to get proper symbols and stack trace information. By broad, I mean a debug build for everything.
I've also found many debug builds, apart from altering some behavior, they also turn on a lot of printfs.
If you're using interrupts/timers or debugging a kernel module, many times debuggers don't work or may alter, move or supress the problem.
and then there's the... I haven't used a debugger in 6 months, how do I do (very simple thing). And sometimes the debugger is just not the right tool or a tedious tool to use. "If I just load this one macro and somehow get the right address maybe I can decode this one kernel data structure..."
Personally, many times an ephereral printf isn't crude and meaningless, it's a precise scalpel getting to the core of the problem.
Re: The unreasonable effectiveness of print debugging
#305This feels like an instance of "worse is better". It works well enough, it is easy to start, it is robust, and it is naturally integrated into your workflow (which is, run the code you wrote.) Debuggers are like a perfectionist approach, and still lacks things like timeline-like view that the articles mentions.
Re: The unreasonable effectiveness of print debugging
#306Earlier quoted context omitted.
What's breakpoint action? Is it like inserting printf before breakpoint?
Breaking is just the default behavior when a breakpoint is hit, you can generally attach whatever behavior / conditions you want using the debugger's scripting language.
Reading through the majority of this comment section, I get the impression that those who like print statements find value because they aren’t proficient with modern debuggers, rather than they find print statement valuable even though they’re proficient with debuggers.
Re: The unreasonable effectiveness of print debugging
#307Earlier quoted context omitted.
I’m sorry but this is just ignorance, learning to use the debugger for the platform at hand is a basic skill every developer should master. So many times have seen developers use the debugger to troubleshoot and fixed issues and been perceived as a “ninja” (despise that term but that was the effect) because they knew how to use the debugger. I mean yeah keep printing lines, and keep being out performed by your debugg…
I've used print debugging extensively doing embedded development, when I could reasonably hook up a serial port to capture the output, or put a crude console on a tiny screen. These systems can't always be debugged in the traditional sense, and if you're troubleshooting some bug that happens on hardware but not in your simulator, then you use the tools you have available.
[deleted]
Re: The unreasonable effectiveness of print debugging
#308Earlier quoted context omitted.
Linus used to be against kernel debugging for the longest time. The core of his position (as I understand it) was that regularly needing a debugger is a sign that your software has "gotten away from you". You've let the software get to a state where it cannot easily be understood from the architecture and program text alone. I do think debuggers can be useful when building up comprehension - particularly of other peo…
I hold the very same opinion, interactive debugging in general should be a rare need. If it's being used too often then it points to the fact that the software has to be run in order to understand it. It's representation is not sufficient to convey it's run time behaviour. Also would like to point that dynamic languages in general require more debugging than statically typed one's since one can't be certain of the da…
I usually find that debuggers are more useful in dynamic languages. As an example in python many bugs are due to an incorrect structure being passed into a method due to the method or input being underspecified/abused.
In such a case it's difficult to decide what to print or more particularly how to print it if it's type/shape is unknown.
Re: The unreasonable effectiveness of print debugging
#309Almost all the reasons people use print debugging can be overcome by improving debuggers --- and to some extent already have been (in the words of William Gibson, the future is already here, it's just not evenly distributed yet). I think it's important for people to understand that the superiority of print debugging is contingent and, for many developers, will not persist. Record-and-replay debuggers like rr [0] (dis…
> Almost all the reasons people use print debugging can be overcome by improving debuggers speed and simplicity https://www.youtube.com/watch?v=JXQZhyPK3Zw&t=1410s
These are important, but for larger projects "speed" is often not a feature of print debugging when you need multiple iterations of refining your logging statements.
"Simplicity", sure ... it's difficult to beat the simplicity of not using tools.
Re: The unreasonable effectiveness of print debugging
#310Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…
I think the Key phrase from that quotation is "thinking harder". A debugger gives you all of the programme's state as a kind of vast animation, so it's easy to start working with one thinking "Something's going wrong here, so I'll just step through the whole programmme and see when things start looking like they're going wrong". It's then easy to miss the problem due to the vast quantity of data you have to parse. Us…
Why would one step through the whole program? Use the approach you describe for print statements, but for breakpoints instead. Set them, inspect the relevant state when one is hit, then resume execution until the next is hit.