Pure function

A pure function must satisfy two conditions. First, it is deterministic: the result depends only on the explicit arguments, not on any hidden state. Second, it has no side effects: it does not modify any variable outside its scope, perform I/O, throw exceptions, or alter the state of an object passed by reference. These properties make pure functions referentially transparent, meaning any call can be replaced by its computed value without changing the program's behavior. For example, in JavaScript, const add = (a, b) => a + b; is pure, whereas let count = 0; const inc = () => count++; is impure because it mutates count.

Pure functions enable better testing: because they are deterministic, unit tests are straightforward and do not require setting up global state. They also facilitate parallelization and memoization—since the same input always yields the same output, results can be cached safely. In large codebases, pure functions reduce bugs caused by unintended side effects and make the code easier to reason about. Functional programming languages such as Haskell enforce purity by default, while others like Scala and Clojure encourage it.

While purity is often associated with functional languages, imperative languages can also benefit from writing pure functions—for instance, in JavaScript's Array.prototype.map and filter are pure if the callback is pure. However, I/O operations are inherently impure, leading to the concept of monads in Haskell to isolate side effects. Another lesser-known detail is that exception throwing is considered a side effect, so pure functions avoid exceptions altogether; they instead return error values or use monadic error handling. The term "pure function" was popularized in the 1970s by John Backus in his Turing Award lecture "Can Programming Be Liberated from the von Neumann Style?"¹ where he argued for functional programming's benefits.

Pure functions are closely related to referential transparency and immutability. A function that mutates its arguments or global state breaks referential transparency. In mathematics, all functions are pure by definition—they are simply mappings from inputs to outputs. In computer science, however, implementing a pure function requires language support or disciplined coding. Recursive functions can be pure if they do not rely on mutable state. The concept is also central to lambda calculus, the theoretical foundation of functional programming.

Referential transparency

An expression is referentially transparent if it can be replaced with its value without affecting the program's behavior.

Side effect

Any modification of state or interaction with the outside world (e.g., I/O, mutation, exception) that is observable outside the function.

Monad

A design pattern used in functional programming to encapsulate side effects while preserving purity.