Almost exactly, it's mostly how you use the REPL that differs, and then only because of what different editors prioritise. When I'm in Emacs, all my work happens against a running REPL - when I open or save a file, it's reloaded. Any tests loaded in the REPL rerun on every save, within that live instance. If I drop into the debugger, it's against that live instance. I can swap in mock components to a running system, go check stuff in a browser (even jack into a live webpage with ClojureScript), all in one long running instance. I have struggled to recreate this kind of setup as smoothly in Python with any editor (pytest doesn't want to run this way, and IPython's autoreload doesn't feel as reliable), but I do probably write more REPLy code in Python than most, so all my model training and optimisation runs during development happen in pausable background threads in IPython etc.

All that said, 90% of the time you still just eval a bit of a code to see what happens and that's the same between the two languages.

simplest way to think about it: the python repl is a scratch pad next to your code. the clojure repl IS your running application. you're rewiring the plane mid-flight instead of landing, making changes, and taking off again. once you experience that feedback loop you genuinely can't go back.

the benefit of lisp in an editor with integrated repl environment is that you get to see immediate feedback by easily evaluating chunks of your code as you navigate it, without copying stuff back and forth between the editor and the repl

and the benefit of lisp comes from the fact that every expression is fully delineated by parentheses, so you don't need to select any text, find the start or the end of any syntactic construction, you just eval the form you're standing at and see the result

or just as easily you can wrap that form, bind the locals to test values and eval that to see what changes

You evaulate code within your editor against the REPL, seeing the output in the same window you're writing in (perhaps in a different buffer).

The cycle is:

  1. Write production code.
  2. Write some dummy code in the same file (fake data, setup).
  3. Evaluate that dummy code. See what happens.
  4. Modify  code until satisfied.

https://www.youtube.com/watch?v=5HHLT2_a1tI

An example of me solving an Advent of Code with clojure and repl. You can see i never interact with the repl directly, I just send code to it via my editor and get results inline.

The two big things are:

1. REPL is automatically compiled into running systems 2. Great hot-reloading support

So it's generally very easy to "poke" at a running system, and the whole dev process assumes you will do this.

TBH, these days it is largely possible in a C++ debugger. Less so 10 years ago, though.

it is very similar, but it is easier to evaluate sub-expressions thanks to the unique syntax of lisp.

there's a detailed explanation here: https://youtu.be/Djsg33AN7CU?t=659

More or less, yes. It's more about the approach to the repl and how it is leveraged in development, or even jacking in to a running system and modifying it as it is running.

[dead]