[ss3000]

I think the "_running_ app instance" is the key distinction here.

Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here.

Another limitation is that you can't really inspect parts of your system outside the context of the currently running function where the breakpoint was triggered.

I think debugging with state-preserving hot reloading in UI development is probably the closest analogue I've encountered to debugging workflows with a Clojure REPL, though it's still nowhere near as flexible.

[lispm]

> Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here.

Fix and continue. Various language implementations provide that.

[ss3000]

That's altering the _code_ as opposed to altering the _state_ of the system.

[lispm]

Just change the state, too. Many languages/implementations provide that.