Programming Paradigms

A programming paradigm is an overall style for organizing code, and the same `calculate_total_size` function built up across this series can be written in any of these four styles without changing what it actually computes, only how that computation is structured. Procedural programming is the style this entire series has used so far: a sequence of function calls that run top to bottom, operating on data passed into them, the same way `calculate_total_size` takes a folder in and returns a number out, with no memory of anything between calls. Object-oriented programming instead bundles data and the functions that operate on it together into one unit, generalizing the records already implied by data structures: a `Folder` object would hold its own cached size as internal state and expose a method like `.get_size()` that updates and returns it, which is useful whenever a program needs to track many independent things that each carry their own data, like dozens of folders each needing their own size tracked separately. Functional programming goes the opposite direction from objects: it avoids stored, changing state entirely and builds programs out of pure functions that always return the same output for the same input and never modify anything outside themselves — a functional version of `calculate_total_size` would use recursion instead of a loop with a mutable running total, adding the current file's size to the result of calling itself on the rest of the folder, which makes the function's correctness far easier to reason about and prove in exactly the sense covered in algorithm analysis, since there is no shared mutable state on the heap for two different parts of a program to disagree about. Event-driven programming organizes code around responding to things that happen rather than a fixed top-to-bottom sequence: a terminal shell waiting for a typed command, covered early in this series, is already event-driven in spirit, and a real file-management application built this way would register a handler that recalculates a folder's size automatically whenever a file is added or removed inside it, rather than running the calculation once and being done. None of these four paradigms is strictly better than the others, and most real programs mix them: a file-management tool might represent folders as objects, respond to file changes in an event-driven loop, and lean on small pure functions for the parts that transform data without side effects — the paradigm is a tool chosen per problem, and recognizing which style a piece of code is already using is often the fastest way to actually understand it.

What does the program need to manage?
a sequence of steps, state, predictable transformations, or reacting to events
Procedural
functions run top to bottom on passed-in data
Object-oriented
data and its functions bundled together as state
Functional
pure functions, no stored or changing state
Event-driven
handler functions fire when something happens
Most real programs mix styles by problem, not by rule
recognizing the style in use is often the fastest way to read code
Same Folder Size, Two Different Shapes Procedural: a function acts on data passed in Procedural calculate_total_size(folder) takes the folder in, hands a number back out no memory between calls, the caller keeps the result Object-oriented: state lives inside the object Object-oriented Folder object holds its own cached size folder.get_size() reads its own state the caller never recomputes it, the object remembers for itself same answer, two different places the state actually lives
Functional vs. Event-Driven No changing state at all, vs. nothing but reacting to change Functional file size + recurse on the rest same folder, same answer, every single time nothing outside the function is read or changed easy to reason about and prove correct Event-driven event loop file added file removed waits, does nothing, until something happens a shell waiting on a command is already this same idea a real program often uses pure functions inside an event-driven loop

Take programming paradigms further

Ask the copilot about this term, or have our engineers assess it against your process.