6 ms·

What was it so painful about it you had to highlight gdb specifically? I'm just starting out with it, so far it seems a lot more flexible than its visual counte

by pestaa 15y ago

What was it so painful about it you had to highlight gdb specifically? I'm just starting out with it, so far it seems a lot more flexible than its visual counterparts do.

jrockway 15y ago
Agreed. I've spent a lot of time in gdb and have never had any problems with it. I think he probably wants some GUI where the watches automatically update, or where -O3'd code magically executes as though the compiler didn't do any optimizations on it.
- burgerbrain 15y ago
  "r where -O3'd code magically executes as though the compiler didn't do any optimizations on it." That seems like one hell of an invitation for Heisenbugs. Are there debuggers that actually do that?
  - swaits 15y ago
    Nope.
  - kragen 15y ago
    Google [dynamic deoptimization].
roel_v 15y ago
Its lack of easily seeing the surrounding code you're stepping through. Its cumbersome ways of use (having to type commands for inspecting variables rather than just being able to point at them). Its difficulty of learning it. And all of that for no benefit - I spend hours learning vim too, but at least there I got flexibility and a supremely powerful editor in return; but there is nothing gdb can do that the Visual Studio debugger can't. And there you just set a breakpoint and press run, while for gdb it takes you a day just to get integration with your editor set up the first time. I'm not sure what you mean with 'flexible' - a debugger is by its very nature interactive, so the typical advantages of text-based tools don't apply. But of course YMMV etc.
- scott_s 15y ago
  It depends on your mental model and how comfortable you are with the commands. It's similar to the disconnect between navigating a file system on the command line and through a GUI.
- ori_b 15y ago
  gdb -tui
- jrockway 15y ago
  gdb can "list" and "where", which gives you the lexical and dynamic contexts respectively. Here come the downvotes... but if you don't know the code running in the debugger well enough to remember the details, well, you've found your bug. Read and understand your code very carefully before you waste your time single-stepping through it. (This is the biggest problem I see with developers that use IDEs -- they forget that they have a brain, and that your brain is always going to be faster than clicking shit in Eclipse.)
  - roel_v 15y ago
    Oh great, another internet toughman boasting about how all those IDE-using pussies are just stupid and how Real Programming should be left to Real Programmers (queue story of Mel here somewhere). rollseyes When you have to type commands to see what you would otherwise see immediately, how is that not a usability deficiency? GDB fans just have Stockholm syndrome. And if you think there is anyone on this world who has a complete mental model of each line of code in a 10k-line project, let alone a 100k or 1m one, you're insane. I'm not talking about debugging a 15-line function, But even then, single-stepping through a function of that size doesn't even cost extra time when you use proper tools (and not that POS gdb), so 'waste your time' doesn't even apply there. Debuggers have a bad rep with some crowds because of the damage gdb did - people think that that's how debugger work and can only work. Navel-gazing at its worst.
    - jrockway 15y ago
      Oh great, another internet toughman boasting about how all those IDE-using pussies are just stupid and how Real Programming should be left to Real Programmers (queue story of Mel here somewhere). rollseyes If you want to talk like this, go back to Reddit. I'm not an Internet toughman, I'm describing the motivations behind the interface of gdb. Turns out that just because someone disagrees with you doesn't mean they're dumber than you. In this case, I think it's worth listening to me because I've used pretty much every development tool imaginable to write hundreds of thousands of lines of code. I may know what I'm talking about! Shocking! When you have to type commands to see what you would otherwise see immediately, how is that not a usability deficiency? GDB fans just have Stockholm syndrome. Information overload is just as bad as too little information. GDB lets you see what you need to see when you need to see it. It doesn't guess what you want it to do; you tell it. You're the brain and it's the computer. And, it hooks into your text editor if you want that little => next to the line of code GDB is on. I've personally never found this to be useful. (As I mention in a comment above, it's rare for modern compilers to produce code that runs top-to-bottom exactly as you've typed it anyway. The source code is an explanation of the sort of steps you want the computer to take, but it's not an exact model of what the comptuer's going to do. Saying "we're now running this line of code" can be very misleading.) And if you think there is anyone on this world who has a complete mental model of each line of code in a 10k-line project, let alone a 100k or 1m one, you're insane. I'm not talking about debugging a 15-line function. This is just plain wrong. The debugger is the wrong tool for analyzing a bug that persists over 10k lines of code. The key to debugging is to reduce the scope of the problem, and the way to do that is by not tightly-coupling large chunks of code. If you have a bug that requires a mental model of 10k-1m lines of code, unit tests and refactoring is the tool you need to be using. But, with that in mind, 10k lines is not that much to keep in one's memory. I maintain cperl-mode.el, which is 10k lines of elisp that I did not write. I haven't touched it for months, but I still know where the important parts are and how they interact. Reading is one of the most important skills a programmer can have. If you can't remember what you've read, you need to slow down. Lack of understanding causes bugs. single-stepping through a function of that size doesn't even cost extra time when you use proper tools (and not that POS gdb), so 'waste your time' doesn't even apply there Yes it does. Single-stepping requires a round-trip between the computer and your brain for every line of code. When your IDE jumps you to a new file because you stepped into a function, your brain has to context-switch and read the surrounding code. All in all, it's a slow and complicated operation compared to the normal process of running your unit tests and scanning the logs if there is a failure. That case is fast because most parts are done by the computer; it just gives you a few pieces of information that you can use to analyze, tweak, and re-run. And you can drink some coffee while the computer does most of the work! A debugger is for a very special case where unit tests cannot find bugs, or the effort to write these test would be too high. A good example is examining a core dump from a production process. You load it up in your debugger and can inspect the program state in great detail. You see that the current call frame is 0x626f6f66. That looks like the text "foob", which seems like it might have come from some text your program was working with, "the foobar chronicles". But you're using bounds-checking for your string operations, so why the bug? Use the debugger to inspect some local in-memory state, like the "len" parameter to strlcpy. It's 2938473873! Must be an integer overflow somewhere. The key here is that everything we did was interactive and required human thought at each step. We didn't know what the problem was, so we asked the debugger for some data. Then we thought about it for a while, came up with a theory to test, and asked the debugger for more information to prove or disprove our theory. After repeating this a few times, we came to the conclusion that we are doing an addition wrong in the foo function, and that's making the program segfault. With that in mind, we switch back to our text editor, write a test for the length-calculation math, and then fix the math. We shouldn't need a trip to the debugger for a while, because we use the debugger to collect information in odd cases, not to watch our program run normally. So anyway, I guess my hangup with the graphical IDE-based debuggers is "why". Why are you writing code that needs to be single-stepped regularly? Why is your codebase so messy that you can't understand it? Why is your time so worthless to you that you are doing the computer's work for it, instead of the other way around? A debugger is a tool to use for investigating weird things, not something you should bust out everyday. Debuggers have a bad rep with some crowds because of the damage gdb did - people think that that's how debugger work and can only work. Navel-gazing at its worst. A lot of insults, but not a lot of information. If you're so sure that Visual Studio's debugger has solved all of programming's problems, why not share a concrete example of how you use it? Your post adds nothing to the conversation and makes people wish your computer would punch you in the face.

