It's 2011, and my IDE still doesn't have a REPL!

The idea of a REPL (pronounced repple) or "Read-Evaluate-Print Loop" was developed in the 1960s at MIT for early Lisp systems, as a way of easily interacting with a programming language. Today, REPLs are sometimes called "shells" or "consoles", as in the "Python shell". Almost any Python, Ruby, or JavaScript programmer would tell you they couldn't live without one. It remains a mystery to me, then, why they haven't really caught on for mainstream programming languages like Java. Implementations do exist, but they're hardly popular. In this post, I intend to argue for wider adoption of this useful tool.

I believe that people go through a series of stages of REPL mastery. The first and most obvious use of the tool is to experiment with code, particularly with APIs. It's one thing to read documentation on how something is implemented, but it's quite another to be able to see how things work in action, to know that it will work for your case. For any remotely complex task, this is essential. I have no idea, for example, how Java programmers write even moderately complex regular expressions without going insane, since the complexity of the expression demands easy experimentation. Furthermore, there's a lot of code in the world without documentation, in which case experimenting with a REPL and reading the code may be your only choice.

Once you're playing with APIs interactively, the natural next step is to start developing your own code interactively. You can basically write a line at a time, and test things out as you go to make sure everything is working well. The lines that do the right thing, you copy into a text editor. Once you're comfortable doing that, well, you can move up to the next level. Does your language let you drop a breakpoint into some code and bring up a REPL at that point? It's difficult to overstate how useful this is for debugging and experimenting. All of the state of the program is set up for you properly. You can write complex code this way, just by setting a breakpoint where you want to write it. You can test everything out interactively as you code with real program values. It's great!

One objection that comes up from time to time in the discussion of interactive development is that it's tricky to usefully interact with a complex codebase, to instantiate the objects and so on that are required. This, however, leads to another benefit: unit testing. The fixtures and mock objects that you need to build to easily try out your code manually are precisely the same ones you'll need for unit testing later on. This leads to a very natural flow of development, where you interactively write a chunk of code, you manually test it out, and then you copy the working result into the code file and you copy the manual tests into your unit tests file. This is the most effective approach to unit testing that I've experienced, since testing flows so naturally from the experimental nature of interactive programming. I highly encourage everyone to at least try this approach to development!