And for a more factual reply: You're making a lot of wrong assumptions. Ahead: I will be talking about a Perl debugger. > Information overload is just as bad

And for a more factual reply: You're making a lot of wrong assumptions. Ahead: I will be talking about a Perl debugger. > Information overload is just as bad as too little information. Here you're making the assumption that such a GUI debugger would show ALL OF THE THINGS ALL THE TIME. Instead however they can be pretty damn intelligent. My weapon of choice inspects the lexical scope around the current position and displays variables around it, as such there is a window of things that the user is very likely to care about whenever the debugger stops. Then, to top it off: The debugger does not actually show all the contents of complex variables at once and instead permits it to show/hide/page their contents and remembers what state they were in when looked at the last time. Information overload is a real problem, but technology has advanced and as long as people don't try to create actual intelligence, agents that take out the work out of certain oft-repeated tasks are viable and useful. > Single-stepping requires a round-trip between the computer and your brain for every line of code. Here you're making the assumption that one has to step through every single line of code to get to the place one wants to look at. In reality, breakpoints are employed instead and sometimes even conditional breakpoints, in order to avoid having to s-s-s-s on a point that's executed repeatedly with data one doesn't care about. Additionally they have nifty tools like "step out" or "step over" that permit it to make it easier to get to interesting points without going through entire irrelevant functions. And lastly, breakpoints are not static, they can easily be set or disabled at runtime, making exploration easy. > 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. Here you're making the assumption that all the code is in one file most of the time. I do not think i need to expand on that. Also, keep in mind that debuggers are often more than clever enough to realize that per-line debugging is stupid and per-statement debugging much more useful. As such, the little arrow can, for example, be really useful in showing you that your code keeps stepping on a certain line where you expected it to proceed. > The key to debugging is to reduce the scope of the problem When one starts using third-party libraries the debugger is stupidly useful in showing exactly where inside that library the input data is operated on, so it can actually be the best tool to reducing the scope. > unit tests unit tests unit tests You like them a lot. To the point where you seem to ignore that they're entirely synthetic and can mislead a lot about what actually happens when code collides with real data. Unit tests are not a debugging tool. They are self-checking documentation of your code. Ok, i can't be arsed to write more. Please try to understand that there are many perspectives and that insulting people will only lead to them hardening their perspectives.