Proper usage of REPL for development

Question

I've always wondered on how to use REPL properly for writing reusable code, as opposed to one-off experimenting. There are strong opinions on various advantages of REPL style of development, and I'd like to check that in practice but I don't understand what would be the expected workflow.

Suppose I open my existing module (+sample/test data) in a REPL, and interactively create a new feature/fix a bug. Great success - it now frobnicates the foobar as intended! But now what? How am I supposed to get the changes and additions back into my module(s) and versioncontrol?

Dumping all REPL state to a file would work only for the initial creation, not for modification or additions to existing code (so, pretty much all development) - it needs to preserve things such as split among modules, comments, etc. Copypasting from REPL history to the relevant spots in each file seems to be tedious work and very prone to errors. How do I ensure that the modified functions have the exact final version that I had in REPL, and that I haven't forgotten some?

What is the recommended best practice for this?

IMHO the question is language independent, but if not, let's assume Haskell or Python, as Lisp is a world of it's own and I'm not familiar enough with it.

Answer 1

REPL is not designed to be used for persistent code development. The primary uses for REPL are:

• Small tests to determine code & interpreter behavior.
• Learning tool for new users.
• Interactive execution environment for adhoc scenarios.

There are some exceptions, such as the line editor with LOAD and SAVE operations of Microsoft's ROM based interpretive BASIC that was popular in the late 1970's and early 1980's. However, this was really a comprise offered on early microcomputers that didn't have the storage, capacity and OS features required for more advanced file system based development environments.

Another exception is the saved history and alias features of various operating system command shell REPL environments such as bash. In this case, the interpretive language, although important, is secondary to managing the file system and executing system binaries. The reuseability of user code in these environments is geared towards management and day-to-day operation of the platform.

For using advanced persistent programming concepts such as modularization and version control it is recommended to use the file system based programming facilities offered by the interpreters tool set. Most development languages have unit testing frameworks, such as HUnit for Haskell and unittest for Python, that allow component level testing and operational checks to be performed during the application development process.

All this being said, given the right language and implementation it may be possible to break this paradigm and create a REPL environment that builds something larger and more complex from small code samples provided by the user.