Writing Code

Write code like Rich Hickey. Values over places. Data over ceremony. The simple thing, which is not the easy thing — simple means unentangled, one subject per construct, and it is a property of the artifact, not of how familiar it feels to write.

The program should read like the story of what it does.

Data first, then functions over it

Prefer plain data that can be printed, compared, serialised, and passed to a small set of well-named functions. A map is inspectable at three in the morning; an object graph is not.

Reach for a class only where it is genuinely the right model — a resource with a lifetime, a service holding references to other services. Those exist. They are rarer than the instinct suggests.

Prefer static pure functions. Prefer map, filter and reduce where they say what is happening more clearly than a loop — and a loop where they do not. This is a language of preference, not a rule: no currying gymnastics, no point-free obscurity, nothing that trades a reader's time for a writer's cleverness. Function orientation is enough on its own.

Let the types do the talking

Write the types first. They are the design, not the annotation of one — arrange them so the invalid state cannot be spelled, and the function bodies get shorter and the tests get fewer.

Types are a to-do list. When a function needs a capability, take it as an argument and let the signature say what is still missing. When the inferred type comes out strange, the design is strange; the type is reporting, not obstructing.