‹ BackHN Continuity

Thread

Anecdotally, programmers dislike "reduce"

175 points · 283 comments · vinhnx

  1. ggorlen · · focus · HN ↗
    Reduce is a good illustration of the principle of least power[1]: it's powerful, flexible, general and low-level and can technically achieve any combination of summation, map, filter, find/includes, some/any/every, etc. But reduce is misused if it's reimplementing patterns available in higher-level form.

    In cases when reduce is required because (for example) JS doesn't have a sum function, it should be kept simple. `arr.reduce((acc, el) => el + acc, 0)` is acceptable if lodash _.sum() is not available.

    In cases when reduce is required because the higher-level operations like map/filter aren't flexible enough, decompose the reduction operation into simpler steps and use map/filter with multiple passes, or write a traditional for..of loop.

    This principle also explains why enhanced/range/of loops are preferred over counter-based `for` loops, and counter-based loops over `while`. Technically all loops can be handled by `while`, but it's seldom needed because enhanced loops handle the common case with the cleanest syntax. Reduce/while/counter-based `for` loops are antipatterns where higher-level, less powerful abstractions exists.

    [1]: <a href="https:&#x2F;&#x2F;wiki.c2.com&#x2F;?PrincipleOfLeastPower" rel="nofollow">https:&#x2F;&#x2F;wiki.c2.com&#x2F;?PrincipleOfLeastPower

    1. timtas · · focus · HN ↗
      The reason to prefer reduce over for or while loops is because procedural loops mutate state defined in higher scopes in the program, making reasoning harder and introducing all kinds of opportunities for tricky bugs.

      I like reduce, and I’ve never gotten pushback for using it. I’d be willing to use other functional method chains. But I would never listen to anyone who suggested using a procedural loop instead.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.