For those doing print debugging in python see the screenshots here https://github.com/likianta/lk-logger
I assume it is not known given it only has a few stars. Adds source location to print and exception outputs.
Don’t look down on print debugging
111–120 of 164 posts
Re: Don’t look down on print debugging
#112While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…
I’ve definitely seen an undercurrent of “I don’t need the crutch of a debugger” sort of attitudes online over the years, never really made sense to me. It can be painful pairing with someone who keeps adding print statements one at a time and repeating the 15 step process to get to them when they could have put in a breakpoint right out of the gate. I still print stuff plenty, but when the source of an issue is not i…
I wouldn't categorize debuggers as a crutch, for "lazy minds", or anything like that. Everyone should use the tools they feel most productive with.
However, at least personally, I've also felt that there was a lot of truth to that Ken Thompson quote. Something along the lines of: "when your program has a bug, the first thing you should do is turn off the computer and think deeply."
Basically, a bug when where your mental model of the code has diverged from what you've actually written. I think about the symptoms I'm observing, and I try to reason about where in the code it could happen and what it could be.
The suggestion in the parent comment that I'm just too stupid to look into or learn about debuggers is so condescending and just plain wrong. I've looked into them, I know how to use them, I can use them when I want to. I simply tend not to, because they don't solve any problem that I have.
Also, the implication that I don't use completely unrelated tools like profilers is equally asinine. Debuggers and profilers are two completely different tools that solve completely different problems. I use profilers almost every day of my career because it solves an actual problem that I have.
Re: Don’t look down on print debugging
#113While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…
I very agree with this view. Print debugging is still useful in some cases, for example in game programming where the state of a lot of objects change rapidly and debugging a single update isn't enough to reproduce the situation.
Re: Don’t look down on print debugging
#114My only complaint about print debugging is the sheer volume of commented out console.log statements I see across code bases. Or worse, not commented out and happily logging away on prod. Seriously, leave your console open as you browse around — you’ll be astounded by the amount of debug output just rolling along on production. Delete your debug cruft!
I have a perfect solution for this, that works for me at least. Adding a `..` to the end of a variable triggers a macro that changes `val` into something like `print("val:", val) // FIXME: REMOVE`. Then a pre-commit hook makes sure I am unable to commit lines matching this pattern.
That could work, but there is a problem with this approach (the last part of it):
Not all projects use git, but the ones that do:
It is possible to set up a global pre-commit hook in git, but it requires some manual configuration because git does not natively support global hooks out of the box. By default, hooks are local to each repository and reside in the .git/hooks directory.
You could do:
git config --global core.hooksPath ~/.git-hooks
At least you can combine global and local hooks by modifying your global hook scripts to manually invoke the local hooks.
Re: Don’t look down on print debugging
#115While print-type debugging has a place, the reason there are a lot of articles dissuading the practice is the observed reality that people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. This isn't just an assumption I'm making: years of being in developer leadership roles, and then watching a couple of my own sons learning the practice, has shown me in hund…
I find that which tools I need changes immensely depending on what kinds of projects I'm working on. When debugging parsers for my toy programming languages print debugging is less helpful and I make heavy use of all the debug tools you mention. The same goes for most types of business logic—writing a test and stepping through it in the debugger is usually the way to go. But when troubleshooting odd behavior in a com…
This. Last week at work I've been investigating an odd flaky behavior. No way to do it with debugger. Add logging to every suspicious place and run all 40 containers of our distributed monolith in local docker. Turned out there is a race condition between consumption of Kafka messages and REST calls.
Re: Don’t look down on print debugging
#116Print debugging is great if you are debugging multiple processes, maybe even multiple computers at the same time. But it can also be a bane as print debugging is directly influencing run of your program, so it can temporary fix existing or create new bugs by its sheer presence.
Re: Don’t look down on print debugging
#117Print debugging is the tool most people reach for when they can, but its biggest problem is that you have to change the source code to add the printfs. This is impractical in many circumstances; it generally only works on your local machine. In particular, you can't do that in production environments, and that's where the most interesting debugging happens. Similarly, traditional debuggers are not available in produc…
How is side-eye different from dtrace?
Side-Eye is massively inspired by DTrace in some of its raw capabilities and the basic idea of dynamic instrumentation. Beyond that, they're very different. At a low level, DTrace is primarily geared towards debugging the kernel, whereas Side-Eye is about userspace. DTrace's support for the DWARF debug information format used on linux is limited. The interaction model is different - for DTrace you write scripts to collect and process data. DTrace works at the level of one machine, whereas Side-Eye monitors processes across a fleet. In Side-Eye you interact with a web application and you collect data into a SQL database that you can analyze. Side-Eye is also a cloud service that your whole team is supposed to use together over time.
And then there are more technically superficial, but crucial, aspects related to specific programming language support. Side-Eye understands Go maps and such, and the Go runtime. It can do stuff like enumerate all the goroutines and give you a snapshot of all their stacks. We're also working on integrating with the Go execution traces collected my the Go scheduler, etc.
Re: Don’t look down on print debugging
#118Earlier quoted context omitted.
I’ve definitely seen an undercurrent of “I don’t need the crutch of a debugger” sort of attitudes online over the years, never really made sense to me. It can be painful pairing with someone who keeps adding print statements one at a time and repeating the 15 step process to get to them when they could have put in a breakpoint right out of the gate. I still print stuff plenty, but when the source of an issue is not i…
I wouldn't categorize debuggers as a crutch, for "lazy minds", or anything like that. Everyone should use the tools they feel most productive with. However, at least personally, I've also felt that there was a lot of truth to that Ken Thompson quote. Something along the lines of: "when your program has a bug, the first thing you should do is turn off the computer and think deeply." Basically, a bug when where your me…
"The suggestion in the parent comment that I'm just too stupid"
If your insecurity leads you to misrepresent what someone actually said so disgustingly, maybe Hacker News isn't for you.
Re: Don’t look down on print debugging
#119I have long relied on a print-debug function I wrote for python called dump(). You do dump(foo) and it will print out "foo: value". Where the variable name "foo" is magically pulled out of the source code and "value" is a json-dump of its value. So dicts look pretty, like the example below.
This is similar to the "debug f-strings" introduced in python 3.8: print(f"{foo=}"). But it's much easier to type dump(foo) and you get prettier output for complex types.
x = 3
foo = dict(bar=1, baz=dict(hello="world"))
dump(x)
dump(foo)
# prints...
x: 3
foo:
{
"bar": 1,
"baz": {
"hello": "world"
}
}
Re: Don’t look down on print debugging
#120Earlier quoted context omitted.
Speaking from my own experience I'm not so sure that printf debuggers just have "incomplete knowledge [...] of modern debugging tools". I use printf (or the file-based equivalent, log files) quite a lot, but nobody can accuse me of not knowing good debugging environments. Also, what's "modern" about "Walk the call stack! See the parameters and values, add watches, set conditional breakpoints"? Those are all things we…
> So please refrain from calling people with different preferences uneducated. OP said: > … people who lean on print debugging often have incomplete knowledge of the immense power of modern debugging tools. I am educated. I have a metric fuckton of incomplete knowledge in all areas of life. You’re poking at something that wasn’t said.
I've never been able to successfully debug anything with a conditional breakpoint or watch, in spite of knowing about these things and trying.
(Well, other than my own conditional breakpoint features built into the code, doing things like programmatically trigger a breakpoint whenever an object with a specific address (that being settable in the debugger interactively) passes certain points in the garbage collector.)