So is it easy to write good tooling or is it not, because gdb still sucks.
So, if you're still not sure about it, this kind of comment is why people mute you on Twitter. Being argumentative and
nonsensical is kind of the magic combo for that. You just picked a random project and decided that because I never went and improved it, I must be wrong about tools programming??
Do you really
believe that makes sense as something to say?
But, whatever. All of this should be pretty obvious to anyone who thinks about it for a second, but since that apparently didn't happen:
Writing tools is no different than writing games, although some of the technique choices differ. But this is rather completely
true, meaning that a poorly written tool may be difficult or impossible to really improve substantially without a complete rewrite because of the infrastructure choices made, the design of the code, etc. In a lot of ways, the quality of a program often flows from the architecture, such that if a tool is shitty, it's usually not because the programmers did a great job on the bulk of it but just failed at the edges. It's usually because the architecture is very poor and it is difficult for the programmers to make the user-facing parts do what everyone can plainly see they should do.
The things we do in Handmade Hero that take only a few hours, like asset streaming, might be almost impossible
to do in a codebase that were architected differently without touching literally all the code and debugging the resulting problem for days. I complain about Photoshop constantly, for example, but if you gave me the source code, it wouldn't help me at all. The problems with it are fundamental and it would be much faster for me to rewrite the parts that I need than it would be to start from their codebase - I can tell you that even without looking at it, just by the behavior of the program :)
So, much like you can't just take someone's game engine and magically add streaming to it if they made a ton of bad architecture decisions up to that point, you can't just parachute into GDB, spend a day, and suddenly it's awesome. And this is even more true for programmers like me, who are architecture guys, because we get 90% of our speed from the fact that we're smart about high-level design. There are programmers that I've known who have skills more adapted to the parachute-in, change, get out style, but I'm not one of them :) A classic example of this is Michael Sartain (also a RAD guy), who consistently surprises me by the way he's able to just jump into some nightmare open source project and go improve something. Of course, even he has never be able to make a dent in GDB or LLDB to the best of my knowledge (and he did try quite a bit with LLDB, but I believe he found trying to work with the maintainers to be prohibitive, another classic problem with trying to improve open source software).
And finally, writing tools is no different than writing games in the fullest sense of that statement
. Sure, it's easy to do a good job on a game engine if you're smart about it, like I'm trying to show in Handmade Hero. But it still takes a substantial time investment
. It wasn't like I started showing how to program the Handmade Hero engine and then five hours later I was done. We'll be about 200 hours of programming in before the engine is in shape, and then we've still got what I estimate to be about 400 hours of programming before we have a nice game. That's 17 weeks of full-time programming! Where do you think I'm going to pluck 17 weeks of full-time programming from my schedule in order to go rewrite GDB? It's simply not feasible if you have other things that you've prioritized higher.
Someday it will probably get to the point where Visual Studio is as bad as Linux debuggers, and then I'll have to change those priorities. It's certainly going that direction. But until then, there is always some program higher on the priority list than rewriting a debugger.
PS. As a coda, I'd like to point out that I don't actually have a problem
with GDB. It's often my go-to debugger on Linux when I just need to see where something crashed or whatnot. It's problem is just that it's command-line-centrism makes it very difficult to use as a "code investigator", which is something I often use a debugger for. I like to have watches, call stacks, source views, etc. that update in an easy-to-view fashion as I step through code, and GDB sucks at that. For some reason, all the things people build on top of GDB never seem to be able to actually retain the "able to get data properly" part of GDB :( So in theory, some GDB front end would actually be fine for debugging on Linux, but even though I've tried dozens of them, I still haven't found one that actually properly implements all of GDBs inspection features while providing a usable interface.