A pure function is an isolated transformation: it takes inputs, returns an output, always gives the same output for the same inputs, and neither modifies nor depends on external mutable state. This makes it referentially transparent: a call can be replaced by its result without changing program behavior. Purity turns behavior into a small, predictable building block whose purpose can be understood without tracing hidden state elsewhere. section 6.1.2 section 1.1.5
Figure 6.1 Pure function illustrated as an isolated transformation: inputs enter the function, and a single output is produced. The function depends only on its inputs and does not interact with external state. As a result, the same inputs always produce the same output.
Use the isolated-transformation model to ask a direct design question: does every result come only from the supplied inputs? section 6.1.2
Pure functions fit naturally into functional pipelines, where data flows through visible transformations rather than through control-flow machinery. A title-processing pipeline, for example, can extract titles, sort them, and collect a result as a readable sequence of operations. Composition allows larger behavior to be assembled from small functions while keeping each step focused. section 6.0 section 6.1.2
A pipeline without hidden mutation
Filtering words by length and mapping the remaining values to uppercase expresses a result-producing transformation. The pipeline is easier to reason about when its operations only derive new values rather than alter shared objects or counters. By contrast, incrementing an outside counter in a lambda, or changing a Book’s title during map, introduces stateful behavior and loses the guarantee of purity. section 6.1.2 section 6.3.4
Immutability supports purity but requires more than declaring a reference final. A final object can still expose mutable internal state; avoiding hidden mutation calls for deeply immutable values, including immutable fields and referenced objects. This matters especially in multiparadigm languages, where functional syntax can discourage mutation without making it impossible. section 6.3.4
Pure functions provide practical engineering advantages:
- Make tests direct: assert an output for an input without mocking external systems or tracking hidden state. section 6.1.2
- Remain naturally thread-safe when they do not rely on shared state. section 6.1.2
- Improve readability and reuse by giving each function one clear, self-contained responsibility. section 1.1.5 section 6.1.2
Purity is a design choice, not a demand to force every operation into a pipeline. Writing files, updating databases, sending network messages, reading the clock, and algorithms built around heavy mutation are necessarily stateful cases. Prefer imperative code when effects are central to the job; when a functional API improves the flow despite impurity, keep the effect explicit rather than hiding it inside a transformation. section 6.1.2 section 6.4
The useful heuristic is to make transformations pure when their job is computation, and isolate unavoidable effects where readers can see and justify them. Purity works best alongside simplicity, expressiveness, and clarity of intent; pursued blindly, it can itself reduce readability or add complexity. section 1.1 section 6.4
