Also known as: functional programming "FP"

Functional programming (FP) treats computation as the evaluation of functions, ideally pure ones — functions that always return the same output for the same input and have no side effects.¹

Data flows through a pipeline of pure functions, each producing a new value rather than mutating shared state.

Core ideas

Pure functions are easy to test, reason about, and run in parallel, because they cannot interfere with each other. FP favours immutable data, higher-order functions (functions that take or return other functions), and composing small transformations into pipelines — map, filter, and reduce are its everyday vocabulary.¹ Because pure code has no hidden state to corrupt, it sidesteps an entire class of bugs and meshes well with concurrency.

The mutable-vs-pure axis

FP contrasts sharply with imperative programming, which says “change this variable, then that one.” Functional code instead says “produce a new value from old values.” FP is one branch of declarative programming: you describe transformations rather than spelling out step-by-step state changes. This makes it a natural fit for dataflow problems where each stage is a clean transformation.

In practice

Lisp is the original functional language; Haskell is purely functional, while Clojure, Elixir, and Scala lean functional. Most mainstream languages — Python, JavaScript, and others — now offer functional tools alongside object-oriented features, so the paradigm is usually a style you choose per piece of code rather than a whole language you adopt.¹

Sources

1. Functional programming — Wikipedia, for the definition, pure functions and immutability, and the map/filter/reduce vocabulary. ↩ ↩² ↩³

See also

• Imperative programming
• Declarative programming
• Object-oriented programming
• Abstraction
• Concurrency vs parallelism
• LISP
• Python

Learn it step by step

• Paradigms & language families