Declarative programming flips the question from how to what: you describe the result you want and let the system figure out the steps needed to produce it.1
Families of declarative code
Declarative is a broad umbrella. Functional programming is one family — you describe transformations, not state changes.1 Beyond it:
- Query languages — SQL declares what rows you want; the database plans how to fetch them, never telling the engine which index to scan.
- Logic programming — Prolog states facts and rules, then poses queries, and the engine searches for solutions that satisfy them.
- Markup and config — HTML, CSS, and infrastructure tools declare a desired structure or end-state rather than a procedure.
- APIs — a REST request declares the resource you want, leaving the server to fulfil it.
Trade-offs
Declarative code is often shorter and harder to get subtly wrong, because there are fewer moving parts of explicit state to manage. The cost is giving up fine control over execution: when a SQL query is slow or a constraint solver picks a poor path, you may need to peek behind the abstraction to understand what it generated.
Versus imperative
The clean contrast is with imperative programming, which spells out an ordered sequence of state changes. Reach for declarative style when what you want is clearer than how to get it — querying data, describing infrastructure, or expressing rules — and reach for imperative when you need precise control over each step.1
Sources
-
Declarative programming — Wikipedia, for the what-not-how definition and the functional, logic, query, and configuration families. ↩ ↩2 ↩3