4 ms·

Discussing your feelings towards debuggers would produce a better discussion if you explained what complexity you find lacking? Nowadays they are incredibly com

Discussing your feelings towards debuggers would produce a better discussion if you explained what complexity you find lacking? Nowadays they are incredibly complex pieces of software (e.g., https://rr-project.org https://rr-project.org) if you take the time to learn how to apply what they offer to the kind of software you write. Simple things that people like reasoning about and visualizing with printf() statements can be done in a debugger more easily after using your brain and logic to think about what the issue might be. Think a value got assigned a value it should't have? You add log statements, rebuild, relink, reproduce; or, you could just set a hardware watchpoint to print the backtrace whenever it changes. In my experience people don't reach for the debugger way of doing it simply because it might not be needed all the time and the syntax is forgotten. Diving into `man` or docs is harder than printf(). Use those skills more regularly and/or make a cheatsheet, macros, etc. and it is less of a problem. Debuggers must be used in certain situations. Personally, the canonical example I use is tracking down compiler bugs. I and colleagues have been hit with a number and it would be utterly hopeless to attempt to reason about what is going on without a debugger. (One particular past case that stands out was the compiler, under very certain circumstances, not restoring a register that it was obligated to restore when emitting a catch block. Isolating the root cause and generating a reduced example was loads of fun /s, would not recommend.) Then there's kernels, runtime engines with JIT, diagnosing unreproducible problems in situ where the executable can't be replaced or restarted, and the list goes on...

jcelerier 7y ago
> Simple things that people like reasoning about and visualizing with printf() statements can be done in a debugger more easily after using your brain and logic to think about what the issue might be. A big problem that tends to make me sometimes not use debuggers, is that for relatively large software split in many DLLs, adding a printf & rebuilding takes a few seconds, while loading it in gdb or lldb is sometimes north of a minute (or, from my experience with MSVC's "symbol loading", sometimes fifteen minutes).
solinent 7y ago
It's more of just a joke--sometimes a simpler solution can do much more than a complex one. Complex solutions aren't necessitated, in fact, I actively avoid them in my product. It's also not for lack of use, I've developed software for more than fifteen years, and I've always had access to some sort of debugger, and I've always used them, just very rarely. >You add log statements, rebuild, relink, reproduce; or, you could just set a hardware watchpoint to print the backtrace whenever it changes. In my experience people don't reach for the debugger way of doing it simply because it might not be needed all the time and the syntax is forgotten. Diving into `man` or docs is harder than printf(). Use those skills more regularly and/or make a cheatsheet, macros, etc. and it is less of a problem. Hardware watch points work horribly for objects, I have to create and maintain views for all the practical objects I use, unless they're very popular libraries like OpenCV. Ultimately, these views could simply be printf or cout statements, maintained with a common function or method defined on all objects. These log statements typically happen right near assert statements, so they can be maintained along with the code. I'll usually use something more sophisticated than simple printf, and I'll have many different types of logs for common debugging cases. They can be enabled or disabled at runtime, so no recompilation needed. They give me access to all the state I could possibly require, and they get committed to the code base. I've had coworkers spend entire days in debuggers (often in groups), where a simple step back and a simple log easily solves the problem. I would use hardware watchpoints if they were standardized across debuggers, but they don't have all the features I need even in the best debuggers, and then I'm still useless on other platforms. Also, I usually need the program to run at near real-time otherwise the bug may not reproduce itself. edit: I should add I do use some of the more advanced debugger features in those rare cases. So debuggers are still necessary, just not in the day-to-day. I should also say I've also worked in environments where the software has to be pretty much bug-free, where small bugs may not be immediately noticeable. So there's a lot of planning, design, even non-formal proofs of correctness happening. If it's allowable for your software to have some bugs, maybe you can take a shortcut with a debugger. Finally, I'm not against all tooling, just debuggers. I use visual profilers all the time.

jcelerier 7y ago

> Simple things that people like reasoning about and visualizing with printf() statements can be done in a debugger more easily after using your brain and logic to think about what the issue might be. A big problem that tends to make me sometimes not use debuggers, is that for relatively large software split in many DLLs, adding a printf & rebuilding takes a few seconds, while loading it in gdb or lldb is sometimes north of a minute (or, from my experience with MSVC's "symbol loading", sometimes fifteen minutes).

solinent 7y ago

It's more of just a joke--sometimes a simpler solution can do much more than a complex one. Complex solutions aren't necessitated, in fact, I actively avoid them in my product. It's also not for lack of use, I've developed software for more than fifteen years, and I've always had access to some sort of debugger, and I've always used them, just very rarely. >You add log statements, rebuild, relink, reproduce; or, you could just set a hardware watchpoint to print the backtrace whenever it changes. In my experience people don't reach for the debugger way of doing it simply because it might not be needed all the time and the syntax is forgotten. Diving into `man` or docs is harder than printf(). Use those skills more regularly and/or make a cheatsheet, macros, etc. and it is less of a problem. Hardware watch points work horribly for objects, I have to create and maintain views for all the practical objects I use, unless they're very popular libraries like OpenCV. Ultimately, these views could simply be printf or cout statements, maintained with a common function or method defined on all objects. These log statements typically happen right near assert statements, so they can be maintained along with the code. I'll usually use something more sophisticated than simple printf, and I'll have many different types of logs for common debugging cases. They can be enabled or disabled at runtime, so no recompilation needed. They give me access to all the state I could possibly require, and they get committed to the code base. I've had coworkers spend entire days in debuggers (often in groups), where a simple step back and a simple log easily solves the problem. I would use hardware watchpoints if they were standardized across debuggers, but they don't have all the features I need even in the best debuggers, and then I'm still useless on other platforms. Also, I usually need the program to run at near real-time otherwise the bug may not reproduce itself. edit: I should add I do use some of the more advanced debugger features in those rare cases. So debuggers are still necessary, just not in the day-to-day. I should also say I've also worked in environments where the software has to be pretty much bug-free, where small bugs may not be immediately noticeable. So there's a lot of planning, design, even non-formal proofs of correctness happening. If it's allowable for your software to have some bugs, maybe you can take a shortcut with a debugger. Finally, I'm not against all tooling, just debuggers. I use visual profilers all the time.