Why a “change” creates a new value
In pure functional programming, a counter is treated more like a number on a page than a box whose contents can be overwritten. If a function receives `4` and adds one, it returns `5`; the original `4` remains available. A program that needs the updated count passes `5` onward, making the flow of data explicit.
This style also rules out hidden side effects: a function should not quietly alter a shared variable, file, or other state while appearing to calculate a result. Given the same inputs, a pure function produces the same output. That makes its behavior easier to test and lets programmers reason about one calculation without tracking every earlier change elsewhere in the program.
The practical payoff—and its cost
Immutability is especially useful when several parts of a program work at once. If two tasks read the same value, neither can unexpectedly change it out from under the other. This reduces a common source of concurrency bugs, in which the result depends on which task happens to run first.
Creating a fresh value for every update sounds wasteful, but implementations can often reuse unchanged parts of a data structure rather than copy everything. Even so, functional code can require a different way of thinking: instead of asking “What should I change?”, the programmer asks “What new value should this operation produce?” The old value remains intact, which can make a program’s history and data flow easier to follow. Pure functional programming keeps mutation out of the program’s logic; it does not mean a computer’s memory can never change under the hood.
