Chas Emerick (@cemerick) is the co-author of “Clojure Programming” along with Brian Carper and Christophe Grand. He maintains a busy blog at cemerick.com and he also produces “Mostly Lazy … a Clojure podcast”.
I asked Chas to enumerate some of the topics that would make a difference to developers: something that would attract attention to Clojure as a language, so we wouldn’t spend time talking about yet another syntax. One of the first things he immediately mentioned was REPL. Writing code in Clojure is often about making changes and immediately seeing your results. Clojure has emphasized this shell-like approach to development and created an environment that allows for immediate evaluation of code and incorporating changes into a running process.
Clojure differs from other languages in that this interactive shell isn’t an afterthought. Ruby’s IRB or Java’s beanshell are similar attempts at interactivity, but they are not primary features of each language. With Clojure, REPL is built in, and you can connect to any running Clojure process and modify and execute code. In this interview we discuss some of the possibilities that this introduces for Clojure developers.
Highlights from interview:
On what is unique about REPL
“…what’s really unique about Clojure is that most people’s workflow when developing and using Clojure is tightly tied to the REPL, using the dynamic interactive development capabilities that the REPL provides to really boost your productivity and give you a very immediate sense of control over both the Clojure runtime, the application, programming or service that you’re building.” [Discussed 00:52]
How does REPL affect your development?
“Generally what you do in Clojure is you start up a JVM instance that is running the Clojure runtime and starts a REPL that you connect to … then you stay connected to that running Clojure runtime for hours, days. I’ve had Clojure environments running for weeks in an interactive development setting, where you gradually massage the code that’s running within that runtime that corresponds to files you have on disc.
“You can choose what code to load into that environment at any time, massage the data that’s being processed by your application. It’s a great feedback mechanism and gives you an immediate, fine‑grain sense of control over what you’re doing [Discussed 01:18]
On using REPL to deploy production patches
“It’s true, you can start up a REPL running on Heroku right now, connect to it and modify your application. Everything will work as you would expect if you happen to be running the application using Foreman locally.
“You don’t want to be, in general, modifying your production environments from an interactive standpoint. You want to have a repeatable process … Depending on the circumstances, it can be reasonable in a ‘fire drill’ situation to push a critical, time‑sensitive patch out to production … 99% of the time you probably shouldn’t reach for it, but it’s very good to know that it’s there.” [Discussed 05:44]
On using REPL for direct access to production statistics
“JMX is great in terms of providing a structured interface for doing monitoring. But you need to plan ahead of time for the things you’re going to monitor for and make sure you have the right extensions to monitor the things that you care about.
“Having a REPL available to connect to in every environment — whether it’s development, user acceptance, functional testing or production — means that when you need to, you can get in there and write a one‑off function. Pull some data from this database, see what’s going on with this function, capture some data that you wouldn’t normally be capturing, stuff that may be far too large to log or to practically get access through JMX. It’s a great tool.” [Discussed 05:44]