Ask HN: DDD was a great debugger – what would a modern equivalent look like?
I’ve always thought that DDD was a surprisingly good debugger for its time.
It made program execution feel visible: stacks, data, and control flow were all there at once. You could really “see” what the program was doing.
At the same time, it’s clearly a product of a different era:
– single-process
– mostly synchronous code
– no real notion of concurrency or async
– dated UI and interaction model
Today we debug very different systems: multithreaded code, async runtimes, long-running services, distributed components.
Yet most debuggers still feel conceptually close to GDB + stepping, just wrapped in a nicer UI.
I’m curious how others think about this:
– what ideas from DDD (or similar old tools) are still valuable?
– what would a “modern DDD” need to handle today’s software?
– do you think interactive debugging is still the right abstraction at all?
I’m asking mostly from a design perspective — I’ve been experimenting with some debugger ideas myself, but I’m much more interested in hearing how experienced engineers see this problem today. Maybe you can have a look at RadDbg [0], as I understand the project has been bought by Epic Games recently. The goal is to make a performant debugger, from what I understand its target audience is mostly game developers, but you can use it for other programs obviously. You can see a talk of the core developer and his vision here: https://www.youtube.com/watch?v=_9_bK_WjuYY Sadly it's windows only yet, but they have plans to port it to other platforms. The readme talks about plans for Linux support, but I'm guessing that's no longer on the table after the Epic acquisition? Sweeney is the single most publicly anti-Linux CEO I'm aware of. Do you expect an IAP peddler to support free software? Yes actually: plenty of companies don't care where their money comes from, they're happy as long as there's money. Unity, the other big IAP peddling game engine company, has pretty good Linux support. It's weird for a company to explicitly say, "if you use this one operating system you can go F yourself, we don't want your money". (Note: this is not the same as saying "we only officially support Windows at this time, sorry". There's seething hatred in Sweeney's words.) My background is in teaching C programming at the university level and DDD was very helpful there, although not very comfortable to use. For years, I've looked for a replacement and finally found Seer and was very happy with it. https://github.com/epasveer/seer Interactive debugging is definitely useful when teaching but obviously teaching is a different context. But Seer is not an educational tool and I believe it will hold up in other cases as well. Pernosco Blows everything else out of the water. https://pernos.co/
( I’m not affiliated to them in any way, just a happy customer) printf("Got here, x=%u"\n", x); “The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” - Brian Kernighan I haven’t touched in a while, but Visual Studio’s (standalone, not code) debugger was very cool. Also rr is impressive in theory, although it never worked on codebases that I worked on. Check out Binary Ninja if you haven’t. Especially if you have large binaries! Something like this maybe: Doesn't seem to meet all your desired features though. Yes, that’s a good example — thanks for the link.
Tools like this seem very strong at visualizing and exploring state, but they still tend to stay fairly close to the traditional “pause and inspect” model.
What I keep struggling with is understanding how a particular state came to be — especially with concurrency or events that happened much earlier.
That gap between state visualization and causality feels hard to bridge, and I’m not sure what the right abstraction should be yet. Sounds like you want a time travel debugger, eg. rr. Sophisticated live debuggers are great when you can use them but you have to be able to reproduce the bug under the debugger. Particularly in distributed systems, the hardest bugs aren't reproducible at all and there are multiple levels of difficulty below that before you get to ones that can be reliably reproduced under a live debugger, which are usually relatively easy. Not being able to use your most powerful tools on your hardest problems rather reduces their value. (Time travel debuggers do record/replay, which expands the set of problems you can use them on, but you still need to get the behaviour to happen while it's being recorded.) Sounds like you want time travel debugging [1]. Then you can just run forwards and backwards as needed and look at the full evolution of state and causality. You usually want to use a integrated history visualization tool to make the most of that since the amount of state you are looking at is truly immense; identifying the single wrong store 17 billion instructions ago can be a pain without it. Here's another one It's for embedded systems though, which is where I come from. In embedded we have this concept called instruction trace where every instruction executed with the target gets sent over to the host. The host can reconstruct part of what's been going on in the target system. But there's usually so much data, I've always assumed a live view is kind of impractical and only used it for offline debugging. But maybe that's not a correct assumption. I would love to see better observability in embedded systems. Radare and friends maybe. For sure it has some graph-like options as DDD had where you could graphically see everything. Most RE tools today will integrate a debugger (or talk to gdb). Linaro (need Allinea) DDT? I am pretty happy with the debugger from Visual Studio. Domain driven design? I assume is this one https://www.gnu.org/software/ddd/ I used it back in Uni, in 98, and it really helped me to understand debuggers. After it, even using gdb made sense. This is a legitimate question but this was clearly generated using an LLM. To add something constructive, this demo represents an amazing ideal of what debugging could be: https://www.youtube.com/watch?v=72y2EC5fkcE