In The Persistent, Evolving Environment, we talked about the “persistent, evolving environment” that the REPL provides in a development context. What was left unsaid there is that those environments to which the REPL connects us are not limited to development contexts. There is no technical reason why a REPL cannot be leveraged in “deployed” contexts—including production—to provide the same kind of dynamicism enjoyed in development.
Remember that the fundamental unit of interaction between you and a Clojure environment is loading code: very simply, evaluating expressions, from files on disk or provided as input to a REPL, which define functions and values and effect changes to the environment. No other special requirements apply. While some REPLs are tied to a local operating system process and console (including the default REPL provided by Clojure that we introduced in Example 1-1), that is by no means universal. In fact, many (if not most) Clojure development tools—including Counterclockwise for Eclipse and SLIME for Emacs—only use “remote” REPL processes.
When you start REPLs in these tools, a new JVM process is spawned as
you would expect, but that process is initialized to start a REPL server,
to which the tool connects: all of the code you load from such tools, and
all of the interactions you have using their REPL user interfaces all
occurs over a network pipe, albeit one connected to
localhost. Very simply, these REPL ...