The unreasonable effectiveness of print debugging • Hacker News Board

Re: The unreasonable effectiveness of print debugging

#341

Post by wodny » Sun, Apr 25, 2021, 11:03 AM UTC

humbleMouse wrote: post #235

wodny wrote: post #209

Print debugging is not that different from setting logging level to DEBUG and those logging calls should already be there in code and give meaningful insight so I don't get printing being often ridiculed. For over ten years of commercial work I used a debugger only a couple of times and in most cases it was against someone else's code, usually when things were completely broken and I needed to get backtraces from mul…

You’ve only used a debugger a couple of times in 10 years? Yikes.

Why "yikes"? Note that doesn't mean I don't know how to use eg. gdb outside or inside IDE. My debugging record proves my methods are quite efficient but there's something even more important - there are ways to systematically avoid the need to use a debugger by keeping projects' sanity level high.

Re: The unreasonable effectiveness of print debugging

#342

Post by [deleted] » Sun, Apr 25, 2021, 11:23 AM UTC

mumblemumble wrote: post #257

dmitryminkovsky wrote: post #242

Whenever this comes up, I think of this quote from The Practice of Programming by Brian W. Kernighan and Rob Pike [0]: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding o…

There's a part of me that wants to say that that opinion has to be taken with a grain of salt and a lump of paying attention to who is offering it. Circa 1999, one would assume that Brian Kernighan and Rob Pike are largely drawing experience from working with C, which is a relatively verbose language. Single stepping through C code in a debugger is indeed a laborious process. If you read accounts from Smalltalk devel…

[deleted]

Re: The unreasonable effectiveness of print debugging

#343

Post by nottorp » Sun, Apr 25, 2021, 12:04 PM UTC

mjevans wrote: post #271

Tade0 wrote: post #161

Earlier quoted context omitted.

Let us not forget the war to end all wars: Tabs vs spaces

Tabs are the clear winner here, since they unambiguously denote which level of indent is in use, take only one character (octet) per indent level, and can be visually adjusted on any moderately advanced editing program to an end users taste WITHOUT modifying the source code. This __wouldn't matter__ if we all just used TABS for indent level and if spaces were ignored for that: I also prefer tabs to show in a GUI code…

> unambiguously

Multi people teams (or just one person editing on different platforms depending on need) using different editors and with different preferences would like to have a word with you here.

Re: The unreasonable effectiveness of print debugging

#344

Post by nottorp » Sun, Apr 25, 2021, 12:07 PM UTC

adam_arthur wrote: post #144

I've never understood print debugging, at least in a web dev/nodejs context. I don't begrudge people having their own approach to things, but almost universally when I see people use print debugging they seem to take quite a bit longer than just break pointing at the problem area. If your code is in an unexpected state, it's much easier to hit a breakpoint, examine local values, and then backstep through the call sta…

> almost universally when I see people use print debugging they seem to take quite a bit longer than just break pointing at the problem area.

Could it be... because they don't know where the problem area is yet? Which is what the original article and most comments in favor of print debugging say.

Re: The unreasonable effectiveness of print debugging

#345

Post by nottorp » Sun, Apr 25, 2021, 12:10 PM UTC

corysama wrote: post #89

In my experience, people who downplay debuggers don’t have the option to use effective debuggers. Debugging C++ and especially C# in Visual Studio is wonderful. Debugging Java in Eclipse can be great. Meanwhile GDB and most other language debuggers are painful and every IDE integration I’ve seen of them has been horribly unreliable. I’ve heard there’s a culture in parts of Google where kids go through uni using GDB b…

> Debugging C++ and especially C# in Visual Studio is wonderful.

... and it's still a royal pain to get your program to display stuff on some text console when you want those printfs.

Also, you have to use Windows. I'd rather avoid that if i can.

Re: The unreasonable effectiveness of print debugging

#346

Post by CJefferson » Sun, Apr 25, 2021, 12:19 PM UTC

nomel wrote: post #306

