‹ BackHN Continuity

Thread

Anecdotally, programmers dislike "reduce"

175 points · 283 comments · vinhnx

  1. rspeele · · focus · HN ↗
    Map and filter usually have only one arg and if they have 2, the 2nd is almost always a 0-based index. They look identical in most languages, even when Microsoft chooses to call them Select and Where.

    Reduce has an accumulator and a 2-arg function and languages are not very consistent amongst each other as to whether it's reduce(initial_acc, callback(acc, elem)) or reduce(callback(acc, elem), initial_acc) or reduce(callback(elem, acc), initial_acc) or what.

    Hard to remember. Also some languages have a version of reduce that doesn't take an initial accumulator at all, which is just a footgun waiting for you to hit an empty collection. Also ALSO, the accumulator can easily become awkward in languages that don't support anonymous types or don't support easy mutation of an anonymous type record. Which is most of them!

    1. mamcx · · focus · HN ↗
      Also reduce is a weird name.
      1. ingonealan3 · · focus · HN ↗
        Why? It does, after all, reduce a collection to a single value.
        1. karmakurtisaani · · focus · HN ↗
          I suppose it's just so ... reductive, you know?
        2. [deleted] · · focus · HN ↗

          [deleted]

        3. ketzu · · focus · HN ↗
          The resulting value can be anything you want. You can turn a list into a tree, or another list.

          Bad example:

              reduce(lambda x,y: x+x.extend([y+2,y*2,y**2]), [1,2,3,4], [])
          
          Reduces the list to another list three times as long.

          It's a reduction in the sense of a transformation (also often seen in complexity theory), not in the "this makes this smaller" everyday usage that I think about first.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.