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

271–280 of 366 posts

Re: The unreasonable effectiveness of print debugging

#271

Post by mjevans »

Tade0 wrote: post #161
mekoka wrote: post #16

IDE vs Text editor. OOP vs Functional. Logger vs debugger. The holy wars that shouldn't be. Why can't we all be friends and accept that Vim is better than emacs.

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 editor at ~4 characters, but be equivalent to 8 display characters in terminal modes (I guess EM size, but when I care about those I really want a 'fixed width' font, so toss all of the complexity aside please).

Re: The unreasonable effectiveness of print debugging

#272

Post by russellendicott »

lr4444lr wrote: post #56
mekoka wrote: post #16

IDE vs Text editor. OOP vs Functional. Logger vs debugger. The holy wars that shouldn't be. Why can't we all be friends and accept that Vim is better than emacs.

How's file exploring and method/class definition lookup these days in Vim?

For the junk I write and work with Ag/Rg has been sufficient.

Re: The unreasonable effectiveness of print debugging

#274

Post by dnautics »

xyzzy123 wrote: post #260
mumblemumble wrote: post #257

Earlier quoted context omitted.

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…

Linus used to be against kernel debugging for the longest time. The core of his position (as I understand it) was that regularly needing a debugger is a sign that your software has "gotten away from you". You've let the software get to a state where it cannot easily be understood from the architecture and program text alone. I do think debuggers can be useful when building up comprehension - particularly of other peo…

Once you traipse into concurrency land, too, debuggers get much more tricky. You now have to consider the state of the thread you are in, plus all the others.

Re: The unreasonable effectiveness of print debugging

#275

Post by prewett »

lainga wrote: post #107
Swizec wrote: post #91

Earlier quoted context omitted.

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…

I might suggest a few of the adventures of Sherlock Holmes.

So, having conveniently written a monograph on the exact topic that provides extra information, the extraordinary ability to know exactly which minor features of the situation are contradictory, and access to knowledge unavailable to the reader?

Re: The unreasonable effectiveness of print debugging

#276

Post by mason55 »

dnautics wrote: post #274
xyzzy123 wrote: post #260

Earlier quoted context omitted.

Linus used to be against kernel debugging for the longest time. The core of his position (as I understand it) was that regularly needing a debugger is a sign that your software has "gotten away from you". You've let the software get to a state where it cannot easily be understood from the architecture and program text alone. I do think debuggers can be useful when building up comprehension - particularly of other peo…

Once you traipse into concurrency land, too, debuggers get much more tricky. You now have to consider the state of the thread you are in, plus all the others.

And whether the act of debugging has changed how everything works

Re: The unreasonable effectiveness of print debugging

#277

Post by indymike »

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?!

Emacs (Doom Emacs included) can run in a terminal session or in a GUI.

Re: The unreasonable effectiveness of print debugging

#278

Post by nyczomg »

zamfi wrote: post #166
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…

Print debugging always works, but also: it lets the programmer customize their view of the program’s (very, very large) hidden state in any way imaginable. Step debuggers are the “no-code” equivalent: extremely useful for the purposes for which they were designed—and often the better choice there—but inherently limited. Geoff’s not wrong in invoking Bret Victor’s Learnable Programming argument that being able to trac…

"Print debugging always works..."

Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteristics that now doesn't deadlock where it used to deadlock because you slowed down one of the threads massively as it spends time it used to not spend logging stuff.

"Step debuggers, on the other hand, are essentially “no-code” debuggers — extremely useful for the purpose for which they are designed, still useful for adjacent purposes, and a great place to start if you know the tool well, but ultimately not as powerful if your needs exceed their capacities."

I guess you'd think this if you thought print debugging "always works". But I promise you it is equally (if not easier) to exceed the capabilities of print statements in some scenarios.

Re: The unreasonable effectiveness of print debugging

#279

Post by bluGill »

nyczomg wrote: post #278
zamfi wrote: post #166

Earlier quoted context omitted.

Print debugging always works, but also: it lets the programmer customize their view of the program’s (very, very large) hidden state in any way imaginable. Step debuggers are the “no-code” equivalent: extremely useful for the purposes for which they were designed—and often the better choice there—but inherently limited. Geoff’s not wrong in invoking Bret Victor’s Learnable Programming argument that being able to trac…

"Print debugging always works..." Nope, print debugging does not always work. Please stop saying that. Sure, it's often useful and often works. But go try to debug a race condition, or bug in some locking mechanism with print statements. I'll wait as you add a bunch of print statements, and then learn the harsh lesson that you are now debugging a completely different program with very different performance characteri…

Debuggers don't work in the situation you described either.

Re: The unreasonable effectiveness of print debugging

#280

Post by Igelau »

zamfi wrote: post #258
jayd16 wrote: post #208

Earlier quoted context omitted.

This is a lot of words but I wonder if you've ever worked with a debugger with watchable variables or immediate mode code execution. I find it odd you say print debugging is more flexible.

I have. What information exactly can you get from a debugger with watchable variables and immediate mode code execution, that you can't get from print? I'm not making the argument that people shouldn't use debuggers -- obviously if there's a good one that does what you need, it'd be silly not to use it. And good debuggers are great. But what happens when you're working on a distributed system? Or multiple processes o…

> What information exactly can you get from a debugger with watchable variables and immediate mode code execution, that you can't get from print?

If you have some completely undocumented object oriented code with tons of relationships, peeling the state apart in a debugger is a good way to get an idea of what you even have that might be worth printing.

Post reply on HN