Where these ideas already live in your everyday code, named at last

React's own domain taught that components should be pure functions of their props, and that state updates should never mutate the existing state object directly — both are this domain's lesson 1 and lesson 2, applied specifically to UI. React's reconciliation algorithm (deciding what actually changed between renders) depends structurally on immutability: comparing old and new state efficiently requires being able to trust that "if it's the same object reference, nothing inside it changed," which is only true if updates never mutate in place.

JavaScript's own array-methods lesson taught .filter(), .map(), and .reduce() as practical tools — this domain's lessons 3 and 9 named what makes them distinctive: each is a higher-order function, and .map() specifically is the Functor pattern, transforming values inside a container without ever requiring the caller to manually unwrap, loop, and rebuild the list by hand.

Lesson 10 named this directly: chaining .then() calls, each of which can return another Promise that gets automatically flattened rather than nested, is a monad's flat_map by another name. Anyone who has debugged a Promise chain has already been reasoning about monadic composition, whether or not that word ever entered the conversation.

Lesson 8's Option and Result types aren't an exotic, purely academic construct — Go's entire error-handling philosophy (this curriculum's own Go domain) is a language-level instance of the exact same idea, and TypeScript's discriminated unions let any codebase build the same guarantee by hand, in a language that doesn't enforce algebraic data types natively.

Lesson 7 drew the direct line: @lru_cache and Caching Strategies' own lessons on TTLs and invalidation are solving the same underlying problem (avoid recomputing/refetching something expensive) for two different categories of thing — a referentially transparent pure function's result, versus data that can genuinely change independently of a function's own arguments. Confusing the two — memoizing something that isn't actually referentially transparent — is precisely the silent staleness bug lesson 7 walked through concretely.

None of functional programming's core ideas were introduced to this curriculum for the first time in this domain — pure functions, immutability, .map(), Promises, Go's explicit errors were all already present, scattered across five or six other domains, each time presented as a specific feature of that specific language or framework rather than an instance of one coherent underlying paradigm. This domain's actual contribution is connective, not inventive: naming the pattern once, clearly, so that recognizing it the next time it appears — in a new language, a new library, a new codebase — takes genuine recognition instead of feeling like yet another unrelated thing to learn from scratch.