Functional programming builds programs from pure functions: functions that do nothing except return a result. Updating variables or objects, throwing exceptions, printing, reading input, accessing files or networks, and halting with an error are side effects because they reach beyond that result. The restriction changes program organization rather than expressive power: useful programs can still perform I/O, handle errors, and model change. section 1.0 section 1.5
The central test is referential transparency. A pure expression can be replaced by its result without changing the program’s meaning; the substitution model uses that replacement to reason locally about code. With fewer hidden interactions, pieces are easier to understand, compose, test, refactor, reuse, generalize, and parallelize. section 1.4 section 1.5
A functional design typically follows these moves:
- Return data that describes work instead of performing the work immediately. section 1.1.2
- Keep calculation in a pure core; place interpretation of effects at a thin outer layer. section 1.1.2 section 1.5
- Represent changing state explicitly by accepting a state and returning a result together with its next state. section 6.7
- Build expressive APIs from small, composable data types and functions rather than special cases or implementation APIs. section 7.1
Buying coffee without charging a card
Rather than have buyCoffee submit a payment as part of its work, let it return a Coffee and a Charge. Creating charges is then pure and independently testable. A separate boundary can later process those charges. Multiple purchases can be grouped by credit card and combined, separating reusable business logic from the external payment action. section 1.1.2
class Cafe:
def buyCoffee(cc: CreditCard): (Coffee, Charge) = #1
val cup = Coffee()
(cup, Charge(cc, cup.price)) #2
The listing makes the boundary visible: buying coffee returns a value that records the charge instead of invoking an external payment operation. section 1.1.2
Statelessness does not mean programs cannot model state. A random-number generator or other stateful API can become a pure transition: given the current state, return both a result and the next state. This makes the sequence of changes explicit data, allowing transitions to be composed without relying on mutation. section 6.7
The same philosophy scales from loops to libraries and architecture. Recursion can express iteration; higher-order and polymorphic functions support reusable operations; repeated patterns across parallelism, testing, and parsing motivate common combinators such as map and flatMap. Functional design starts with simple examples, factors out common concerns, and gradually adds complexity. section 2.0 section 7.1 section 8.5
Effects remain necessary at program boundaries, but they need not govern the whole design. A compositional style can be retained even for stream processing and incremental I/O, while a pure core preserves the ability to reason about smaller programs embedded in larger ones. section 15.5 section 1.5
