3 ms·
I think there is a level of familiarity bias that happens with debugging tools. I could probably get away with making gdb my login shell I live in it so much, a
by TheNewAndy 6y ago
I think there is a level of familiarity bias that happens with debugging tools. I could probably get away with making gdb my login shell I live in it so much, and when I find myself using Visual Studio's debugger, I find it incredibly clunky. The things people complain about for gdb (e.g. you can't see the source code for where it is executing) I don't find to be a big deal (I just jump to the correct line in my text editor). Meanwhile, using Visual Studio is a complete pain for me, for reasons that clearly don't matter to people who use Visual Studio all the time (e.g. while possible, running multiple instances of a program side by side is annoying, quickly evaluating arbitrary expressions is more painful, setting data breakpoints is needlessly complicated (do they still ask if it is C or C++?), etc.
I think it must just be one of those things where the tool you use shapes the way you work, and so then when you switch tools, but try to work in the same way, you get frustrated.
- muststopmyths 6y agoI find windbg a good middle ground between the gdb/lldb style and visual studio overload. source debugging is a minor component of GUI debuggers. Having a graphical watch window with multiple variables, looking at registers in a different window while stepping through etc. is invaluable to me. Also stuff like losing mental context because of dumping a long stack in the same window where I was just inspecting disassembly is frigging painful. But I agree about familiarity bias in most cases.