by pestaa 15y ago

What was it so painful about it you had to highlight gdb specifically? I'm just starting out with it, so far it seems a lot more flexible than its visual counterparts do.

jrockway 15y ago

Agreed. I've spent a lot of time in gdb and have never had any problems with it. I think he probably wants some GUI where the watches automatically update, or where -O3'd code magically executes as though the compiler didn't do any optimizations on it.

burgerbrain 15y ago
"r where -O3'd code magically executes as though the compiler didn't do any optimizations on it." That seems like one hell of an invitation for Heisenbugs. Are there debuggers that actually do that?
- swaits 15y ago
  Nope.
- kragen 15y ago
  Google [dynamic deoptimization].

roel_v 15y ago

Its lack of easily seeing the surrounding code you're stepping through. Its cumbersome ways of use (having to type commands for inspecting variables rather than just being able to point at them). Its difficulty of learning it. And all of that for no benefit - I spend hours learning vim too, but at least there I got flexibility and a supremely powerful editor in return; but there is nothing gdb can do that the Visual Studio debugger can't. And there you just set a breakpoint and press run, while for gdb it takes you a day just to get integration with your editor set up the first time. I'm not sure what you mean with 'flexible' - a debugger is by its very nature interactive, so the typical advantages of text-based tools don't apply. But of course YMMV etc.

