What’s the most empowering way you could title a debugger?

Interesting question. Program Introspector? Inspector? Analyzer? Though upon reflection, debuggers don't really support analysis in general, they only support analysis in time.

slow motion replay

Real Time Program X Rays

There is no one thing fit all answer for debugger. Different level of people responsible for different level of details. A debugger could easily expose overwhelming information for the wrong audience. It is important to tailor just-enough information to assist the task in hand.

Execution inspector. I like @shalabh’s proposal "slow motion replay" except that I am not aware of any debugger that actually works like that. Sometimes I'd love to be able to run a piece of code in slow motion, with various views on its inner state, rather than having to launch each step by hand.

To walk step-by-step with your program, handholding through execution

Dynamic view

@Konrad Hinsen can confirm, slow mo replay is a great tool. It’s not really easy in Clojure, but the times I’ve needed it the live replay is super useful.

@jatkins So what is the magic tool that makes this possible in Clojure?

@Konrad Hinsen Lol, macros. https://github.com/vvvvalvalval/scope-capture

@jatkins That's an interesting use of macros to implement an ugly workaround for the lack of access to stack frames in a debugger!

Hmmm. Yes? Between the REPL and Java debugging tools it hasn’t been an issue though.

Sounds like a case of Stockholm syndrome 😉 For me, having to switch to a lower level code representation for debugging is a clear sign of bad development tools. But then, the more I work with Pharo/Smalltalk, the less tolerant I get for systems with less support for humans.

I didn’t mean to start a debate on the viability of Clojure as a language… Suffice it to say clj fits my needs quite well, and it (inadvertently) does support the ability to play back a function call. It’s particularly useful on inner loops.

I wasn't meaning to denigrate Clojure, which I have used myself in the past with an overall positive experience. It's just that the topic of this thread is debugging support, which I think most people agree is not great in Clojure because the call stack can only be inspected at the JVM level. It's surprising to me how few high-level languages provide adequate support for high-level debugging. Implementation difficulties are probably a big part of this, but I suspect there's also a lack of interest. "Real programmers don't need debuggers" is still something I hear frequently said (in some variant).

Ah, I see. To be honest, I’ve never even felt the need to use a debugger, except for the random npe that gets eaten by the jvm. That’s not to say I’ve never used one - in Java I heavily depended on the debugger. I think it comes down to the fact that the REPL is 99% of the time the easiest place to debug stuff. There are certainly a few utilities I’ve used and or built to make that number higher. One of them being spyscope.

The REPL goes a long way, I agree. It starts to become insufficient when you are debugging code that's a few layers down from the surface. Which is exactly when stack traces start to matter. So for me, the transition from bad to good debugging support is the presence of a debugger that lets me inspect stack traces at the level of my language: access to local bindings by name, moving up and down the stack, etc. Unfortunately, among the languages I know, that's a rare feature: Smalltalk, Common Lisp, Python, and nothing else.

Ah, I see. Yes, I pretty much agree. I’ve found lots of shortcuts to use the REPL for different instances of long stacks, but sometimes it would be be great to look all the way down. I think getting a really good debugger in clojure might be possible if your editor played along and made some configurable transformation to the code that is invisible to the user - e.g. adding spyscope (or some specialized cousin), and collecting the relevant details for online display.

Right, in particular in the Lisp world, using macros for code instrumentation. It just needs to be done!

@Konrad Hinsen Welp, I actually made said macro. It works pretty well 🙂. Now the instrumentation needs to go beyond capturing just the local function, but also the call tree. Perhaps even extend to the async side of the code? The sky’s the limit.