Don't Panic — Declarative Programming

Declarative programming means stating a result, relationship, or desired state and allowing an engine to work out much of the route. The work still happens. It has merely acquired an optimizer, controller, or compiler, which is help of a rather opinionated kind.

Keep the control boundary in view. Imperative code describes operations and their order. Declarative code describes what must hold while the engine decides much of the ordering, search, or evaluation. A SQL query requests rows; it does not bring a tiny database crew and dictate the access path.

A declaration can be an expression, query, rule, constraint, dependency graph, or desired-state object. A CSS rule waits for matching elements. A Make rule waits for prerequisites. A Kubernetes object waits for a controller to compare desired and observed state. The variety is real, but every form leaves some decisions to an engine.

The surprise is that compact declarations can still be expensive, risky, or wrong. A database can select an unexpected plan. A configuration change can replace a resource. A rule can lose through precedence. The declaration has not failed; it has delegated decisions that still need inspection.

Use three views. Read the declaration for intent. Inspect the execution plan for engine interpretation. Check observed output or state for reality. Testing a result or invariant is safer than demanding one hidden sequence of steps, which is a fine way to debate an optimizer that was never given voting rights.

Read the intro for the full map. Use the slides when the control boundary needs a picture. Keep the cheatsheet nearby when reviewing intent, plan, and reality. The practice reference turns the idea into a PostgreSQL query and an EXPLAIN plan, where engine choices become visible.