REPL Driven Programming

I’ve written many times about what I call “exploratory” or “interactive” programming. The idea is you build your program from the bottom up, trying out expressions, building them into larger and larger units until you have a whole program. For me, the quintessential example of this is Kris Jenkins’ video on writing an Emacs Spotify client in 16 minutes. If you haven’t seen it or you’re the least bit confused about what I mean when I talk about exploratory programming, be sure to take a look. You won’t, I promise you, regret the 16 minutes you spend on it.

The other day, I saw a citation, I don’t remember where, for Mikel Evins’ post On repl-driven programming. By “REPL driven programming” he means what I call exploratory programming. His post was in response to someone asking how Python or Ruby REPLs are different from those in Lisp or Smalltalk and why Lisp’s and Smalltalk’s versions are better.

The TL;DR is that with Python, etc. you can do some things in the REPL but with Lisp and Smalltalk you can do everything. That means, in particular, that you can build and simultaneously debug your program right from the REPL as Jenkins demonstrates in his video. Notice that Jenkins never really “types in” his program. He just builds it up in the REPL1.

Evins’ discussion is mainly centered around Common Lisp and he goes on to describe how a run time error in Common Lisp drops you into “breakloop”, which is a parallel REPL in which the context of the running application is available. That means that you examine and fix the code and resume the computation where it left off. If you want to know what’s so great about the Lisp REPL, take a look.

Footnotes:

1

Jenkins isn’t technically using the REPL. He’s typing expressions into his buffer and then executing them with Ctrl+x Ctrl+e, which is essentially the same thing.

This entry was posted in General and tagged , . Bookmark the permalink.