Once upon a time, someone with the handle “entha_saava” posted this question on Hacker News:

Can someone knowledgeable explain how are lisp REPLs different from Python / Ruby REPLs? What is the differentiating point of REPL driven development?

The answer is that there is a particular kind of programming in which you build a program by interacting with it as it runs, and there are certain languages and runtimes that are designed from the ground up to support that kind of programming.

Python and Ruby are not examples of such languages.

Why not? That’s the crux of entha_saava’s question, right? What are these repl-driven programming systems, and what makes them different from Python and Ruby and every other language that offers a repl?

For that matter, what’s a repl?

The word repl is an acronym that stands for read-eval-print loop. The term comes from the history of Lisp. From the start, sixty years ago, the standard way of working with a Lisp has been to start a language processor, type expressions at its prompt, and wait for it to evaluate the expressions and print their results, before prompting for another expression. Read, eval, print. Loop.

Nowadays, repls are all the rage. Every language and its brother offers a repl. There’s a website, repl.it, whose entire purpose is to provide all the repls.

It doesn’t actually provide all the repls, of course. What’s particularly ironic is that it doesn’t provide either of the canonical repl-driven development environments: Common Lisp and Smalltalk.

That brings us back to entha_saava’s question: if Common Lisp and Smalltalk are repl-driven environments, and Python and Ruby are not, what’s the difference? What do Lisp and Smalltalk have that Python and Ruby don’t?

What they have is a language and runtime system that are designed from the ground up with the assumption that you’re going to develop programs by starting the language engine and talking to it, teaching it how to be your program interactively, by changing it while it runs.

I can hear the objections formulating already. I’ve seen them before. Yes, every language with a repl can do some things in the repl. Obviously that’s true; if it weren’t, then the repl would be entirely useless.

Being able to do some things in the repl does not make an engine into a repl-driven programming environment. What distinguishes old-fashioned Lisp and Smalltalk environments is that you can do everything in the repl. They place no gratuitous limitations on what you can do; if the language and runtime can do it, then the repl can do it.

For example, you can ask the current version of Clozure Common Lisp to rebuild itself from scratch by evaluating the following expression at the repl prompt:

(rebuild-ccl :full t)

CCL responds by completely rebuilding itself from source.

The point is not that you would want to rebuild CCL this way all the time. The point is that there are no artificial limitations on what the repl can do. The full range of the development system’s capabilities is accessible from the repl.

That’s one of the first things I notice when using newer, lesser repls: I’m always running into things I can’t do from the repl.

It’s not just about freedom from restrictions, though. Proper support for interactive programming means that the language and its runtime have positive features that support changing your program while it runs.

Try this in your favorite repl:

Define a function, foo, that calls some other function, bar, that is not yet defined. Now call foo. What happens?

Obviously, the call to foo breaks, because bar is not defined. But what happens when it breaks? What happens next?

If your favorite repl is Python’s or Ruby’s or any of a few dozen other modern repls, the answer is most likely that it prints an error message and returns to its prompt. In some cases, perhaps it crashes.

So what’s my point, right? What else could it do?

The answer to that question is the “differentiating point” of repl-driven programming. In an old-fashioned Lisp or Smalltalk environment, the break in foo drops you into a breakloop.

A breakloop is a full-featured repl, complete with all of the tools of the main repl, but it exists inside the dynamic environment of the broken function. From the breakloop you can roam up and down the suspended call stack, examining all variables that are lexically visible from each stack frame. In fact, you can inspect all live data in the running program.

What’s more, you can edit all live data in the program. If you think that a break was caused by a wrong value in some particular variable or field, you can interactively change it and resume the suspended function. If it now works correctly, then congratulations; you found the problem!

Moreover, because the entire language and development system are available, unrestricted, in the repl, you can define the missing function bar, resume foo, and get a sensible result.

In fact, there’s a style of programming, well known in Lisp and Smalltalk circles, in which you define a toplevel function with calls to other functions that don’t yet exist, and then define those functions as you go in the resulting breakloops. It’s a fast way to implement a procedure when you already know how it should work.

If you’re a user of old-fashioned Lisp or Smalltalk systems then this all sounds obvious to you, but that reaction is not common. Surprise is much more common, or even suspicion: what’s the catch?

The catch is that the designers of your language system had to think that facility through in the planning stages. You don’t get a decent implementation of it by bolting it on after the fact. Breakloops need full access to the entire development system, interactively, with a computation and its call stack suspended in the breakloop’s environment.

Let’s take another example of a facility designed to support interactive programming. Once again, try this in your favorite repl:

Define a datatype. I mean a class, a struct, a record type–whatever user-defined type your favorite language supports. Make some instances of it. Write some functions (or methods, or procedures, or whatever) to operate on them.

Now change the definition of the type. What happens?

Does your language runtime notice that the definition of the type has changed? Does it realize that the existing instances have a new definition? When something touches one of them, does it automatically reinitialize it to conform to the new definition, or, if it doesn’t know how to do that, does it start a breakloop and ask you what to do about it?

If the answer is “yes,” then you’re probably using a Lisp or Smalltalk system. If the answer is “no,” then you’re missing a crucial element of repl-driven development.

Remember: the point is to support programming interactively. You don’t want to have to kill your program and rebuild it from scratch just because you changed a definition. That’s silly; adding and changing definitions is most of what you do! If your development environment is going to support interactive development, then it had better know how to keep your program running when you change some definitions.

Old-fashioned Lisp and Smalltalk system know how to do that. There are also a few other kinds of systems, mostly older ones, that know how to do it.

These are not eccentric new ideas out of left field. They’ve been around for half a century. They contribute materially to productivity in interactive development.

They’re what sets repl-driven development apart from mere development with a repl.

Now, not every programmer prefers that kind of development. Some programmers prefer to think of development as a process of designing, planning, making blueprints, and assembling parts on a workbench. There’s nothing wrong with that. Indeed, a multibillion-dollar international industry has been built upon it.

But if you prefer interactive development, if it’s more natural to you, then it can make you enormously more productive, not to mention happier in your work.

Interactive development with a proper repl-driven environment is the exception. Most programming is done in other ways.

As a consequence, there are a lot of programmers out there who’ve never even heard of it, who have no idea that it exists. My intuition is that some fraction of those programmers would prefer well-supported interactive programming, and would benefit from it, if they just knew what it was.

Maybe if enough programmers are exposed to that style of programming then we’ll begin to see new tools that embrace it.