Programming Paradigms

Python, JavaScript, Go, Rust, Haskell - these are not different tools. They are different answers to the same question: how is complexity managed? A paradigm is not syntax. It is a model of computation. Rust's ownership system is linear types from a 1970s theoretical paper. Haskell's monads are category theory from 1958. React's immutable state is the same idea John McCarthy put into Lisp in 1958. Everything has already been invented - it just gets renamed and repackaged. Understanding five paradigms means a new language stops being surprising, and starts being recognizable as a rediscovery of an old idea.

• **Rust** = linear types (1970s) + affine type theory. The borrow checker is not a new invention - it is a formal system from academic papers, finally going mainstream. Zero-cost abstractions handle packets at Cloudflare at 1M RPS
• **React/Redux** is the functional paradigm: immutable state + pure reducers. Ideas from Haskell and ML, packaged in JavaScript. Used in products with 100M+ users
• **Apache Spark** uses the functional model (map/flatMap/reduce) to process petabytes of data. The same task in the imperative style would be a synchronization nightmare
• **SQL** is Codd's relational calculus from 1970 plus the logic paradigm of Prolog. Every SELECT is a logical query; the optimizer decides "how" instead of the programmer

Imperative Programming: Step-by-Step Instructions

Ada Lovelace wrote the first program in 1843 for Babbage's Analytical Engine. No abstractions - just a list of arithmetic operations in sequence. That is **imperative programming**: the computer receives a **sequence of commands**, each one mutating memory. In 180 years the syntax has changed. The computational model has not.

**The imperative paradigm** is a programming style in which a program is a **sequence of commands** that mutate state. Key elements: **variables** (memory cells), **assignment** (state change), **loops** (repetition), **branching** (conditionals). A program is a recipe: step 1, step 2, step 3...

**Mutation is the primary source of bugs.** When 5 functions all modify the same variable, tracking down who corrupted the data becomes a detective story. That is precisely why other paradigms emerged - they each try to solve the problem of uncontrolled state mutation.

Declarative Programming: What, Not How

Edgar Codd invented relational algebra in 1970 - and with it an idea that keeps getting reinvented: describe WHAT is needed, not HOW to find it. SQL is the direct descendant. React applies it to UI. Terraform applies it to infrastructure. The **declarative** approach works because it offloads optimization: a SQL query planner explores 50 execution strategies; a developer would explore 2.

**The declarative paradigm** is a style in which the programmer describes the **desired result** and the system figures out how to achieve it. The PROPERTIES of the solution are described, not the steps. SQL, HTML, CSS, regular expressions, React, Terraform - these are all declarative tools.

**Regex** is yet another declarative tool. The expression `^[A-Z][a-z]+$` describes a pattern: "starts with an uppercase letter, followed by lowercase." No loop checking each character is written - the regex engine figures out how to search. HTML describes the **structure** of a page. CSS describes its **appearance**. Terraform describes **infrastructure**. Everywhere the same idea: description, not instruction.

**Declarative code is easier to read and maintain** because it is closer to the problem statement. An SQL query reads almost like an English sentence: "SELECT name, salary FROM employees WHERE department = Engineering". The imperative equivalent requires reading every step just to understand the intent.

Functional Programming: Functions as LEGO Bricks

John McCarthy built Lisp in 1958 on top of Church's lambda calculus. The core idea: a function is a mathematical object, not a procedure. f(x) = x² **always** returns the same result for the same x. No dependency on external world. No side effects. These are called **pure functions** - and the entire functional paradigm follows from this single constraint, which turns out to deliver enormous payoffs for parallelism and testability.

**Functional programming (FP)** rests on three pillars: 1. **Pure functions** - the result depends only on the arguments; no side effects. 2. **Immutability** - data is never mutated; new copies are created. 3. **Functions as first-class citizens** - functions can be passed as arguments, returned from functions, and stored in variables.

**Why does FP simplify testing?** Testing a pure function is straightforward: pass an input → check the output. No mocks, stubs, or environment setup needed. And **immutability** eliminates an entire class of bugs: if data never changes, race conditions on concurrent access become impossible.

