Live data from Hacker News

The unreasonable effectiveness of print debugging

buttondown.email

361–366 of 366 posts

Re: The unreasonable effectiveness of print debugging

#361
post #254

Earlier quoted context omitted.

Using a debugger is largely passive - it shows you what is actually happening. Debugging via print allows you to step outside and peer in ie it is active . Print debugging can be prone to bugs within itself which may cause additional ignorance about the potential bugs being diagnosed. How meta can you get? 8) There's also the effect of the effort of actually looking - that may or may not have an effect. Anyway, the d…

(most) debuggers can print - I often use conditional breakpoints with the "condition" "print(thing)". It works great, doesn't require re-compiling, can be enabled/disabled with a single click, etc. It's handy when you want to see a lengthy sequence all at once.

Discovering this capability changed how I debug. Conditional breakpoints that log-only creating an always useful, easily enabled/disabled log of critical method results without littering the code itself with logging statements.

Re: The unreasonable effectiveness of print debugging

#362
I love tracepoints, which is basically print-statements but dynamically from he debugger. Sadly I almost always end up in having performance problems, so I still need to an if or so to the code for the tracepoint to perform well. And then were back at printf debuggging again...

Re: The unreasonable effectiveness of print debugging

#363

Earlier quoted context omitted.

> you’ll have breakpoints set that aren’t necessarily needed at the moment, meaning you have to continue a bunch of times to get to the right spot. Python: if something: breakpoint() Js: if (something) debugger; Much easier than breakpoint conditions in visual debuggers imho.

That runs the risk of forgetting to remove it.

If you don't read your commits before pushing or even merging them ... But I use `git add -p` and `git checkout -p` which works well against this

Re: The unreasonable effectiveness of print debugging

#364
post #349
post #336

Earlier quoted context omitted.

I'm not sure what's difficult about (map! :n "ff" #'save-buffer) ; Save (map! :n "fq" #'kill-current-buffer) ; Quit a buffer or (defun my/org-buffer-check () "Check that we are in org-directory, and the buffer name is in that directory" (and (string= org-directory default-directory) (seq-contains (directory-files org-directory nil) (buffer-name) 'string=))) the latter being easily represented as: function my/org-buff…

Sorry but that is not clear or obvious at all to me.

I understand the "!", I use it when it fails the first time and I'm trying to hint that I really really want it to work.

Re: The unreasonable effectiveness of print debugging

#365
post #216

I'm working on Swift interpreter and the codebase is fairly difficult to debug. There's a lot of reused bits. So if you put a debug point somewhere trying to capture one behavior, odds are that that line will run 10 times for other work before the relevant part uses it. So I tend to write a LOT of print statements that flush of debug variables right before I where I want to debug. Then I set a conditional breakpoint…

Why not just add an action to the conditional breakpoint that prints the value?

I’m usually constructing those values just for that one-off test. They aren’t there at runtime.

It’s an AST interpreter so sometimes I want to see the value of something that’s 5 properties away inside a syntax node

Re: The unreasonable effectiveness of print debugging

#366
post #255

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

I’ve said this before, but rr really is a superpower, and Pernosco doubly so. Definitely worth every penny.
Post reply on HN