Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of print debugging

buttondown.email

Post reply on HN
Print view View original

101–110 of 366 posts

Re: The unreasonable effectiveness of print debugging

#101

Post by jhgb »

eddieh wrote: post #84
jhgb wrote: post #43

I had a crazy idea the other day that perhaps there could be something like "CSS for program execution traces". If you think of function identifiers as XML/HTML tags and arguments for individual function activations as element attributes, then perhaps something similar to CSS selectors but acting on the tree representation of a program's execution could trigger at certain clearly defined points during the execution a…

Sounds a lot like syntactic sugar or a DSL for symbolic breakpoints combined with conditionals. That's certainly doable. Something like: func1(4) > func2(null) debug; Semantically: upon func1 called with arg 4 and some descending path that calls func2 with arg null, enter the debugger Neat idea!

I got the idea when I was thinking about the applicability of computer algebra systems to math education. Some way of visualizing the decisions and steps of a logically complicated program seemed necessary for that. Getting a readable trace of the computation in a similar way to the one that some logical programs or expert systems can justify their reasoning with seemed like a usable form of such a visualization, and some time later then the analogy with CSS/XSLT struck me. I was thinking of collecting all the steps into an output, but setting breakpoints in a similar fashion with individual "selectors" could be useful for debugging, too.

Re: The unreasonable effectiveness of print debugging

#102

Post by CJefferson »

1337shadow wrote: post #97
CJefferson wrote: post #71

Earlier quoted context omitted.

Honestly, I didn't know that and I'll try it. Last time I had to debug I remember adding "-m pdb" (as at the start of https://docs.python.org/3/library/pdb.html , first result in Google), but for some reason that immediately threw an error instead of starting the program, so I just chucked some prints in instead.

I just tried python -m pdb and it works for me https://dpaste.org/9EQo#L26 but I really always use breakpoint(). You can even configure it to use other debuggers with an environment variable, ie.: PYTHONBREAKPOINT=ipdb.set_trace

I just quickly went any checked the program I was trying to debug. I was running 'python3 package --arguments', where 'package' is the name of a directory which contains a package I was working on. 'python -m pdb package --arguments' just complains that 'package' is a directory.

Adding a 'breakpoint()' at the start of the program does get me into the debugger. I'll remember that for future (but, it's not easy to find by googling if you don't already know what you are looking for!)

Re: The unreasonable effectiveness of print debugging

#103

Post by ArtWomb »

Have never found writing to logs to be "effective". More a necessary evil ;)

What is really effective is "visual debugging". Say for example you are testing for bias in an RNG. Rendering a large format image of random rgb values will immediately show any cycles, even to the untrained eye.

Consider GPGPU workloads, for ML or ray tracing for example. There are myriad levels of variables to track: resources, allocations, command buffer state, synchronization, compute kernel per vector, and so on. All primitives that very much lend themselves to graphical representations!

Right now editing live code in a profiler usually involves textual editing of the graphical shaders. But it's easy to see how this evolves to a purely visual shader editor, not unlike those found in Unreal or Godot.

Re: The unreasonable effectiveness of print debugging

#104

Post by arendtio »

Another aspect, where printf debugging can be better than debuggers are use-cases where timing is relevant. Some bugs don't occur when break points stop the program at certain points in time. For completeness is should be added, that there are also cases where the printf can change the performance and make it impossible to find a bug.

I think the two methods are complementary and should be use in combination.

However, the big issue is that basic printf debugging is very simple to use and debuggers have a steeper learning curve in the beginning. Therefore, people start using printf debugging and don't invest into learning how to use debuggers. And when developers don't invest into learning how to use debuggers properly, they are missing the skills to utilize them and still use printf debugging in cases when debuggers are clearly superior.

Re: The unreasonable effectiveness of print debugging

#105

Post by damagednoob »

Androider wrote: post #94

