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

The unreasonable effectiveness of print debugging

buttondown.email

Post reply on HN
Print view View original

61–70 of 366 posts

Re: The unreasonable effectiveness of print debugging

#61

Post by fao_ »

edwinyzh wrote: post #53
fao_ wrote: post #29

Earlier quoted context omitted.

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

Wow, by looking at this screenshot ( https://raw.githubusercontent.com/hlissner/doom-emacs/screen... ), is doom emacs a terminal/console program or a GUI program?!

It's a number of extremely, extremely well crafted layers on top of Emacs.

I switched last July and after 8+ years of using variations of Vim, Vi, Ex-Vi, Ed(1) (yes), NeoVim, et all, it is by far the smoothest experience I've ever had.

Unlike my experience with Spacemacs, I haven't had any problems adapting from Vim -- there are no points where the Vim interaction layer breaks down, and it genuinely feels like an editor that I'll be using for the next 20+ years. Like something that can grow around me.

Re: The unreasonable effectiveness of print debugging

#62

Post by varispeed »

The best way of finding faults for me is writing a test that fails the problematic condition and then use prints in all parts that I think are being executed and may have key information to help solving the mystery.

I tried using debuggers, but it was always too much hassle.

Re: The unreasonable effectiveness of print debugging

#64

Post by pbiggar »

Both suck. With a debugger, you need to set up a debugger and step through (and often, they don't work quite as well as you hope). With print debugging, you need to add the print statements.

In both, you can't retroactively debug already executed code.

This is one of the areas where I'm really proud of what we did in Dark. In Dark (https://darklang.com), all execution is traced and you can see the value of any expression on any trace by putting your cursor in the expression. Advantages:

- no struggle to reproduce the error

- no need to set up a debugger

- no need to add print statements

When I write Dark, I can debug in seconds. When I work on the Dark implementation (F# or ReScript), I spend at least minutes on each bug because I need to do a bunch of setup to find enough information to diagnose the error.

Re: The unreasonable effectiveness of print debugging

#65

Post by j4yav »

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.

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

Re: The unreasonable effectiveness of print debugging

#67

Post by Agingcoder »

diegocg wrote: post #60

I have never spent much time learning debuggers honestly. I'm not sure if what I want exists: I would love to have a debugger that offers a partial text editor experience, eg. it shows my code, I move the cursor to some statement, then I press some key binding and the debugger starts printing (in another window) all the state changes in that statement. Another key binding prints all the state changes in the entire fu…

Yes, it's called pernosco, and it's quite remarkable. However, it works from a recording of your program.

https://www.pernos.co

Re: The unreasonable effectiveness of print debugging

#68

Post by tester756 »

I'd say that except some heavily multithreaded cases, then print approach may be due to lack of mature tooling

I can't understand why would anyone prefer to write some print, when you can have Visual Studio's

* break point

* conditional break point

* ability to place another break points when you're already on the other

* expression evaluation at fly!!

* decent possibility to modify code at fly

I still remember case where I modified function with line with bad SQL (breakpoint after executing this SQL), added call to the same function with the same parameters after this breakpoint, let it execute again, caught the breakpoint once again and removed that call to itself

and all of that without recompiling program! it felt like magic

Re: The unreasonable effectiveness of print debugging

#69

Post by majjgepolja »

pjmlp wrote: post #39
axaxs wrote: post #37

Earlier quoted context omitted.

OK. And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. Debuggers aren't bad. But neither is printing. Knowing when to reach for them is probably a bit more key.

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?

Re: The unreasonable effectiveness of print debugging

#70

Post by varispeed »

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.
Post reply on HN