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.