>> How come the open source world hasn't been able to create a debugger that's as good as the (still primitive) debugger in Visual Studio 6.0? It's astonishing to me how bad the state of the art is.
I keep asking myself that same question every now and then, why can XCode have such a nice and pleasant LLVM-based version of gdb, while gdb on linux still doesn't have even the most bare-bones GUI that let's me inspect common data types without jumping through hoops?
On Xcode nowadays the debugger is lldb, not gdb, but it's a very similar debugger in the sense that it's fundamentally command-line-based. Xcode just happens to integrate with it to provide a GUI front end.
When I was into Linux in the '90s, DDD was very popular (as was Emacs as a gdb front-end), but now there are also dedicated IDEs like Develop/QT Creator/Eclipse that provide similar front ends to gdb like Xcode does for lldb (and used to do for gdb).
It's also very valuable to learn the CLI (both for gdb and lldb), because it seems like there are inevitably useful features in both debuggers that aren't exposed by any GUI, not to mention being able to debug something over ssh. It's not a requirement though, there are tons of options out there.
This is strictly true, of course. But it's a very useful CLI, which is exposed within Xcode as well. From a developer perspective, it's a very similar situation- the CLI gives you full access to the capabilities of the debugger, and the GUI gives you more convenient/intuitive access to a subset of that functionality. Even inside Xcode I spend as much or more time in the lldb console window than I do driving it with the GUI.
I use ddd, but I don't particularly like it. It's telling that after all those years we still don't have anything better, it seems like ddd today is still the same crutch as when I first used it, over 10 years ago.
The market has spoken in terms of preferring free tools. I personally think that is one big reason why the quality of developer tools is as low as it is.
For some reason the equality seems to hold for most applications with a complex user interface. Reasons may include that it is a cross discipline thing that requires skills/people such as interaction designers, artists, technical writers, linguists etc that are less common than developers in the OSS community. It could also be that good interface design benefits from a centralized decision process which can be a bad fit for OSS that is usually too incremental and democratic for radical design changes. Normally there is no money for things like paid UI testing/focus groups.
That said, there is great free software with good UI/UX too - only they are more or less always backed by a large corporation.
A market with only free offerings will cause a certain category of actors to be absent. I would think that a market with fewer categories of actors would correspond into a drop in quality among some dimensions.
At least GDB mostly works. LLDB constantly falls over for me doing even the most basic of tasks. Give me a functioning debugger over a pretty one any day.
A year ago I would've agreed with you, but lldb seems just as solid these days. I use lldb just about every day in all sorts of oddball, convoluted debugging scenarios, and I just haven't been hitting the issues I used to with it.
It's not perfect- there are still rare situations in which it's not using the right symbols, but at least that I can usually fix that with a 'target symbols add'. Otherwise it's because the thing I'm trying to debug is sandboxed or otherwise protected, which is almost always going to be a hassle, and requires workarounds outside of the debugger. Raw lldb is a lot better than it used to be though.
GDB mostly works for x86. I used to swear at GDB many times daily when using it to debug an embedded ARM target with openocd a few years ago.
Very frustrating when it crashes just as you've got the target into the state where you think your bug will trigger. And then GDB repeats the performance reliably for you... On those days you end up resorting to a lot of creative thinking.
>> let's me inspect common data types without jumping through hoops?
could you elaborate on what's missing in GDB? data-types are written in the binary by the compiler (dwarf format), and GDB does nothing more / nothing less than parsing it and giving access to it through it user interface.
GDB has no knowledge about your code or it's library in itself (at least in C, Python extentions now include libc++ data-type-specific pretty-printers)
That is exactly what is missing in GDB. The most common things you do while debugging are treated as exotic special cases. Every other debugger I've ever used tries to show me the environment I've landed in, giving me context I can use to understand program state. That is, so far as I'm concerned, the first and most important job a debugger is supposed to do. GDB shows me nothing; I have to tug every scrap of knowledge out of it individually, and I have to tell it how this work should be done. Instead of feeling like I'm using a tool that helps me and does some of the work for me, enhancing my awareness, it feels like I'm fighting with a tool that wants to make my life difficult, that is grudgingly giving up scraps of jealously-guarded information only when I can prove my worth by guessing and reciting its arcane incantations.
I rarely bother; it's easier to fprintf() and read the log file, and this has the advantage of also working when you're trying to debug asynchronous processes.
QtCreator has a nice GUI over the GDB. I was pleasantly suprised to see it worked really well, but - on the other hand - I didn't use it for any advanced debugging.
I keep asking myself that same question every now and then, why can XCode have such a nice and pleasant LLVM-based version of gdb, while gdb on linux still doesn't have even the most bare-bones GUI that let's me inspect common data types without jumping through hoops?