Follow

Thread on debug by print vs debuggers

buttondown.email/geoffreylitt/

robert.ocallahan.org/2021/04/p

I'm pleasantly surprised that so many people care about debug by print. I've always felt like a lone voice before when talking about it. Great!

I think this conversation is missing the point, though, about what makes debug by print special. The key skill it teaches is reasoning about a program by modifying it. Interacting with your program in all its depth, rather than just through a pane of glass.

· · Web · 3 · 2 · 12

The debug cycle consists of edit, run, observe. When might better debugging tools be counter-productive? If they cause you to forget that there is a debug cycle, and to stay too long observing when a new modification would get you to the answer faster.

I’ve seen people stymied when their tools stop working. Tools will always will have limits. A bug takes hours of execution, it overflows RAM. Prints prepare one for times when you have to leave your tools behind and enter the wilderness.

@akkartik i feel prints lose usefulness in large projects, which is a case against large projects :p

@eris Disagree! The value of prints is independent of LoC or team size. It _can_ be dependent on run duration, however.

In my experience the situations where prints fail to scale are also outside the envelope of other tools. You end up needing to build new tools. (I really like github.com/akkartik/mu/blob/ma)

@akkartik One of the most difficult bugs that I've had to deal with involved a processor which ended up in a tight loop due to stack overflow. Ironically, that behavior was what was intended, albeit through a more traditional while loop. That was a fun one!

@akkartik It's funny because as a noob, debugging by print is already the most reliable way to figure things out, printing is the first way you learn to get your data out of the program in most cases. It tells me everything I need to know. What's coming down the pipeline, how it's mutating compared to the expected results, if not then at what point in between did it screw up, and then narrow it down. I only use stepping at the in-between section if either the output is too larger --

@akkartik -- or I can't pin-point it immediately.

I guess it depends on the scope of your project but stepping through often seems redundant, having to either type continue after every step vs piping the print statements out to a file along side whatever data you're expecting and grepping your point of interest and see what shows up.

Like I accidentally pushed this to my repo.

raw.githubusercontent.com/Limi

@akkartik I was looking for 16 numbers in this array that weren't suppose to be showing up. It was easier to pipe it out in a massive blob with print and grep it than it would be to step through each line individually. It tells me literally everything I need to know along the way.

@akkartik For me, it's simply a matter of deduction vs observation. It's faster for me to see printed state at a few points and reason out what happened, than to roll thru hundreds of irrelevant states.

People who don't hold the program state in their head will prefer watching each step.

In theory I could set breakpoints and see the same states, but it's more effort than a few DLOG lines.
#debugging #print

Sign in to participate in the conversation
Merveilles

Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.