Speed of iteration beats quality of iteration. You can step through the program, reason about what's going on, tracking values as they change. But if you missed the moment, you have start again from the beginning (time traveling debuggers being rare). Or maybe you're looking at the wrong part entirely at this stage, and just wasting time. With print debugging you write a bit of code to test a hypothesis. Then you run…

> Speed of iteration beats quality of iteration.

That's especially true if you're doing some form of TDD/unit testing. With IntelliJ, I can easily set it to watch for changes and cycle one unit test while I make changes. If something weird happens I can just drop a printf in there, understand and rectify the issue, then take it out. Much faster than step through debugging.

Re: The unreasonable effectiveness of print debugging

#106

Post by winrid »

jollybean wrote: post #8

Qt 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…

Have you tried Clion?

Re: The unreasonable effectiveness of print debugging

#107

Post by lainga »

Swizec wrote: post #91
roenxi wrote: post #73

Probably the most interesting thing about development as a discipline is the near radio silence on how to debug. There is a decided lack of academic success in engaging with debugging as an object that can be studied. There are channels to learn about debugging as a stand-alone topic. Programmers don't often talk about debugging techniques in my experience. For something that takes up the overwhelming bulk of a devel…

Debugging is impossibly difficult to teach. It's much closer to "how to solve an escape room" than it is to "how to build X". Debugging requires deep understanding what you are doing and your system. It's different every time. And while there's a general algorithm you can follow: 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 How would you teach that…

I might suggest a few of the adventures of Sherlock Holmes.

Re: The unreasonable effectiveness of print debugging

#108

Post by edoceo »

majjgepolja wrote: post #69
pjmlp wrote: post #39

Earlier quoted context omitted.

They weren't ninjas, otherwise they would have used breakpoint actions for doing those print statements without modifying the source code.

What's breakpoint action? Is it like inserting printf before breakpoint?

maybe this is sometimes called assert()? or in some debuggers you set a watch on a var and the BP triggers only on the watch-condition so the BP don't trigger each loop, only when x=7

Re: The unreasonable effectiveness of print debugging

#109

Post by colonwqbang »

Swizec wrote: post #91
roenxi wrote: post #73

Probably the most interesting thing about development as a discipline is the near radio silence on how to debug. There is a decided lack of academic success in engaging with debugging as an object that can be studied. There are channels to learn about debugging as a stand-alone topic. Programmers don't often talk about debugging techniques in my experience. For something that takes up the overwhelming bulk of a devel…

Debugging is impossibly difficult to teach. It's much closer to "how to solve an escape room" than it is to "how to build X". Debugging requires deep understanding what you are doing and your system. It's different every time. And while there's a general algorithm you can follow: 1. Guess what's wrong 2. Ask "How would I prove that's wrong?" 3. Try it 4. If bug found, fix, if not go back to 1 How would you teach that…

For a system of moderate complexity, there are myriad answers to question (1). A skilled programmer has the intuition to guess the most likely causes. This ranges from the mundane (e.g. recompile everything from scratch) to the occasional almost magical lucky guess which immediately leads to a solution.

Re: The unreasonable effectiveness of print debugging

#110

Post by matsemann »

Androider wrote: post #94

Speed of iteration beats quality of iteration. You can step through the program, reason about what's going on, tracking values as they change. But if you missed the moment, you have start again from the beginning (time traveling debuggers being rare). Or maybe you're looking at the wrong part entirely at this stage, and just wasting time. With print debugging you write a bit of code to test a hypothesis. Then you run…

I often use prints to find the suspect, and then debugger to weed it out. Conditional breakpoints make it easy to stop at the correct place.

About your debugging from the beginning: with Intellij on the jvm one can "drop frame", which is basically to discard the current function and start over with the stack as it was. Since I mostly write kotlin my objects are immutable, so rerunning most stuff actually works fine. And hot-swapping the function while the debugger is paused I can even try multiple implementations without having to rerun everything, just drop frame, hot swap, step into the new and updated function.

I'd say knowing the debugger well and using it is a faster way to iterate than not.

Post reply on HN