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

81–90 of 366 posts

Re: The unreasonable effectiveness of print debugging

#81

Post by mistahenry »

rubyist5eva wrote: post #51

Print debugging is great but you'll pry the IntelliJ debugger from my cold dead hands.

Completely agree. When implementing new functionality in my Kotlin Spring Boot apps, I find the debugger crucial for fixing any exception that isn’t immediately clear. I’ll simply rerun my test with a breakpoint on the failing line, peruse the values of local variables (often spelunking deep into nested objects), and test theories with the window that lets my evaluate arbitrary expressions. Occasionally, I’ll change the value of a local variable and let the program continue to see if that value would fix the issue.

It’s a workflow that makes “Wait, why did that happen” such an easy question to answer.

Re: The unreasonable effectiveness of print debugging

#83

Post by montecarl »

CJefferson wrote: post #71
1337shadow wrote: post #42

Earlier quoted context omitted.

What Python debuggers you are talking about? have you tried the built-in CLI debugger? Just drop breakpoint() in your code and you're in. Have been using it daily for over a decade and really happy with it - it's actually one of my favorite features of the language, amongst the many super useful features that Python and its excellent stdlib have to offer.

Honestly, I didn't know that and I'll try it. Last time I had to debug I remember adding "-m pdb" (as at the start of https://docs.python.org/3/library/pdb.html , first result in Google), but for some reason that immediately threw an error instead of starting the program, so I just chucked some prints in instead.

I have mapped a key to insert "import pdb;pdb.set_trace()" in my editor. Also use it daily, and not just for debugging. It is useful when working on a new project and you just want to interrogate some object you got back from a library to see what valid operations you can do with it. Or to double check some math operations.

Re: The unreasonable effectiveness of print debugging

#84

Post by eddieh »

jhgb wrote: post #43

I had a crazy idea the other day that perhaps there could be something like "CSS for program execution traces". If you think of function identifiers as XML/HTML tags and arguments for individual function activations as element attributes, then perhaps something similar to CSS selectors but acting on the tree representation of a program's execution could trigger at certain clearly defined points during the execution a…

Sounds a lot like syntactic sugar or a DSL for symbolic breakpoints combined with conditionals. That's certainly doable.

Something like: func1(4) > func2(null) debug;

Semantically: upon func1 called with arg 4 and some descending path that calls func2 with arg null, enter the debugger

Neat idea!

Re: The unreasonable effectiveness of print debugging

#85

Post by kstrauser »

h2odragon wrote: post #27
catillac wrote: post #18

Earlier quoted context omitted.

I heard the latter sentiment earlier today, but I don’t think anyone is actually passionate about what editor others use. Opinionated sometimes.

Passion about the tools others use can be called for if you can see they're obviously struggling to meet their goals with the tools they've chosen. The hard part is, unlike a screwdriver where you can demonstrate, editors and "IT" in general are mental tools where the mindset is an invisible, nontransferable "handle" to the visible portion that everyone can see and use.

A previous manager was snarky about me using Emacs to write Python instead of “a proper tool”. Every time he’d pass my desk, “a real IDE could to that for you”. We finally had a conversation along the lines of “can it save me more time than you waste pestering me about meaningless stuff? Also, STFU until I miss a deadline for the first time since I’ve been here.”

I would not hire a carpenter who doesn’t believe in using hammers. Neither would I constantly bug a hired carpenter to use the hammer I think they should be using instead of the one they like.

Re: The unreasonable effectiveness of print debugging

#86

Post by sa1 »

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 configuration boilerplate for emacs. Emacs itself can run in both terminal and GUI mode, and doom should broadly look similar in both settings.

Re: The unreasonable effectiveness of print debugging

#87

Post by pjio »

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?

The quality of the language servers vary, but you could get a decent IDE-like experience.

Re: The unreasonable effectiveness of print debugging

#88

Post by kstrauser »

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

Amen. “What do you use for debugging prod services?” “CloudWatch.”

Re: The unreasonable effectiveness of print debugging

#89

Post by corysama »

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 because “Woo Linux!” then go straight into Google where everyone is “Woo Linux!” (I do like Linux, btw) so they are either still using GDB, or more likely have given up on it and reverted to printf. So, everything takes forever to figure out and that’s just “normal”. This was coming from a console gamedev who was shocked by the transition after moving to Google.

Meanwhile, I’ve spent a good part of the past couple decades debugging large volumes of code that I will literally only see once ever. With a good debugger, that can be done effectively because watching and even modifying the code’s behavior can be done at a glance rather than a re-compile.

I’ve also worked on a very big project that used extensive logging because they had a very bad debugger setup and productivity was in the toilet compared to every other job I’ve had. The only way I could keep productive was to take the time to break out systems into small independent programs in my own environment so that I could use a debugger on that rather the run the code where it is.

Re: The unreasonable effectiveness of print debugging

#90

Post by damagednoob »

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…

I mean there are other types of debuggers (step-through, time travel[1]) but I agree with you that I have never seen any research on which is better/faster. It seems an obvious topic so it makes me suspect that it comes down to individual style.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

Post reply on HN