English for Clojure Developers

Clojure’s functional, REPL-driven style means teams talk about code differently than in mainstream object-oriented languages — the vocabulary of “immutable data,” “pure function,” and “REPL-driven development” carries specific weight. This guide covers the English used when discussing Clojure code with a team.

Key Vocabulary

Immutable data structure — a data structure (vector, map, list) that cannot be changed in place; “modifying” it returns a new structure, sharing unchanged parts of the original for efficiency. “You can pass this map around freely without defensive copies — it’s immutable, so no caller can accidentally mutate what another caller still holds.”

Pure function — a function whose output depends only on its inputs and that produces no observable side effects, making it trivially testable and safe to reorder or memoize. “Pull the side-effecting logging call out of this function — once it’s pure, we can test it with plain input/output assertions instead of mocking anything.”

REPL-driven development — a workflow of evaluating and testing code incrementally in a live REPL session rather than writing code blind and running the whole program to check it. “Don’t guess at what this transformation returns — load the namespace into the REPL and evaluate it against real sample data first.”

Transducer — a composable, reusable transformation (map, filter, etc.) decoupled from the specific collection or process it’s applied to, avoiding intermediate collection allocation. “Instead of chaining map and filter separately over this large sequence, compose them as a transducer so we only walk the data once.”

Namespace — Clojure’s unit of code organization and the equivalent of a module, typically one file per namespace with a dotted, hierarchical name. “This namespace is pulling in half the codebase as dependencies — that’s usually a sign it’s doing too much and should be split.”

Spec — a library and pattern (clojure.spec) for describing the shape of data and function contracts, usable for both validation and generative testing. “Add a spec for this function’s input map — it’ll catch malformed data at the boundary instead of failing three functions deeper with a cryptic error.”

Common Phrases

• “Is this function actually pure, or does it have a hidden side effect we should call out?”
• “Have you evaluated this in the REPL against real data, or is this still untested against the shape we’ll actually see in production?”
• “Would a transducer avoid the intermediate collections here, or is the current chain clear enough to leave as is?”
• “Is this namespace pulling in more than it needs — should we split it?”
• “Should we add a spec here so bad data fails at the boundary instead of downstream?”

Example Sentences

Reviewing a pull request: “This function looks pure at a glance, but it’s reading from an atom internally — worth a comment so the next reader doesn’t assume it’s side-effect free.”

Explaining a design decision: “We used a transducer here instead of threading three separate map/filter calls, since this runs over a multi-million-row sequence and the extra allocations were showing up in profiling.”

Describing an incident: “The bug traced back to a function we assumed was pure — it was quietly reading and resetting a shared atom, so calling it twice produced different results.”

Professional Tips

• Say “pure function” precisely when reviewing testability — it’s a stronger, more specific claim than just “this looks simple.”
• Use “REPL-driven” to describe your workflow when explaining how you validated an edge case — it’s the idiomatic Clojure development style, not an informal shortcut.
• Flag “hidden side effect” explicitly when a function that looks pure touches an atom, ref, or I/O — it’s one of the most common Clojure review comments.
• Name “transducer” specifically when proposing a performance fix for chained sequence operations — it signals the precise mechanism, not just “make it faster.”

Practice Exercise

1. Explain in two sentences why immutable data structures make functions easier to reason about.
2. Write a one-sentence code review comment flagging a function that looks pure but has a hidden side effect.
3. Describe, in your own words, what problem a transducer solves compared to chaining map and filter.