What does this setup look like? I’m imagining one window with a REPL and a second window with your source code, if you edit the source code it will immediately update in the REPL…?
It's close to that but not quite. The typical and recommended setup is what's called an editor/repl integration. You edit code as normal, but then you have keystrokes for recompiling/evaluating bits of code. Commonly, you can evaluate a whole file, a top-level form (like a defn), or a single expression. This lets you modify an existing system and probe it to see how it works while maintaining state in-memory.
Less common, but still not rare, is a system to automatically tear down and re-initialize stateful resources so that as you change code, you can easily get everything working again as if the JVM were started with that code.
The challenge with both of these (complementary) approaches are that your code and your running system can get out of sync. Part of the skill of REPL-Driven Development is keeping them in sync. And the other half is recognizing when they might be out of sync and correcting it.
Thanks for this post! It's hard to explain the different between a true REPL and interpreter prompt. I get "Yeah but Python has a REPL..." constantly. It's nice to see an articulation on the nuances. Thanks for clarification.
You touch on this but I also wanted to highlight the importance of S-expressions and an IDE that can leverage them. Structural editing ("move this form" rather than "move these chars") is a huge part of why Lisp and REPLs are successful.
Put another way, if I couldn't understand my code structurally, I'd have no way to eval the current element/form/buffer. I'd be back in the ancient world of navigating by bespoke arrangements of ascii characters. A REPL is awesome but it's made practical by the gift of consistent syntax and structural editing. To me, that was the "aha" moment. The idea that application state is accessible didn't really rock my world too much.
A small nit: reading docs is perfectly compatible with REPL experimentation. Just like LSP, tech docs are small, statically-analyzable, a critical piece to the modern dev environment. Por Que No Los Dos? My advice would be instead: set up an editor shortcut to display docs inline and use it liberally.
What does this setup look like? I’m imagining one window with a REPL and a second window with your source code, if you edit the source code it will immediately update in the REPL…?
It's close to that but not quite. The typical and recommended setup is what's called an editor/repl integration. You edit code as normal, but then you have keystrokes for recompiling/evaluating bits of code. Commonly, you can evaluate a whole file, a top-level form (like a defn), or a single expression. This lets you modify an existing system and probe it to see how it works while maintaining state in-memory.
Less common, but still not rare, is a system to automatically tear down and re-initialize stateful resources so that as you change code, you can easily get everything working again as if the JVM were started with that code.
The challenge with both of these (complementary) approaches are that your code and your running system can get out of sync. Part of the skill of REPL-Driven Development is keeping them in sync. And the other half is recognizing when they might be out of sync and correcting it.
Thanks for this post! It's hard to explain the different between a true REPL and interpreter prompt. I get "Yeah but Python has a REPL..." constantly. It's nice to see an articulation on the nuances. Thanks for clarification.
You touch on this but I also wanted to highlight the importance of S-expressions and an IDE that can leverage them. Structural editing ("move this form" rather than "move these chars") is a huge part of why Lisp and REPLs are successful.
Put another way, if I couldn't understand my code structurally, I'd have no way to eval the current element/form/buffer. I'd be back in the ancient world of navigating by bespoke arrangements of ascii characters. A REPL is awesome but it's made practical by the gift of consistent syntax and structural editing. To me, that was the "aha" moment. The idea that application state is accessible didn't really rock my world too much.
A small nit: reading docs is perfectly compatible with REPL experimentation. Just like LSP, tech docs are small, statically-analyzable, a critical piece to the modern dev environment. Por Que No Los Dos? My advice would be instead: set up an editor shortcut to display docs inline and use it liberally.