formerly_proven wrote: post #125

Earlier quoted context omitted.

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.

Reading through the majority of this comment section, I get the impression that those who like print statements find value because they aren’t proficient with modern debuggers, rather than they find print statement valuable even though they’re proficient with debuggers.

I agree, but my feeling is, if one person is bad at using debuggers it is their fault. If (as it seems to me) most developers are bad at using debuggers, then it's probably to debugger's (and associated tooling's) fault.

Re: The unreasonable effectiveness of print debugging

#347

Post by corty » Sun, Apr 25, 2021, 12:23 PM UTC

Too wrote: post #319

corty wrote: post #132

Earlier quoted context omitted.

Also, in almost all languages debuggers are an afterthought. Take e.g. the situation with Golang, Haskell or Python. Either there is no useful debugger or there is one, but it came late and still cannot debug everything the language does.

Not sure what situation you are talking about. Debugging Python is as easy as right-clicking a file in Pycharm and pressing debug. Why care if it was an afterthought when it for the past decade has worked perfectly.

I care. That it has worked for the last decade only means that Python was without a working debugger for 2/3 of its existence. 1/3 of which I had to suffer from it.

Also, pycharm isn't really what I would call a proper debugger yet, attaching remote running processes for example just doesn't work reliably yet and is very new anyways. Debugging embedded targets just doesn't work. Multithreading is iffy (but that's unfortunately normal in Python).

Re: The unreasonable effectiveness of print debugging

#348

Post by bakatubas » Sun, Apr 25, 2021, 1:08 PM UTC

toast0 wrote: post #160

klyrs wrote: post #121

Earlier quoted context omitted.

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

Print debugging is essential in distributed systems. Sitting in the debugger waiting for human input often leads to timeouts and not covering the case you want. Of course, sometimes adding the prints, or even just collecting values to be printed later also changes execution flow, but like do the best you can.

All the more reason for folks to spend more time using the debugger; for instance, break points are only one feature.

Setting up remote debugging I’ll agree is more difficult than a local application, but each remote machine can automatically run startup commands and not require user input; commands can be run at particular places too (to print output etc) with conditional trace points, all while not impacting the code itself.

Main point is that folks don’t spend enough time learning the debugger, as print statements are easier. But using the debugger is a better practice in my opinion in the case where print statements are added just for a quick test, then removed.

Re: The unreasonable effectiveness of print debugging

#349

Post by j4yav » Sun, Apr 25, 2021, 2:10 PM UTC

fao_ wrote: post #336

j4yav wrote: post #65

Earlier quoted context omitted.

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

I'm not sure what's difficult about (map! :n "ff" #'save-buffer) ; Save (map! :n "fq" #'kill-current-buffer) ; Quit a buffer or (defun my/org-buffer-check () "Check that we are in org-directory, and the buffer name is in that directory" (and (string= org-directory default-directory) (seq-contains (directory-files org-directory nil) (buffer-name) 'string=))) the latter being easily represented as: function my/org-buff…

Sorry but that is not clear or obvious at all to me.

Re: The unreasonable effectiveness of print debugging

#350

Post by travisjungroth » Sun, Apr 25, 2021, 2:20 PM UTC

Swizec wrote: post #167

travisjungroth wrote: post #154

Earlier quoted context omitted.

I think this is the standard algorithm and it's absolutely terrible. People poke at things, which ends up giving a linear search across a possibly huge system. Even if the "guess" is intelligent, it's not like you can trust it. If you actually fully understood the system, you would know what's wrong and you wouldn't be debugging. Do a bisect instead. The complexity is O(log n). It's probably slower than if you guess…

Your algorithm is for creating programs or adding new features. Not reslly for debugging already broken stuff. I would agree that hoing from less to more complexity is a great heuristic for making those guesses on what to check.

This is normally described as a way to write code, but it works for debugging if you can modify the system or at least give arbitrary inputs. It doesn’t really apply to “read only” debugging.