The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL.
Instead, you develop code in a file, but constantly evaluate code as you go along.
When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions.
Then, when I'm happy with the results, I ask the editor to evaluate and insert the results back into the editor. This then becomes the unit test.
> The thing to realise is that, at least is my experience, REPL based development doesn't mean your are actually typing code into the REPL.
> Instead, you develop code in a file, but constantly evaluate code as you go along.
Yes but what you are describing is hot code replacement and evaluation. You do not need a REPL. For a concrete example Java + JRebel + Debugger (Eclipse calls it Display with a glasses icon) will do that for you.
In my mind a REPL is very much about the input and of course the output otherwise its basically what I mentioned above.
And I think the the article doesn't really go into any new innovation or attempts at making REPLs better (particularly because they mention Bret Victor)... ie better input and better output.
Yes advanced REPLs have history saving capabilities and what not but then they are basically competing with the rest of the editor, IDE and source control.
Really innovative REPLs I think are what Bret shows, as well Squeak, and Racket. Those environments offer really unique input and output.
Instead, you develop code in a file, but constantly evaluate code as you go along.
When I work on a clojure project, I very rarely open the actual REPL, but I am constantly evaluating code and experimenting with different implementations of functions.
Then, when I'm happy with the results, I ask the editor to evaluate and insert the results back into the editor. This then becomes the unit test.