**map, filter, reduce** - the three musketeers of FP. `map` transforms each element. `filter` keeps the matching ones. `reduce` folds a collection into a single value. Almost any loop can be rewritten as a combination of these three functions.

OOP: Objects as Small Worlds

Alan Kay built Smalltalk in 1972 with biology as the inspiration: cells encapsulate state and communicate through chemical signals. In his model, an object is not a data container - it is an **autonomous agent** that receives messages and decides how to respond. Data and behavior are inseparable. C++ and Java later reinterpreted this as class hierarchies, and Kay spent decades clarifying that this was not what he meant.

**OOP** combines data and behavior into **objects**. Four principles: 1. **Encapsulation** - data is hidden, accessed through methods. 2. **Inheritance** - a new class inherits the properties of an existing one. 3. **Polymorphism** - one interface, different implementations. 4. **Abstraction** - highlighting the essential, hiding the details.

**Inheritance is not the core idea of OOP.** Many people equate OOP with deep class hierarchies. In practice, experienced developers use inheritance sparingly. The "Composition over Inheritance" principle (Gang of Four, 1994) says: assemble behavior from components, don't inherit from ancestors.

Logic Programming: Facts, Rules, and Inference

Alain Colmerauer built Prolog in 1972 on first-order logic. The radical idea: a program is not an algorithm - it is a **knowledge base**. Facts plus rules. Submit a query, and the system constructs a proof through unification and backtracking. No "how to search" - only "what is true". The same model as SQL, but with recursion, inference, and automatic proof generation built in.

**Logic programming** is grounded in formal logic. A program is a set of **facts** (assertions about the world) and **rules** (logical relationships). **Prolog** (1972) is the primary logic language. The programmer describes WHAT IS TRUE, and the system uses **unification** and **backtracking** to find answers.

**SQL is logic programming too!** `SELECT * FROM users WHERE age > 18 AND city = 'Moscow'` is a logical query: "find all records for which it is TRUE that age > 18 AND city = Moscow". Datalog is a database query language based on Prolog. Many developers use logic programming every day through SQL without realizing it.

Key Ideas

• **A paradigm is a model of computation, not syntax.** Python can be imperative, functional, and OOP - in the same file
• **Imperative**: steps + mutation. Clear to the machine, dangerous for humans - mutation causes 70% of bugs in concurrent code
• **Declarative + Logic**: describe WHAT, the system figures out HOW. A SQL optimizer tries 50 execution plans; a programmer would try 2
• **Functional**: pure functions are a test engineer's dream. No side effects = no ordering dependency = free parallelism
• **OOP**: Kay's real idea was message passing, not hierarchies. Gang of Four said "prefer composition over inheritance" in 1994 - 30 years later it's still ignored
• **Rust ownership, Haskell monads, React reducers** - all are old academic ideas with new names. Understanding paradigms means reading between the lines of any new language

Related Topics

Programming paradigms are the entry point into programming language theory:

• Type Systems — Each paradigm uses types differently: OOP uses nominal typing, FP uses algebraic data types, logic programming uses terms.
• Lambda Calculus — The mathematical foundation of functional programming: any computable function can be expressed via λ-abstraction.
• Compilers — A compiler translates declarative or functional code into imperative machine instructions - a bridge between paradigms.

Вопросы для размышления

• Consider a recent project. Which paradigms were used? Most likely at least two - which ones, and why?
• In designing a GPS navigator, which paradigm fits each part best: route finding, map rendering, voice command processing?
• Why are most modern languages (Python, Kotlin, Rust, Swift) multi-paradigm? Can a "pure" paradigm cover all the needs of a real-world project?

Связанные уроки

• comp-01-intro — Understanding paradigms helps see how compilers handle different coding styles
• plt-02-type-systems — Type systems are built on top of paradigms: functional → type inference, OO → polymorphism
• fl-01-intro — Formal languages explain the mathematical foundations of logic and functional paradigms
• dm-01 — Logic programming (Prolog) is executable discrete mathematics
• comp-04-interpreter-vs-compiler