Hacker News Reader

Comment by CryZe | Hacker News Reader

Not when you have a proper IDE setup where building + running it in debugging session are all done with a single action. I've done print debugging for a long time, and here and there it still makes sense, but I've found that it's honestly worth putting in the effort once per (decently sized) project to just set up the IDE properly. And honestly once you have done it once, it's mostly just copy pasting the same config from project to project.

View on HN

A lot of us believe that we spend a much smaller portion of our time looking at or debugging existing code than we really do. If you don't believe it's a time suck then you have very little incentive to keep pushing to get better at it. So the majority of us quickly reach a point where we are satisfied that we 'know how to debug' but leave a lot of room for improvement on the table.

The best description I've heard for master-level debugging is that it's a process of narrowing down the problem space as cheaply as possible. Your brain is telling you that based on everything you 'know' about the code, the right answer should come out. If the wrong answer is coming out, something you 'know' is wrong.

After the most obvious failure mode doesn't reveal the problem, your next check may not be the second most obvious failure. Instead you're multiplying the cost of verifying an assumption times the likelihood it's correct times the 'area' of the problem space it eliminates. Checking things like "is it plugged in?" sounds stupid but brings down the worst-case resolution time by hours.

Long story short, let's say I'm sitting in an interactive debugger looking at a stack frame, expecting that a particular variable has the wrong value, but it's fine. The cheapest thing for me to do next is to look at all of the neighbors of the suspicious value, and those in the caller and on the return. With println, pretty much every subsequent check costs the same amount as the first one. And if there's no short path from starting the app to running the scenario, that cost could be pretty high.

If you believe that you have a high success rate on your first couple of guesses, then println works great for you. But what if you're wrong? Have you ever tracked how many attempts it usually takes you? Or are you too wrapped up in the execution to step back and think about how you could do better next time?

Also, I want to be clear that I'm not telling anybody how to debug, as long as you aren't making that choice for your whole team. Don't choose tools or code conventions that break interactive debugging because "println was fine for grandpa so it's good enough for me!" That's a big ol' case of Chesterton's Fence.

Print debugging is a case of the Flub Paradox.

Having experienced the higher plane of fully integrated IDE / run / debugging with arbitrary expression evaluation, conditional breakpoints, etc, I can't even imagine how anyone could work with "print debugging".

I actually have gone in the opposite direction. I used to use a step-through debugger for all my debugging needs, but at this point I pretty much only do printf debugging.

I find that in most cases it's easier for me to figure out what's going on, because I can quickly scan a log of how different variables changed over time, instead of having to step through one step at a time.

Even if you have everything working just the way it should, in the majority of cases print debugging is enough because problems boil down to the assumptions in your head about what should be a variable not being reflected by what it is in your program.

You write tests? Consider selecting variables of interest (and printing them to STDERR when debug mode is on) like one of many test.

Looking at memory and all the variables has its place, but as you said only "here and there" - because when you have to do that, you have already lost: you are looking for a needle in a (hay)stack, and will lose much more time that just eyeballing the variables of interest you selected before.

Just wanted to say that your rust projects are a blast to watch from afar on twitter. You've done seemingly really crazy things with Rust + Zelda Wind Waker.

Thank you for sharing your hacks!

I so deeply hate that there is so much good content on Twitter that is simply lost if I don't happen to login on the given day. God forbid I'm not on the platform at all. It's so weird how RSS + Blog is a better experience for everyone, except advertisers.

Anyway, I'm super curious what someone is doing with Rust and Zelda. How do I learn more without Twitter?

Looks like this might be it? and then maybe I'm just missing out on images and videos that are only in some ephemeral tweet? https://github.com/CryZe/WindWakerBetaQuest

I was actually thinking of the crazy stuff the OP does to modify the game (geometry and collision, I think) [1] with rust. I hadn't even seen WindWakerBetaQuest - that's also really cool!

[1] Things like custom menus https://twitter.com/CryZe107/status/1026355408343126017

Playing around with physics https://twitter.com/CryZe107/status/991389826002931714

Implementing Super Mario Odyssey-style snow https://twitter.com/CryZe107/status/991104446812819456

Rendering the Rust logo into 3d namespace https://twitter.com/CryZe107/status/990644091963756544

Reply on news.ycombinator.com