On Repl-Driven Programming

I think just because someone is able to do something similar in another language doesn’t mean that the power of a fully integrated REPL is overstated.

Most developers are using languages where this sort of thing isn’t possible, and for them, experiencing a REPL driven development flow can be an eye opening experience (even if it’s just to add it to their tool box along side more common approaches like attaching debuggers and using TDD to shorten the development feedback loop).

I don’t know enough about Elixir to understand how your approach is the same/different than using something like a REPL with Clojure, but I did come across a pretty interesting discussion on the topic:

https://elixirforum.com/t/what-do-you-all-think-of-clojures-...

TL;DR - you can accomplish something similar with Elixir, but the underlying technical details are different.

Bash?

Author describes a nice feature, but that’s not what makes repl-driven development tick for me. Repl really shines when editor integrates with it - send a form to evaluate, instantly get result back into the editor, eval a form and replace it with the value received, define and redefine the environment on the fly, get instant feedback if your code works without having to drop into shell and run some test command, micro-tests and usage examples that you can actually run inside editor to see how they work.

You can get similar integration with ruby and python, but there’s way more friction because that kind of development is not the blessed way and so nobody bothers to make it work.

You misunderstand me. By "repl-drive programming" I do not mean programming that is fixated on the "command-line repl". On the contrary, what I'm talking about has much more in common with what you describe as "far more productive". It's not about a particular shell or window or buffer; it's about a runtime environment that is designed to support writing software by building and changing it as it runs.

By "repl", I do not mean the window or the buffer or the shell program. I mean the loop of: read an expression, evaluate it, and present the results, in the context of a runtime that is designed to comprehensively support it.

Moreover, you can have all of the tools that you listed and still not be working with a properly-designed repl-driven environment. For example, I built a 3D interactive environment on the JVM that worked quite well--it launched into the 3D environment ns no more than a second or two, and could build whole procedurally-generated scenes in a few seconds. It supported networked multiuser interactions. I could start it from a repl and dynamically alter scenes and objects and their behavior in the environment by talking to them.

It still wasn't a proper repl-driven environment because the underlying runtime could not correctly handle dynamic redefinition of classes and methods. That meant that if I decided that I needed to change a representation or something, I had to kill the environment and rebuild it. It meant that there was always a gratuitous barrier that I might run into at any moment. It meant that some abitrary set of things I was working on was always on the other side of that barrier.

Contrast that to working with, for example, SK8, where I could redefine absolutely everything in the environment (including, for example, the system-level procedures used to draw window frames) without ever restarting the code that was under development.

Agreed, FORTH is repl-driven in the sense I mean. The main difference from Lisp and Smalltalk systems is that FORTH environments are, generally speaking, more spartan.

In the late 1980s I had a group of friends at Apple that included Smalltalk, Lisp, and FORTH programmers. We certainly found plenty of things to admire and attempt to steal from one another, and everyone accepted the basic goodness of building systems by engaging in conversation with them as they run.

Lisp and Smalltalk cross-pollenated each other more than each did with FORTH, but maybe Slava Pestov's Factor is a glimpse of what you get if FORTH is more in the mix.