Hacker News Reader

Comment by zwnow | Hacker News Reader

In a few years of my career now I never had to use a debugger or CI. Console debugging is good enough usually. On version control I agree.

View on HN

The conclusion I draw from this is that some debuggers are so bad it's not delivering value over "print debugging".

But perhaps it's a lack of knowing what a debugger can deliver.

A debugger gives you the ability to immediately dive in and instantly inspect the complete stack trace, all the values on the stack, all the values of local variables, etc. Without restarting the program or calling out specifically what you're going to want to inspect ahead of time.

A debugger will "pause the world" and let you see all the parallel stacks.

A debugger will let you set conditional breakpoints. If you need to debug the conditions for when a variable gets set to a particular value, a conditional breakpoint on the variable set to break when it's set to that particular value makes that a doddle.

A debugger will let you enumerate collections and re-write values on the fly.

A debugger will let you break on exceptions, even ones normally caught and handled.

A debugger can launch and attach itself.

All of that is a massive force-multiplier and time-saver, which print debugging doesn't deliver.

A debugger doesn't show you the evolution of your program over time. A few well placed prints give you that.

I use my debugger often, but sometimes you need to track the value of something over time (say, over 1000 iterations) and a debugger can't show you that.

So prints are still relevant. Debugger are more for "needle-in-haystack" stuff I think.

A debugger that could record the execution over time (and query that execution), that would be great. I know there are some, but are there for python for example ?

> I know there are some

Do you mind providing examples? I’m not sure what I would search to find that and I’m interested in the idea.

I've never used it but sounds like https://rr-project.org/

A debugger will also allow you to step through library and framework code where you can't usually go and place print statements.

I've spent some quality time with debuggers but have come to the conclusion that it is a seductive way to spend time that doesn't necessarily get me there any faster than with printf or equivalent.

Admittedly, I mostly develop with sbcl and slime, so the judiciously place 'break' statement brings you to a stack trace.

Also with sbcl/slime, you can do ESC-. on a function and go to the actual source, even deep within the core of sbcl itself.

Nonetheless, I mostly depend on logging statements and print statements. When I need to go to python, print statements give most of what I need.

I don't know you or your work. But I know (senior) developers that don't use a debugger and I've often noticed that when fixing a bug, they don't build a full mental model of what really goes wrong and often just fix the symptoms. Think "that shouldn't be null, we need a null check here" instead of "why is this value null? we should check here, but also make sure the caller works correctly."

You can have that kind of thinking or mental model with and without debuggers though. I do not see how it is relevant to debuggers.

On the other hand, though this is n = 1 and from 2000 (and it is classic Linus):

Linus Torvalds:

> I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program.

> I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing.

> Oh. And sure, when things crash and you fsck and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger.

> I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_.

https://lkml.org/lkml/2000/9/6/65

And I agree. At least for me, print debugging goes a long way, and I'm already invested in building mental models about code. I think using a proper debugger has to be the last resort, because nothing else works and it's time to get into the ugly details. Two valuable avenues for producing good code are formal verification (and its ilk, such as specification) and horse sense/common sense, which combine to say that we should have rigorous mental models that impose on our code. That's the primary objective, to me. The use of tools such as debuggers is secondary, and in my experience, largely neutral or harmful. There's the classic caveat of "if your goal is to ship code fast, then this isn't practical", which is fair, but I have some things to say about shucking off that culture.

Debugger for me is more about inspection than actual debugging, especially when dealing with a complex systems. It's possible to just use a printf, but the debugger gives more information. It's rare that I need to do stepping. I mostly just want to see the stack trace and the state of the program. One of the nice thing about Common Lisp and Smalltalk is to be able to do this any single point.

Do this at any point and then change the state of the program.

I do not know what you work on, but debugging is indispensable for certain workloads. Print debugging doesn’t come close to setting up a breakpoint and inspecting every single variable in the stack with a good interface. You don’t even have to select what to print and where, anything can be printed anywhere in two clicks. A UI like the debuggers in Jetbrains IDEs provides smart rendering for all types so that for example map or list elements can be collapsed. The entire call stack is neatly organized and searchable too. It saves hours, creates less friction and also greatly enhances exploratory debugging, where you don’t even know where in the call stack your problem might be. I’d feel very hindered and unhappy if I didn’t have access to a good debugger.

I dont know, sounds more like a design issue to me, if your app requires this amount of information to get debugged properly.

Really? Just try debugging a Dijkstra like algorithm and then talk about design issues.

My bread and butter at one point was working on various pathfinding and numerical computing problems, and I'm primarily a print statement debugger. The time evolution of the system is usually the most important signal for debugging these types of problems, and is easy to dump.

That's not to say I don't also use debuggers when necessary, I just reserve those for very hairy problems that can't be solved any other way, e.g. stepping into dependencies. Let's not forget that debuggers have their limitations too, e.g. release build GC optimization (or indeed any release-only bug), and any init process where you have to attach the debugger after the startup, fundamentally cannot be debugged using debuggers.

You seem to have worked on small simple projects thus far then.

Or on embedded systems

Debuggers are important tool, but not all debugger are good and not all problems require debugger. That's why I wrote a simple tool, which given a list of methods and classes will printf to log every invocation and exit of selected functions (via java reflection and function rewriting). It was much better than a normal debugger at finding actual flow of data in very complex multi-program system, so essentially machinegun-printf saved the day.

I was the same until I started working on a Go server. It helps immensely when I want to know the value of objects say when a request is handled and how that flows.

There are different categories of tools.

You can design a house on paper, but you need e.g. mallets and wheelbarrows to build it; you can design software with "tools for thought", more or less computerized, but you need the automation offered by CI, version control etc. to handle the more concrete aspects properly.

CI is really nice with multiple platforms or multiple people. Solo projects for Linux, I never bother

It means that you don't write anything complex.

Which is most probably the majority of us, computer programmers.

Reply on news.ycombinator.com