Understand Functional Programming visually
Explore each concept's architecture through animated diagrams. Click a card to dive deeper.
순수 함수
Deterministic side-effect-free function
A pure function is a function whose output depends only on its arguments and which causes no observable side effects. Given the same inputs, it will always return exactly the same value, and nothing outside the function changes as a result of calling it. In functional programming, pure functions are the smallest unit of logic you can reason about in isolation. The more of a system's core behavior you can keep pure, the easier it becomes to explain, test, and rearrange.
불변성
Non-mutating value updates
Immutability means that once a value is created, it is never changed. Instead of mutating an existing object or array, every update produces a new one. The original remains intact and any code still holding a reference to it sees the same value it always did.
일급 함수
Functions treated as values
First-class functions mean a language treats functions as values. A function can be assigned to a variable, passed as an argument, returned from another function, or stored in an array or object — the same way any other value can.
고차 함수
A function over other functions
A higher-order function is a function that either accepts another function as an argument, returns a function as its result, or both. This is distinct from ordinary functions, which only work with data values. Higher-order functions are only possible in languages where functions are first-class values.
클로저
A function with captured scope
A closure is a function that retains access to the variables of its enclosing scope even after the outer function has finished executing. The inner function does not copy those variables -- it holds a live reference to them, so reads and writes affect the same binding that the outer scope created.
함수 합성
Functions chained into one pipeline
Function composition is the practice of combining two or more functions into a new function by wiring the output of one directly into the input of the next. Instead of writing a long procedure with many intermediate variables, you describe the transformation as a sequence of named steps, and a compose or pipe utility connects them automatically.
map/filter/reduce
Core collection transform operators
map, filter, and reduce are higher-order functions built into most functional and multi-paradigm languages. They express the three most common things you do with a list: transform each item, keep only some items, or fold all items into one value.
재귀
Self-calls over smaller inputs
Recursion is a technique where a function solves a problem by calling itself with a simpler version of the input, repeating until it reaches a base case that can be answered directly. The results from smaller calls are then combined to produce the answer for the original input.
커링
A unary chain from many arguments
Currying is the technique of transforming a function that takes multiple arguments at once into a sequence of functions that each take exactly one argument. Instead of calling `f(a, b, c)`, you call `f(a)(b)(c)`. The payoff is not novelty in the call syntax. The payoff is that each intermediate result is itself a function of one argument, which makes it easy to reuse, compose, and partially apply in a functional pipeline.
부분 적용
A specialized function with preset arguments
Partial application is the technique of pre-filling some of a function's arguments and producing a new function that accepts only the remaining ones. A function like `(locale, currency, amount)` becomes a more focused function like `(amount)` once the locale and currency have been fixed. The point is not merely to save typing. The point is to move stable configuration out of the call site so the remaining function better matches the job it is actually used for.
지연 평가
Deferred computation on demand
Lazy evaluation is the strategy of not computing a value at the moment it is defined, but instead delaying the computation until the value is actually needed. The expression is stored as 'work to do later,' and execution happens only when some consumer demands the result. That change in timing is powerful. It lets programs describe infinite sequences, skip unused branches, and avoid paying for the full cost of a pipeline when only part of the output is consumed.
Maybe/Option
An explicit optional value type
Maybe/Option is a sum type that says a value may be present or absent. If the value exists, it is wrapped as `Some value` or `Just value`; if it does not, the value is `None` or `Nothing`. The important shift is that absence stops being a hidden exceptional condition and becomes an ordinary case in the data model. A caller can see from the return type itself that emptiness is part of the normal contract.
Either/Result
A success-or-failure value type
Either/Result is a sum type that models a computation which may succeed or fail. A successful outcome is represented as `Ok value` or `Right value`; a failed outcome is represented as `Err error` or `Left error`. The key idea is that failure is not thrown outside the function as hidden control flow. It stays inside the returned value, which means the function signature can honestly describe both the happy path and the error path.
ADT
A closed model of valid shapes
An ADT, or algebraic data type, models a value as one of a closed set of shapes, where each shape carries exactly the data that belongs to it. The word algebraic refers to the two ways those shapes are assembled: products and sums. A product type groups fields that exist together, like a record or struct. A sum type lists alternative variants, where the value can be exactly one of them. ADTs combine those two ideas so the type itself states which states are valid and what data each state contains.
패턴 매칭
Branching by shape while unpacking data
Pattern matching branches on the concrete shape of a value and, at the same time, binds the data inside that shape to local names. Instead of separately checking a tag and then manually digging payload fields out on the next line, one construct does both jobs. In functional programming this matters because values are often modeled as ADTs. Once the data is designed as distinct variants, pattern matching becomes the natural way to consume it. It is less a fancy control structure than the control-flow counterpart to value-oriented modeling.