Functional Programming Guide: Map, Filter, Reduce Explained

Functional programming (FP) is a programming paradigm that treats computation as the evaluation of mathematical functions. It avoids changing state and mutable data. You don't need to abandon Python or JavaScript for Haskell to benefit from FP principles — map, filter, reduce, and pure functions are available everywhere and dramatically improve code quality when used well.

Pure Functions: Predictable and Testable Code

A pure function has two properties: given the same inputs, it always returns the same outputs. It has no side effects — it doesn't modify external state, write to files, or call APIs. Why this matters: pure functions are trivially testable (no mocking needed), parallelizable (no shared state to conflict), and easy to reason about. Compare:

# Impure - depends on external state
total = 0
def add_to_total(x):
    global total
    total += x  # modifies external state

# Pure - same input always returns same output
def add(a, b):
    return a + b

In practice, you can't make everything pure (you need I/O, databases, etc.). The goal is to push side effects to the edges of your program and keep the core logic pure.

Immutability: Data That Doesn't Surprise You

Immutable data doesn't change after creation. In Python, tuples and strings are immutable; lists and dicts are mutable. The functional approach: instead of modifying data, create new data. This prevents bugs where one part of a program unexpectedly changes data another part is using.

# Mutable - modifies the original list
def add_item_bad(items, item):
    items.append(item)  # changes the input!
    return items

# Immutable - returns new list
def add_item_good(items, item):
    return items + [item]  # original unchanged

In JavaScript, use const, spread operators ([...arr, newItem]), and Object.freeze(). Libraries like Immer make immutable updates ergonomic in React/Redux applications.

Map and Filter: Transform and Select

Map applies a function to every element in a collection and returns a new collection of results. Filter selects elements that pass a predicate (a function returning true/false).

# Python examples
numbers = [1, 2, 3, 4, 5, 6]

# Map: double each number
doubled = list(map(lambda x: x * 2, numbers))
# [2, 4, 6, 8, 10, 12]

# Pythonic: list comprehension
doubled = [x * 2 for x in numbers]

# Filter: keep only even numbers
evens = list(filter(lambda x: x % 2 == 0, numbers))
# [2, 4, 6]

# In JavaScript
const doubled = numbers.map(x => x * 2);
const evens = numbers.filter(x => x % 2 === 0);

Reduce: Aggregate a Collection to a Single Value

Reduce (also called fold) takes a collection and a function that combines two values, and produces a single result. It's the most general of the three — map and filter can both be implemented using reduce.

from functools import reduce

numbers = [1, 2, 3, 4, 5]

# Sum using reduce
total = reduce(lambda acc, x: acc + x, numbers, 0)
# 15

# Flatten a list of lists
nested = [[1, 2], [3, 4], [5]]
flat = reduce(lambda acc, x: acc + x, nested, [])
# [1, 2, 3, 4, 5]

# Build a lookup dict from a list
users = [{'id': 1, 'name': 'Alice'}, {'id': 2, 'name': 'Bob'}]
lookup = reduce(lambda acc, u: {**acc, u['id']: u}, users, {})

Function Composition: Build Complexity from Simplicity

Function composition chains small, focused functions into more complex operations. The output of one function becomes the input of the next. In Python, a simple compose function:

from functools import reduce

def compose(*fns):
    return reduce(lambda f, g: lambda x: f(g(x)), fns)

def double(x): return x * 2
def add_one(x): return x + 1
def square(x): return x ** 2

# Apply right-to-left: square first, then add_one, then double
transform = compose(double, add_one, square)
result = transform(3)  # square(3)=9, add_one(9)=10, double(10)=20

In JavaScript, libraries like Ramda and lodash/fp provide compose and pipe utilities. The pipe operator (Stage 3 proposal) will make this native: value |> double |> addOne |> square.

FP in Practice: When and How to Apply It

You don't need to rewrite everything as pure functions. Apply FP selectively where it adds clarity. Good candidates: data transformation pipelines (chain map/filter/reduce instead of imperative loops), utility functions (formatters, validators, converters — these should be pure), React components (pure components with no side effects render predictably), and configuration objects (treat as immutable). Avoid forcing FP where imperative code is clearer: complex business logic with many conditions, performance-critical loops where mutation is faster, code that other developers aren't familiar with FP patterns. The goal is readable, testable code — FP is a means to that end, not the end itself.