It's sometimes said that design in functional languages is done in the interpreter. You try out different ideas, decide on appropriate representations and abstractions for the problem domain, then build a working program on top of them. Back in my Lisp days, that's the way I did things, more or less.

Since then, though, I've fallen in among disreputable companions---programmers in object-oriented languages, specifically those in the Agile school. They argue that you should start with the minimum abstractions required to get that first feature out. As you add new features, you should use your good taste (and refactoring guidelines) to refine and extend the abstractions in the code---abstractions that always match the real problem domain, not your prediction of what it will be.

In my own programming, that approach has worked well, so as I jumped on the Clojure bandwagon, I wanted to use it. In this talk, I will show how it works by building a program.