41–48 of 48 posts
The people I've met who don't use debuggers either write very uninteresting code day to day or just get by enough with their old ways of print statements, enough to not feel compelled to learn to set a debugger up. But I think that's dumb, and it's almost always worth understanding how to set up, especially in a large codebase.
I do use a lot of analysis tools like Valgrind which imho are way more useful than debuggers. Linters and static analysis tools can also be really useful for early bug detection.
I love using the debugger but now I want one where I can rewind the program a few steps if I want to. The use case I have is to go back and forth trying out different combinations of variables on a section of code. Even if I could manually set a flag to store the program state at certain portions so I can return there, that would work great. Other than that, debuggers are very superior to print statements and such. Y…
There is actually a surprising amount of reverse debugging products out there, some are listed here: http://jakob.engbloms.se/archives/1564 Would you be willing to use one of those?
I looked through there; I code in Python for work (Lua at home a lot), so I didn't see anything that seemed to be targeted towards that use case. I've also seen tools like rr that record a session, but I specifically want to be able to step back and forth while executing code. I would use anything that, at minimum, would allow me to set a "save point" like a breakpoint and then return to that save point from any breakpoint, or from paused execution if I am stepping through the code.
I think it would be easier for Python, Lua, or other dynamic, interpreted languages to do this because you could store the program state via storing the interpreter's internal state more easily.
Also, I understand side-effects would complicate this and I am willing to ignore those issues if I had a bare-bones reversible debugger for Python.
Using a debugger for async codes introduces timing bugs.
I avoid debuggers because if I can't debug something without them, said something is too complicated for me to understand now, let alone in the future. Moreover, if said something is that complicated, it is almost certainly wrong in several subtle ways. One nice property of asserts is that they keep working even when your attention is elsewhere.
How do you step through your code to understand what EXACTLY is happening to the data without a debugger?
If I don't understand what is happening to data without stepping, the code is too complicated.
If it's too complicated, I don't understand it now, won't understand it later, and it's probably wrong.
If I was working (again) in embedded systems, I might use a debugger as a substitute for print.
The people I've met who don't use debuggers either write very uninteresting code day to day or just get by enough with their old ways of print statements, enough to not feel compelled to learn to set a debugger up. But I think that's dumb, and it's almost always worth understanding how to set up, especially in a large codebase.
And now you have to set up debugging for a Scala backend, a Node application running a GraphQL server, and a React Native frontend running in an iOS simulator.
I'd have a really hard time respecting someone's choice to bet on a tool that is very difficult to troubleshoot, if there's an alternative that isn't, unless that tool is extremely better at something else.