manux81

Ask HN: Would filesystem bookmarks be useful in your shell workflow?

Posted by manux81 on Sunday July 12, 2026 @04:13PM
from the ask-hn dept.

I’m experimenting with a small shell utility for filesystem bookmarks, and I’d like to understand whether this is a problem other people have.The idea is to define persistent or temporary bookmarks for directories:``` bm add work ~/Work bm temp build /tmp/build ```and then use them directly in paths:``` cd @work ls @work/project ```The utility would also support renaming bookmarks, promoting...

( Read More... | 2 comments | 2 points | on HN )

Re:DDD was a great debugger – what would a modern equivalent look like... on Monday January 26, 2026 @11:24AM (#46767621)

For context, I’ve been experimenting with a small open-source prototype while thinking about these ideas: https://github.com/manux81/qddd It’s very early and incomplete — mostly a way for me to explore what breaks once you actually try to model time and causality in a debugger.

Re:DDD was a great debugger – what would a modern equivalent look like... on Monday January 26, 2026 @11:22AM (#46767609)

That’s a very fair point. The hardest bugs I’ve dealt with were almost always the least reproducible ones, which makes even very powerful debuggers hard to apply in practice. It makes me wonder whether the real challenge is not just having time-travel, but deciding when and how much history to capture before you even know something went wrong.

Re:DDD was a great debugger – what would a modern equivalent look like... on Monday January 26, 2026 @11:22AM (#46767597)

This resonates a lot. Framing debugging as an investigation — with hypotheses, evidence and gaps — feels much closer to how I experience real debugging, especially on complex systems. What I’m still unsure about is how much of that investigative process tooling should make explicit, without overwhelming the developer or turning it into a full case-management workflow.

Re:DDD was a great debugger – what would a modern equivalent look like... on Sunday January 25, 2026 @05:57PM (#46759489)

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.

DDD was a great debugger – what would a modern equivalent look like today?

Posted by manux81 on Sunday January 25, 2026 @05:47PM
from the self-post dept.

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

( Read More... | 61 comments | 3 points | on HN )