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.

▲

TheRoque an hour ago | parent | next [-]

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.

- [0]: https://github.com/EpicGamesExt/raddebugger

▲

mort96 28 minutes ago | parent [-]

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.

▲

nottorp 10 minutes ago | parent [-]

Do you expect an IAP peddler to support free software?

	▲	mort96 7 minutes ago \| parent [-]
		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 ad- and 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.)

▲

uyar 27 minutes ago | parent | prev | next [-]

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.

▲

martijnvds 2 hours ago | parent | prev | next [-]

printf("Got here, x=%u"\n", x);

	▲	jeffwass an hour ago \| parent [-]
		“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” - Brian Kernighan

▲

Agingcoder 28 minutes ago | parent | prev | next [-]

Pernosco

Blows everything else out of the water.

https://pernos.co/ ( I’m not affiliated to them in any way, just a happy customer)

▲

galkk an hour ago | parent | prev | next [-]

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.

▲

apaprocki 43 minutes ago | parent | prev | next [-]

Check out Binary Ninja if you haven’t. Especially if you have large binaries!

▲

chrsw 10 hours ago | parent | prev | next [-]

Something like this maybe:

https://whitebox.systems/

Doesn't seem to meet all your desired features though.

▲

manux81 10 hours ago | parent [-]

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.

	▲	omnicognate an hour ago \| parent \| next [-]
		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.)
	▲	Veserv an hour ago \| parent \| prev \| next [-]
		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. [1] https://en.wikipedia.org/wiki/Time_travel_debugging
	▲	chrsw 9 hours ago \| parent \| prev [-]
		Here's another one https://scrutinydebugger.com/ 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.

▲

anthk 22 minutes ago | parent | prev | next [-]

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).

▲

markhahn an hour ago | parent | prev | next [-]

Linaro (need Allinea) DDT?

▲

DeathArrow an hour ago | parent | prev | next [-]

I am pretty happy with the debugger from Visual Studio.

▲

buster 2 hours ago | parent | prev | next [-]

Domain driven design?

	▲	reidrac an hour ago \| parent [-]
		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.

▲

superdisk an hour ago | parent | prev [-]

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