4 ms·

Everytime I've singled out the REPL as why I like Clojure so much when explaining why Clojure so great to my friends they seem to mention that other languages h

Everytime I've singled out the REPL as why I like Clojure so much when explaining why Clojure so great to my friends they seem to mention that other languages have repls too. Like F# or JavaScript. When I counter that Clojure's REPL is connected to the running app instance they are developing I don't think they really understand. Perhaps this is one of those things that you just have to try out to grok.

wtf_srsly 7y ago
As is javascript. Have you ever tried debugging an application with Chrome ? I frequently use the "pause on exception" feature of the debugger or also place breakpoints strategically and then use the console as REPL for further debugging.
- ss3000 7y ago
  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 7y ago
    > 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 7y ago
      That's altering the _code_ as opposed to altering the _state_ of the system.
      - lispm 7y ago
        Just change the state, too. Many languages/implementations provide that.
- kqr 7y ago
  One difference is that you might then be debugging compiled, possibly even modified JS. The Lisp REPL deals in the original Lisp source code.

wtf_srsly 7y ago

As is javascript. Have you ever tried debugging an application with Chrome ? I frequently use the "pause on exception" feature of the debugger or also place breakpoints strategically and then use the console as REPL for further debugging.

ss3000 7y ago
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 7y ago
  > 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 7y ago
    That's altering the _code_ as opposed to altering the _state_ of the system.
    - lispm 7y ago
      Just change the state, too. Many languages/implementations provide that.
kqr 7y ago
One difference is that you might then be debugging compiled, possibly even modified JS. The Lisp REPL deals in the original Lisp source code.