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

Don’t look down on print debugging

blog.startifact.com

Post reply on HN
Print view View original

151–160 of 164 posts

Re: Don’t look down on print debugging

#151

Post by llm_nerd »

bluGill wrote: post #110
llm_nerd wrote: post #37

Earlier quoted context omitted.

There are loads of articles discouraging print debugging, and it's a very real thing that people fight against (and for). Print style debugging is the first thing most programmers learn, and for some it absolutely becomes a bad habit. And to be clear, print debugging and pervasive, configurable logging are very different things and the latter is hugely encouraged (even with logging levels), while the former is almost…

Print'here' is very useful. I get a log of how many times that funcion is called. If I log some data I log how that data changes over time. Those are powerful tools.

FWIW, many debuggers have facilities to do precisely this. The JetBrains debuggers allow you to set a breakpoint that -- in a non-stopping way -- simply logs every time it was passed, or logs whatever values you want it to log as an expression. So in one potentially non-stopping run you get an output of all of it.

Re: Don’t look down on print debugging

#152

Post by plorkyeran »

arkh wrote: post #95
llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

The thing is, in interpreted languages land print debugging has a power no debugger gives you: live debugging on your production instance. Something is broken in prod, you cannot reproduce it in your test environment because you think it may be due to a config (some signing keys maybe) you can't check. And it looks like someone forgot to put logs around whatever is the problem. You can either: spend multiple hours tr…

If you can ssh into one of your production nodes and modify the code to add some logging, you can also attach a debugger to your production node.

Re: Don’t look down on print debugging

#153

Post by codingdave »

llm_nerd wrote: post #22

While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…

The both have their place. Print debugging is ineffective for complex problems. The full power of debuggers is overkill for simple problems. Neither option is more powerful than slowing down, observing the problem, and just thinking about it. When you throw rubber duck debugging into the mix, all three tend to be fairly evenly distributed in terms of how often they solve the problem, in my experience.

Re: Don’t look down on print debugging

#154

Post by rspoerri »

For me print debugging ist the best way to work on a script or code if i dont know when debugging is finished. Most debugging sessions (using a debugger) i ever did were very complex situation where i knew how to trigger the error. And while i am sure that you can save debugging sessions i just dont need another tool (to learn) and install on multiple computers where i test and run my code.

Re: Don’t look down on print debugging

#155

Post by d0mine »

llm_nerd wrote: post #77
d0mine wrote: post #55

Earlier quoted context omitted.

Performance optimization is an excellent example of exactly the opposite. Why thinking first, creating the model of the code, to put a trace, metric, log call is better than mindless debugging. Interactive debugging has its uses but it may be less than appears at first and it encourages the wrong thing (local focus, irrelevant details). You should ask yourself first how fast the code should be and why (build the mode…

You should consider performance/efficiency at all stages. And that consideration should be based on an informed feedback loop where assumptions are validated and proven empirically. What developers think are performance patterns often wildly diverges from reality. The scenario I gave is when there are performance problems with a developed project (you know -- where a profiler is actually usable, after they already de…

Measurement is a necessary step but if you don’t think through the expected results first then it is easy to rationalize any results that a profiler provides (easy to lye to yourself).

I like the solid approach described in Understanding Software Dynamics by Richard L. Sites

Re: Don’t look down on print debugging

#156

Post by anotherevan »

Talking about print debugging has reminded me of a time I spent two weeks using a sideways form of print debugging to track down a timing bug. It was on an embedded system, and the bug when tripped would take out the serial communications line: at which point I couldn't get any diagnostics, not even print statements!

An in-circuit emulator was unavailable, so stepping through with a debugger was also not an option.

I ended up figuring out a way to be able to poke values into a few unused registers in an ancillary board within the system, where I could then read the values via the debug port on that board.

So I would figure out what parts of the serial comms code I wanted to test and insert calls that would increment register addresses on the ancillary board. I would compile the code onto a pair of floppy disks, load up the main CPU boards and spend between five and ninety minutes triggering redundancy changeovers until one of the serial ports shat itself.

After which I would probe the registers of the corresponding ancillary board to see which register locations were still incrementing and which were not, telling me which parts of the code were still being passed through. Study the code, make theories, add potential fixes, remove register increments and put in new ones, rinse and repeat for two weeks.

Re: Don’t look down on print debugging

#157

Post by Terr_ »

zaphar wrote: post #5
Terr_ wrote: post #2

To me there are three requirements for me to be comfortable with a team culture of print-debugging. 1. If a breakpoint debugger exists for the stack, it should still be convenient and configured, and the programmer should have some experience using it. It's a skill/capability that needs to be in reserve. 2. The project has automatic protections against leftover statements being inadvertently merged into a major branc…

Why would debugging be a team culture thing? It's very individual in practice.

Debugging tooling is a team/project level issue just as much as local build/run steps and coding-style. The effects are just harder than see.

Best practices and tricks for debugging a given project will impact things like:

* The overall productivity of the team.

* Writing guides and documentation.

* CI/CD scripts, such as preventing accidental leakage of print statements.

* How development environments are set up and configured, especially if there are containers or port forwarding or remote services involved.

* How team members collaborate when there's more than one person trying to diagnose a problem.

* Generally how you teach new juniors or experienced developers arriving with a learning curve.

Re: Don’t look down on print debugging

#158

Post by Terr_ »

tantalor wrote: post #13
zaphar wrote: post #5

Earlier quoted context omitted.

Why would debugging be a team culture thing? It's very individual in practice.

Agreed. I don't care how a team member debugs something as long as they can solve the issue.

Let's flip that around and replace "debugging" with "coding" for a moment. Imagine you have a new junior developer on the team, and their deliverables seem okay.

Then one evening you discover they've been staying late manually reformatting and reindenting all of their code using notepad before each commit. They explain this is because it's what they know will work reliably, and those other tools gave odd errors on their computer or had too many confusing options or needed some kind of bridge or dependency.

I might be impressed with their work ethic, but I can't just not-care about the problem that has risen into view. (Unless I'm literally counting the days until I move elsewhere.)

Re: Don’t look down on print debugging

#159

Post by shpx »

If anything the effectiveness/necessity of manually adding print statements to get any feedback about what the program you're working on is doing makes me look down on software development in general.

We are working on a system that could have nearly total visibility, down to showing us a simulation of individual electrons moving through wires, yet we're programming basically blind. The default is I write code and run it, without any visual/intuitive feedback about what its doing besides the result. So much of my visual system goes completely unused. Also debuggers can be a pain to set up, way more reading and typing than "print()"

Re: Don’t look down on print debugging

#160

Post by llm_trw »

dgfitz wrote: post #97
llm_trw wrote: post #85

Earlier quoted context omitted.

I find the people quick at fixing bugs are even quicker at introducing new bugs.

I have the complete opposite experience. I learned how to use a debugger from the only 10x programmer I’ve ever had the pleasure of working with. Person was a wizard at finding bugs. And they didn’t write many. My goal in code reviews was to find them from this person. I found 2 in 5 years.

You have one counter example. How many 0.1 programmers are there using a debugger to blindly change values in the program in the hope it fixes the bug?

I've seen dozens.

Post reply on HN