The unreasonable effectiveness of print debugging • Hacker News Board

Re: The unreasonable effectiveness of print debugging

#121

Post by klyrs » Sat, Apr 24, 2021, 5:20 PM UTC

bakatubas wrote: post #44

CJefferson wrote: post #23

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

As a counter-point, I think there’s an argument that folks don’t spend enough time in the debugger. But there’s a lot of value there and in fact one could use a debugger environment to unit test as even native debuggers have scripting environments. Personally, I think folks should master the debugger _first_ and during all steps learning a programming language. But similar to test-driven-development it’s a different…

In a world with perfect optimizing compilers that never introduce bugs, we should never "need" print debugging. But that's not where I live, so I'll keep using print debugging.

On the other hand... adding print statements can also invalidate certain optimizations (an excellent source of heisenbugs), so I'll never stop using debuggers either

Re: The unreasonable effectiveness of print debugging

#122

Post by yaantc » Sat, Apr 24, 2021, 5:22 PM UTC

goalieca wrote: post #11

Print debugging is the only way in a distributed system the way we are building micro services these days. We just call it logging. Edit: ..and do it in production

Yes. The same apply to a lot of embedded systems. When you can't stop the system you better learn how to debug from logs. And put the right logging support in place ahead of time: it may be impossible to replace the software in place by a new debug version, and then it's only based on preexisting logs and just adapting the logs configuration.

Re: The unreasonable effectiveness of print debugging

#123

Post by mark-r » Sat, Apr 24, 2021, 5:23 PM UTC

varispeed wrote: post #70

breck wrote: post #58

I hate coding in an environment that does not easily support step-wise debugging. And yet, I use printf 10x-100x more frequently. Printf is actually causing you to do some thinking, and writing a little bit of code to conduct an experiment that hopefully will tell you in one shot what the problem is on a simple run. Step-wise debugging instead forces you to think about the problem, but then go through carefully and r…

There are environments where printf is not possible - e.g. MCU development. For instance, if the code breaks before the serial port is setup for printf to work.

You can always just send the output to a block of memory that is reserved for debugging, and dump out that block when necessary.

Re: The unreasonable effectiveness of print debugging

#124

Post by d0mine » Sat, Apr 24, 2021, 5:26 PM UTC

le-mark wrote: post #31

CJefferson wrote: post #23

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

I’m sorry but this is just ignorance, learning to use the debugger for the platform at hand is a basic skill every developer should master. So many times have seen developers use the debugger to troubleshoot and fixed issues and been perceived as a “ninja” (despise that term but that was the effect) because they knew how to use the debugger. I mean yeah keep printing lines, and keep being out performed by your debugg…

You are missing out on the important point: printing forces you to formulate a hypothesis: what you expect and to compare with what you actually get. Debugging encourages less modeling and more trying random stuff until something sticks.

It is an exaggeration. In practice, it is useful to apply both. Novices can get some insight using debugging, more experienced with code base people should exercise their understanding of the code and use well picked prints.

Re: The unreasonable effectiveness of print debugging

#125

Post by formerly_proven » Sat, Apr 24, 2021, 5:30 PM UTC

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?

Breaking is just the default behavior when a breakpoint is hit, you can generally attach whatever behavior / conditions you want using the debugger's scripting language.

Re: The unreasonable effectiveness of print debugging

#126

Post by Fronzie » Sat, Apr 24, 2021, 5:31 PM UTC

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…

The one beginners often miss:

What output do you expect?

Ask this yourself before starting the debugger. Without this, it is very easy to glance over the point where things go funny.

Re: The unreasonable effectiveness of print debugging

#127

Post by alpaca128 » Sat, Apr 24, 2021, 5:32 PM UTC

mcbuilder wrote: post #49

fao_ wrote: post #29

Earlier quoted context omitted.

I used to think like you, friend! For over a decade, then I discovered doom emacs :)

For those wondering, Doom Emacs is a better vim (from evil-mode) than vim and so much more (easy out of the box community configs for most languages and tools, and way more cool stuff) inside the Emacs OS.

What always prevented me to actually switch to Emacs was how it's so huge it seems impossible to get an overview of how to do what. Every programming language-specific mode comes with its own unique features that surprise me when I just want to write code, meanwhile just entering a single tab without it getting deleted again is an odysee of reading documentation. At the same time it's slow and despite it having the best Vim emulation it cannot hide that Emacs just doesn't work like that. As soon as you leave the file's buffer you discover how Evil mode's illusion falls apart on all sides and you always land in situations where you have to use a mix of Vim and Emacs keybindings.

I love the concept behind Emacs, I just think at least 80% of its code should actually be in plugins, and the program itself and a lot of large expansions are really bogged down by the sheer size and lack of simplicity.

Oh, and Emacs-Lisp...it's much better than Vimscript, but it's a disappointment nonetheless. Loops instead of recursion in Lisp, really? And last time I tried it the parser could not handle unmatched brackets in comments.

Re: The unreasonable effectiveness of print debugging

#128

Post by Jeff_Brown » Sat, Apr 24, 2021, 5:35 PM UTC

kstrauser wrote: post #92

Jeff_Brown wrote: post #63

For print debugging in Python I recently discovered a nice little time-saver: the icecream package. Rather than having to type "print( "x: ", x )", you can instead type type "ic(x)". [1] https://github.com/gruns/icecream

Also, “print(f’{x=}’)” without an external dependency.

Cool! Where can I read about what's going on in that?

Re: The unreasonable effectiveness of print debugging

#129

Post by revscat » Sat, Apr 24, 2021, 5:36 PM UTC

j4yav wrote: post #65

mcbuilder wrote: post #49

Earlier quoted context omitted.

For those wondering, Doom Emacs is a better vim (from evil-mode) than vim and so much more (easy out of the box community configs for most languages and tools, and way more cool stuff) inside the Emacs OS.

I tried using it but got stuck on having to learn Lisp to understand my config file.

Apparently all the cool kids are using neovim + Lua these days. Lisp turned me off of emacs years ago as well. Recently I started digging into Neovim and have found Lua much easier to parse/internalize than Lisp, and kind of a joy to work with.

Re: The unreasonable effectiveness of print debugging

#130

Post by wmichelin » Sat, Apr 24, 2021, 5:37 PM UTC

CJefferson wrote: post #23

Personally, I think my biggest reason for using print debugging is.. it works. In C++ I often find the debugger doesn't find symbols on projects built with configure/Make. If I have a Java Gradle project I have no idea how to get it into a debugger. Python debuggers always seem fragile. Rust requires I install and use a "rust-gdb" script -- except on my current machine that doesn't work and I don't know why. I'm sure…

Python easily has the best debugger I've ever seen in a language.

``` import pdb; pdb.set_trace() ```

that's literally all you have to do at any point in your code. Run your code in the foreground of a terminal, and boom you have a debugger exactly where you want it.