In many software development environments, the use of the 'reduce' function—a versatile tool for collapsing a collection into a single value—often triggers negative feedback during code reviews. While developers frequently use 'map' and 'filter' without much scrutiny, 'reduce' is often flagged as being 'hard to read' or less elegant than its counterparts.
The Social Phenomenon of 'Reduce' Avoidance
Evan Hahn reports that while he uses 'map' and 'filter' constantly without peer complaints, his use of 'reduce' frequently results in feedback that the code is difficult to read. He suggests this may be due to 'reduce' being less familiar, harder to read, or less elegant in languages like JavaScript, Python, and Swift.
Hahn notes that this trend may be a social phenomenon rather than a technical failure, though he acknowledges that in functional programming environments like Clojure, this feedback is significantly less common. He observes that even when he prefers 'reduce', he often reverts to other methods to satisfy the social expectations of the code review process.
Cognitive Load and Reasoning Patterns
Commenters on Hacker News argued that 'map' and 'filter' are preferred because they allow for local reasoning, where the output of a single element is independent of others. In contrast, 'reduce' (or 'fold') forces a developer to reason globally about the state of an accumulator as it evolves through the entire collection.
One commenter noted that 'reduce' adds mental overhead by requiring the developer to 'conjure up' a zero value or initial state for the relevant type. Others pointed out that in imperative languages, 'reduce' often provides little benefit over a standard 'for' loop but introduces more complex syntax, making it a 'loop with worse syntax.'
Inconsistency and Implementation Trade-offs
A significant hurdle for 'reduce' is the lack of consistency across programming languages. Commenters noted that different languages vary on whether the accumulator is the first or second argument in the callback, or whether the function takes an initial value at all. This inconsistency makes 'reduce' a 'footgun' where an empty collection might cause a crash if no initial value is provided.
The discussion also highlighted performance risks, such as the O(n^2) complexity of string concatenation within a 'reduce' function in Python. One commenter shared a historical anecdote where 'reduce' was demoted to a library function in Python 3 because it caused a production incident involving a line-wrapping algorithm that exhausted thread pools due to quadratic time complexity.
The Principle of Least Power
The 'Principle of Least Power' is cited as a reason to favor higher-level abstractions. Because 'reduce' is so powerful and general, it can technically achieve almost any collection transformation, but it is often misused to reimplement patterns that already have dedicated, more readable functions.
The consensus among several commenters is that if a higher-level operation like 'map' or 'filter' is not flexible enough, it is often better to decompose the operation into multiple simpler steps or use a traditional loop rather than reaching for 'reduce' to do everything at once.
Uncertainties and Subjective Preferences
The evidence for the 'dislike' of 'reduce' remains largely anecdotal, as there is no quantitative data provided to measure the frequency of these complaints in professional code reviews. Furthermore, the 'correct' choice often depends on the specific language and the developer's familiarity with functional programming concepts.
While some developers find 'reduce' to be a 'hammer/nail' method that simplifies complex logic by moving implementation away from the call site, others maintain that the lack of transparency in how the reduction is executed makes it a less safe abstraction than 'map' or 'filter.'