Mr. Grummel Get the app
← All notes
LEARNING 5 MIN READ DRAFT — MARCH 2028

The programming style that treats a function like a maths function, not a set of instructions

Functional programming treats computation as evaluating pure functions that always return the same output for the same input, making a program's behaviour far easier to reason about in isolation.

Functional programming, a genuinely different style from object-oriented programming, treats computation as the evaluation of pure functions, ones that always return the same output given the same input and don't change any state outside themselves along the way. That discipline, no hidden side effects, no mutable shared state, makes a functional program's behaviour dramatically easier to reason about and test in isolation than code that freely reads and modifies state scattered elsewhere in the program.

Pure functions and immutability are the discipline's two core commitments

A pure function's output depends only on its own inputs, calling it twice with the same arguments always produces the same result, and calling it produces no observable side effect, it doesn't modify a variable somewhere else, write to a file, or change any shared state a different part of the program might be relying on. Functional programming pairs that with immutability, once a piece of data is created it isn't changed in place, instead a new, separate version is produced whenever a change is needed, which is a genuinely different default from the mutable variables imperative and object-oriented code typically relies on.

That discipline pays off most clearly in reasoning, testing and parallel execution

A pure function can be tested completely in isolation, since its behaviour depends on nothing but its own inputs, there's no need to set up and tear down some larger surrounding program state just to verify it works. The same property makes parallel execution considerably safer, since there's no shared mutable state for two simultaneously running pieces of code to race over and corrupt, a persistent source of genuinely hard-to-debug errors in code written in a more traditional, stateful style.

Functional programming, distinct from object-oriented programming, treats computation as the evaluation of pure functions, ones that always return the same output for the same input and don't change any state outside themselves, and that discipline makes a functional program's behaviour dramatically easier to reason about and test in isolation.

What we're still unsure about

That pure functions and immutability make code easier to test in isolation and safer to parallelise is a well established, broadly accepted technical claim within computer science. What's more genuinely a matter of ongoing, practical debate among working programmers is whether a strictly functional style is actually more productive and maintainable for large, real-world software systems, mainstream production code still overwhelmingly mixes functional techniques into otherwise object-oriented or imperative programs rather than committing fully to either paradigm, and that mixed reality reflects a genuinely unresolved, not just academic, disagreement about where functional programming's benefits are actually worth its costs.

This sits inside Functional Programming Concepts, one of eight topics in Programming, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.

Draft — not published yet.
Try the pop quiz