# REPL Driven Development

DevFeed: [REPL Driven Development](<https://devfeed.tech/articles/repl-driven-development-31904.md>)

Original publisher: [Read original article](<http://blog.jayfields.com/2014/01/repl-driven-development.html>)

Author: Jay (noreply@blogger.com)

Published: 2014-01-27T17:53:00Z

Content type: opinion

Language: en

Sources: [Jay Fields](<https://devfeed.tech/sources/jay-fields.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Code](<https://devfeed.tech/topics/code.md>), [Software](<https://devfeed.tech/topics/software.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>)

Tags: [application](<https://devfeed.tech/tags/application.md>), [c-sharp](<https://devfeed.tech/tags/c-sharp.md>), [clojure](<https://devfeed.tech/tags/clojure.md>), [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [emacs](<https://devfeed.tech/tags/emacs.md>), [evaluation](<https://devfeed.tech/tags/evaluation.md>), [expression](<https://devfeed.tech/tags/expression.md>), [java](<https://devfeed.tech/tags/java.md>), [junit](<https://devfeed.tech/tags/junit.md>), [nunit](<https://devfeed.tech/tags/nunit.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [repl](<https://devfeed.tech/tags/repl.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [running](<https://devfeed.tech/tags/running.md>), [software](<https://devfeed.tech/tags/software.md>), [verification](<https://devfeed.tech/tags/verification.md>), [writing](<https://devfeed.tech/tags/writing.md>)

## AI overview

The article explains REPL Driven Development (RDD), a workflow in which developers craft s-expressions, evaluate them immediately in a REPL, inspect the results or apply changes to a running application, and repeat until the problem is solved. The author argues that avoiding application restarts, separate verification tools, and leaving the source enables faster feedback while writing production code.

## Source excerpt

When I describe my current workflow I use the TLA RDD, which is short for REPL Driven Development. I've been using REPL Driven Development for all of my production work for awhile now, and I find it to be the most effective workflow I've ever used. RDD differs greatly from any workflow I've used in the past, and (despite my belief that it's superior) I've often had trouble concisely describing what makes the workflow so productive. This entry is an attempt to describe what I consider RDD to be, and to demonstrate why I find it the most effective way to work. RDD Cycle First, I'd like to address the TLA RDD. I use the term RDD because I'm relying on the REPL to drive my development. More specifically, when I'm developing, I create an s-expression that I believe will solve my problem at hand. Once I'm satisfied with my s-expression, I send that s-expression to the REPL for immediate evaluation. The result of sending an s-expression can either be a value that I manually inspect, or it can be a change to a running application. Either way, I'll look at the result, determine if the problem is solved, and repeat the process of crafting an s-expression, sending it to the REPL, and evaluating the result. If that isn't clear, hopefully the video below demonstrates what I'm talking about. If you're unfamiliar with RDD, the previous video might leave you wondering: What's so impressive about RDD? To answer that question, I think it's worth making explicit what the video is: an example of a running application that needs to change, a change taking place, and verification that the application runs as desired. The video demonstrates change and verification; what makes RDD so effective to me is what's missing: (a) restarting the application, (b) running something other than the application to verify behavior, and (c) moving out of the source to execute arbitrary code. Eliminating those 3 steps allows me to focus on what's important, writing and running code that will be executed in