scott_s 15y ago
It depends on your mental model and how comfortable you are with the commands. It's similar to the disconnect between navigating a file system on the command line and through a GUI.
ori_b 15y ago
gdb -tui
jrockway 15y ago
gdb can "list" and "where", which gives you the lexical and dynamic contexts respectively. Here come the downvotes... but if you don't know the code running in the debugger well enough to remember the details, well, you've found your bug. Read and understand your code very carefully before you waste your time single-stepping through it. (This is the biggest problem I see with developers that use IDEs -- they forget that they have a brain, and that your brain is always going to be faster than clicking shit in Eclipse.)
- roel_v 15y ago
  Oh great, another internet toughman boasting about how all those IDE-using pussies are just stupid and how Real Programming should be left to Real Programmers (queue story of Mel here somewhere). rollseyes When you have to type commands to see what you would otherwise see immediately, how is that not a usability deficiency? GDB fans just have Stockholm syndrome. And if you think there is anyone on this world who has a complete mental model of each line of code in a 10k-line project, let alone a 100k or 1m one, you're insane. I'm not talking about debugging a 15-line function, But even then, single-stepping through a function of that size doesn't even cost extra time when you use proper tools (and not that POS gdb), so 'waste your time' doesn't even apply there. Debuggers have a bad rep with some crowds because of the damage gdb did - people think that that's how debugger work and can only work. Navel-gazing at its worst.
  - jrockway 15y ago
    Oh great, another internet toughman boasting about how all those IDE-using pussies are just stupid and how Real Programming should be left to Real Programmers (queue story of Mel here somewhere). rollseyes If you want to talk like this, go back to Reddit. I'm not an Internet toughman, I'm describing the motivations behind the interface of gdb. Turns out that just because someone disagrees with you doesn't mean they're dumber than you. In this case, I think it's worth listening to me because I've used pretty much every development tool imaginable to write hundreds of thousands of lines of code. I may know what I'm talking about! Shocking! When you have to type commands to see what you would otherwise see immediately, how is that not a usability deficiency? GDB fans just have Stockholm syndrome. Information overload is just as bad as too little information. GDB lets you see what you need to see when you need to see it. It doesn't guess what you want it to do; you tell it. You're the brain and it's the computer. And, it hooks into your text editor if you want that little => next to the line of code GDB is on. I've personally never found this to be useful. (As I mention in a comment above, it's rare for modern compilers to produce code that runs top-to-bottom exactly as you've typed it anyway. The source code is an explanation of the sort of steps you want the computer to take, but it's not an exact model of what the comptuer's going to do. Saying "we're now running this line of code" can be very misleading.) And if you think there is anyone on this world who has a complete mental model of each line of code in a 10k-line project, let alone a 100k or 1m one, you're insane. I'm not talking about debugging a 15-line function. This is just plain wrong. The debugger is the wrong tool for analyzing a bug that persists over 10k lines of code. The key to debugging is to reduce the scope of the problem, and the way to do that is by not tightly-coupling large chunks of code. If you have a bug that requires a mental model of 10k-1m lines of code, unit tests and refactoring is the tool you need to be using. But, with that in mind, 10k lines is not that much to keep in one's memory. I maintain cperl-mode.el, which is 10k lines of elisp that I did not write. I haven't touched it for months, but I still know where the important parts are and how they interact. Reading is one of the most important skills a programmer can have. If you can't remember what you've read, you need to slow down. Lack of understanding causes bugs. single-stepping through a function of that size doesn't even cost extra time when you use proper tools (and not that POS gdb), so 'waste your time' doesn't even apply there Yes it does. Single-stepping requires a round-trip between the computer and your brain for every line of code. When your IDE jumps you to a new file because you stepped into a function, your brain has to context-switch and read the surrounding code. All in all, it's a slow and complicated operation compared to the normal process of running your unit tests and scanning the logs if there is a failure. That case is fast because most parts are done by the computer; it just gives you a few pieces of information that you can use to analyze, tweak, and re-run. And you can drink some coffee while the computer does most of the work! A debugger is for a very special case where unit tests cannot find bugs, or the effort to write these test would be too high. A good example is examining a core dump from a production process. You load it up in your debugger and can inspect the program state in great detail. You see that the current call frame is 0x626f6f66. That looks like the text "foob", which seems like it might have come from some text your program was working with, "the foobar chronicles". But you're using bounds-checking for your string operations, so why the bug? Use the debugger to inspect some local in-memory state, like the "len" parameter to strlcpy. It's 2938473873! Must be an integer overflow somewhere. The key here is that everything we did was interactive and required human thought at each step. We didn't know what the problem was, so we asked the debugger for some data. Then we thought about it for a while, came up with a theory to test, and asked the debugger for more information to prove or disprove our theory. After repeating this a few times, we came to the conclusion that we are doing an addition wrong in the foo function, and that's making the program segfault. With that in mind, we switch back to our text editor, write a test for the length-calculation math, and then fix the math. We shouldn't need a trip to the debugger for a while, because we use the debugger to collect information in odd cases, not to watch our program run normally. So anyway, I guess my hangup with the graphical IDE-based debuggers is "why". Why are you writing code that needs to be single-stepped regularly? Why is your codebase so messy that you can't understand it? Why is your time so worthless to you that you are doing the computer's work for it, instead of the other way around? A debugger is a tool to use for investigating weird things, not something you should bust out everyday. Debuggers have a bad rep with some crowds because of the damage gdb did - people think that that's how debugger work and can only work. Navel-gazing at its worst. A lot of insults, but not a lot of information. If you're so sure that Visual Studio's debugger has solved all of programming's problems, why not share a concrete example of how you use it? Your post adds nothing to the conversation and makes people wish your computer would punch you in the face.