Aggregating Data with `reduce`

reduce is the function you reach for when many inputs must become one result.

That result might be:

• a number
• a map
• a set
• a vector
• any other accumulated value

For Java developers, the safest mental model is:

reduce replaces the loop that keeps updating one accumulator.

What reduce Does

reduce repeatedly combines:

• the current accumulator
• the next item in the collection

until one final result remains.

1(reduce + 0 [1 2 3 4])
2;; => 10

The reducing function must know how to take:

• the accumulated result so far
• the next item

and return the new accumulator value.

Why It Feels Different From A Java Loop

In Java, this is often written as a loop that mutates a local variable.

In Clojure, the accumulator is still there, but it is explicit in the function call rather than hidden in mutable control flow.

The conceptual improvement is that the aggregation rule becomes a named function contract rather than scattered loop mechanics.

Start With The Initial Value

One of the most important design choices in reduce is the initial accumulator.

1(reduce + 0 amounts)

That 0 is not decoration. It tells the reader:

• what kind of result is being built
• what the empty-case starting point is

The same idea applies to other accumulator shapes:

Choosing the initial value well makes the reduction easier to understand and safer on empty collections.

A Realistic Example: Totals by Status

Suppose you want to count orders by status.

1(defn count-by-status [orders]
2  (reduce (fn [counts {:order/keys [status]}]
3            (update counts status (fnil inc 0)))
4          {}
5          orders))

This is a good reduce example because the whole job is “walk the collection and keep updating one summary value.”

The accumulator here is a map, not a number. That is the key lesson:

reduce is about aggregation, not just arithmetic.

Another Example: Build A Lookup Map

1(defn orders-by-id [orders]
2  (reduce (fn [acc order]
3            (assoc acc (:order/id order) order))
4          {}
5          orders))

This is often easier to reason about than an imperative loop that mutates a temporary map.

When reduce Is The Wrong Tool

Do not use reduce just because it is powerful.

Java developers sometimes overuse reduce because it looks “more general.” That is true, but not always helpful. If a map or filter says the job more directly, use the clearer tool.

A Good Reducing Function Has One Clear Job

A reducing function should answer one question:

how does the next item update the accumulator?

1(defn add-billable-hours [total entry]
2  (if (:time-entry/billable? entry)
3    (+ total (:time-entry/hours entry))
4    total))
5
6(reduce add-billable-hours 0 entries)

That separation helps because:

• the accumulator shape stays obvious
• the update rule is easy to test
• the collection traversal stays out of the business logic

Common Early Mistakes

reduce And Pipeline Design

Many readable pipelines end with reduce:

1(->> orders
2     (filter :order/paid?)
3     (map :order/total)
4     (reduce + 0M))

That reads naturally:

• choose the relevant orders
• extract the values you care about
• combine them into one total

This is often clearer than trying to force all three ideas into one large reducing function.

Knowledge Check