The REPL Workflow

Clojure programmers don't write a whole file, run it, and read the output. They keep a REPL (Read–Eval–Print Loop) running and evaluate small pieces of code as they write them. This is called REPL-driven development.

A REPL session

user=> (+ 1 2)
3
user=> (def x 10)
#'user/x
user=> (* x x)
100
user=> (doc inc)
-------------------------
clojure.core/inc
([x])
  Returns a number one greater than num. Does not auto-promote
  longs, will throw on overflow. See also: inc'
nil

• Each value is printed as data (strings with quotes, vars as #'user/x).
• doc shows a function's documentation; (source name) shows its code, and (apropos "partial-name") searches for functions.
• *1, *2, *3 hold the last three results, and *e the last exception.

The workflow in an editor

1. Start a REPL for your project from the editor (Calva: "Start a project REPL and connect").
2. Write a function in your source file.
3. Put the cursor on it and evaluate it (Calva: Ctrl + Enter) — the running program now has the new definition.
4. Try it right below, in a rich comment block:

(defn greet [name]
  (str "Hello, " name "!"))

(comment
  (greet "Ada")        ; evaluate this form in the editor
  (greet "REPL")
  )

(println (greet "file"))

Hello, file!

(comment ...) ignores everything inside and returns nil, so the experiments stay in the file without running when the file loads.

5. Change the function, re-evaluate it, try again. The program never restarts.

Why it matters

• Feedback in milliseconds instead of seconds or minutes.
• You can inspect real data from a running system — a database result, an HTTP response — and write the code that handles it against that data.
• Small pure functions are easy to try in isolation, which nudges you toward good design.

Throughout this course, examples are shown as files with println so that the output is explicit, but you'll learn fastest by typing them into a REPL.