Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, tutorials, and more.

Debugging, Monitoring, and Patching Production in the REPL

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 ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training,
learning paths, books, interactive tutorials, and more.