Thread

Anecdotally, programmers dislike "reduce"

175 points · 283 comments · vinhnx

Loading the complete thread in the background. This saved snapshot is available now. Refresh

Skeime · 1789373345 · focus · HN ↗
I think this is because in an imperative language, `reduce` does not actually give you much over a `for item in collection` loop. With `map` and `filter`, you immediately learn something about the result (it's a list of the same length as the original, with each item only depending on the corresponding original item; it's a list containing some of the original elements unchanged and nothing else). This is useful, so `map` and `filter` are good.
With `reduce`, the result could be anything, and in an imperative language, side effects are also possible. So it's just a loop with worse syntax.
(Admittedly, in an imperative language, `map` and `filter` could also have side effects, though I think most people would consider this bad style.)
1. Hackbraten · 1789377008 · focus · HN ↗
  I think that in every imperative language that offers `map`, `filter`, `reduce`, or similar, the written contract of this API should state that any higher-order function handed to it as an argument must be free from side effects.
  I think I’ve seen several language core APIs have this in their contract, e.g. `Stream#reduce` in Java [0] (emphasis mine):
  > accumulator - an *associative, non-interfering, stateless* function for combining two values
  [0]: <a href="https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#reduce-T-java.util.function.BinaryOperator-" rel="nofollow">https://docs.oracle.com/javase/8/docs/api/java/util/stream/S...
  1. Someone · 1789384046 · focus · HN ↗
    [delayed]
  2. Skeime · 1789389223 · focus · HN ↗
    I mean, most of the code that I write would be side-effect free anyway. In an imperative loop, this would also be true except for updating local variables. If this is the case, `reduce` really is the same as a loop over a collection, except that the names for the state passed between iterations come out better. In the `reduce` version, you can name the parameters to the reducer, but often not the return values. As a reader, one needs to connect the return values to the parameters by position.
    (Note that by "loop over a collection", I explicitly mean a looping construct that gives the elements of the collection directly, instead of looping over indices and extracting the elements manually.)
  3. speedstyle · 1789392718 · focus · HN ↗
    In Rust these specifically take `FnMut`, a function which can update internal/borrowed state, rather than `Fn` which can't easily. In `map` or `filter` you can't rely on the iteration order so that's rarely useful – maybe something 'logically' stateless but which needs a mutable connection/threadpool/cache/etc, or something like a counter which is really a second reduction. There's even `inspect` which is explicitly for side effects. In `fold`, the order is guaranteed and you could use it for a state machine, a fiddly `zip` with other mutable iterators, etc – something you need to perform the reduction, but which isn't really an output, I think you could reasonably write either
    .fold(init, move |acc, x| {…}) // or .fold((state, init), |(state, acc), x| {…}).1
  4. KPGv2 · 1789660594 · focus · HN ↗
    > I think that in every imperative language that offers `map`, `filter`, `reduce`, or similar, the written contract of this API should state that any higher-order function handed to it as an argument must be free from side effects.
    Does the written contract for for-loops specify this as well? Because that's the obvious alternative for a reduce that an imperative programmer would reach for: a for-loop with the programmer managing the accumulation manually.
2. Someone · 1789384581 · focus · HN ↗
  [delayed]
futune · 1789391009 · focus · HN ↗
I was going to write a question asking if reduce is the thing I know as accumulate (I think I picked this up from SICP). But then I went to wikipedia, and it seems that an even more common name is fold.
Here's a hypothesis: The fact that the same operation has half a dozen different names makes it sound like there is a lot to learn. If I am totally familiar with fold, and i come upon a reduce, I may need to think more about what's going on, which is distracting.
I don't think map and filter have so many synonyms? I know select for filter, but it seems to me less common.
1. 3836293648 · 1789393241 · focus · HN ↗
  And in some contexts you have the subtle distinction that fold is linear and reduce requires an associative operation and an identity element (aka a monoid)
hyperhello · 1789393040 · focus · HN ↗
For can have another set of variables in the header too. You can simulate it more readably even if you need to call the lambda.
el_oni · 1789395360 · focus · HN ↗
Ive only used reduce at work half a dozen times and it does raise an eyebrow each time.
But for unioning a bunch of spark dataframes together i think
```
    df = reduce(DataFrame.union, list_of_dfs) 
```
is much nicer than
```
    df, *rest = list_of_dfs

    for other in rest:
        df = df.union(other)
```
People just get a bit funny, especially now you have to import it from functools
1. tehnub · 1789618770 · focus · HN ↗
  Came here to comment this. I work on a team of functional-adverse devs, but they all happily use this one.
olivewong · 1789411905 · focus · HN ↗
I agree, but I think a lot of it is variable name abuse on the accumulator, making it unclear. I've seen a lot of single letter or worse, a coworker who named it "cum" for short which is super not okay
ducaale · 1789416271 · focus · HN ↗
I find `reduce` useful for operations where:
- arg1, arg2 and return value are all of the same type e.g `ADD`, `MAX`, `CONCAT` etc
- and there is an identity value e.g zero for `ADD`, -math.inf for `MAX`
I recommend checking this article[1] on how monoids play nicely with reduce.
[1] <a href="https://fsharpforfunandprofit.com/posts/monoids-without-tears/#what-use-are-monoids-to-a-programmer" rel="nofollow">https://fsharpforfunandprofit.com/posts/monoids-without-tear...
rspeele · 1789445508 · 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. jiehong · 1789595073 · focus · HN ↗
  > … to call them Select and Where.
  While map is a great name, I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them.
  I mean, it’s like a colander: you filter noodles and water, but which one do you keep? The noodles, right? But, replace noodles with tea and now you want to keep the water part.
  Naming is hard I guess.
  1. seanw444 · 1789596321 · focus · HN ↗
    I've never run into a generic "filter" function which keeps only the non-matching elements.
    jdougan · 1789604244 · focus · HN ↗
    Smalltalk has #reject: which does that. You could, of course, just wrap a not around the test in the closure, but sometimes reject with a well-named predicate is easier to read.
    bsnpApproved := tvShows reject: [ :eachShow | eachShow hasNaughtyContent ].
    dreamcompiler · 1789606816 · focus · HN ↗
    Common Lisp's filter is remove-if which works this way.
    (It also has remove-if-not but that's deprecated and if you use it your code smells.)
    shawn_w · 1789639690 · focus · HN ↗
    `remove-if-not` was deprecated before the Common Lisp standard was approved and yet it remained (and will never be removed because the standard will never be updated). That's not deprecated for any practical purpose. And it's more convenient than using `(remove-if (complement #'some-predicate) sequence)`
    Scheme has `filter` and `filter-not` in the SRFI-1 list library. Both of which can easily be written using a fold to bring this vaguely on topic.
    kazinator · 1789759829 · focus · HN ↗
    [delayed]
    dreamcompiler · 1789825881 · focus · HN ↗
    I agree that keep-if is a better name. But you reiterated my point: remove-if works in the counterintuitive way the original comment noted, i.e. not like the common connotation of 'filter.'
    As for deprecation, several of the '-if-not' functions were deprecated because the committee felt the 'complement' function accomplished that task better.
    kazinator · 1789973120 · focus · HN ↗
    Nonetheless, they were fooled by that function, because it's just keep-if by a funny name that includes "not" suggesting that it contains a complement that might be factored out.
    If you want keep-if, you don't want to use a different function, which forces you to complement your predicate. If you want (keep-if #'redp jellybean-list) to keep the red jelly beans, you don't want to write (remove-if (complement #'not-red-p) jellybean-list). If keep-if has a silly name remoe-if-not, you might nonetheless prefer (remove-if-not #'redp jelly-bean-list).
    Shims like complements are ugly, and compilers won't optimize through them for arbitrary function definitions (whose source code is not even in scope), so it is good to have both keepers and removers. Heck, it's useful to have a function which does both in one pass returning two values: the filtrate and the retentate.
  2. pavlov · 1789596441 · focus · HN ↗
    Maybe those two could be filter_for (the “where” case) and filter_out.
    listenallyall · 1789617042 · focus · HN ↗
    Kotlin has filter and filterNot
  3. dcminter · 1789596910 · focus · HN ↗
    [delayed]
    NooneAtAll3 · 1789598750 · focus · HN ↗
    depends on the size of the sieve, but sometimes one does cook a whole stewpot of tea at once (f.e. in canteen)
    dcminter · 1789659774 · focus · HN ↗
    [delayed]
    SamBam · 1789610706 · focus · HN ↗
    I was thinking an apt analogy might be making stock -- you filter out all the solid food you don't want to keep in the liquid.
    And it's a doubly-good analogy, because I have occasionally gotten that confused in real-life as well. Twice in the past ten years I've had a stock boil away for three hours, and then set a colander in the sink and poured it through, only to watch my beautiful stock swirl down the drain because motor-memory made me forget that I wasn't draining pasta but should have put the colander in a bowl...
    dcminter · 1789676583 · focus · HN ↗
    [delayed]
  4. reddit_clone · 1789600119 · focus · HN ↗
    Talking about un-guessable, misleading function names,
    C++ std::remove.
    I would never have guessed what it does exactly. (It moves elements that match the filter to the front, and moves the end-marker forward. Leaves all the elements in the collection. You need to erase them yourself. )
    mitxela · 1789602816 · focus · HN ↗
    It returns the new end marker
    anitil · 1789602873 · focus · HN ↗
    Oh it's a bit like unordered-delete when using an arena. I guess I would have expected an ordered-delete instead
  5. andrekandre · 1789600405 · focus · HN ↗
    > I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them
    if you had parameter names maybe it might help?
    `filter(where:)` like in swift...?
    mikebenfield · 1789600511 · focus · HN ↗
    Doesn't seem to help the ambiguity to me.
    andrekandre · 1789687619 · focus · HN ↗
    maybe its the verb?
    what about `exclude()` or `keep()`?
    in those cases its less ambiguous (to me anyways) that returning true means 'yes' to 'keep' or 'exclude', whereas saying yes or no to filter is like 'filter to exclude or include?'
    thats my take anyway
  6. quaverquaver · 1789603256 · focus · HN ↗
    select/reject (Ruby)
  7. layer8 · 1789609021 · focus · HN ↗
    It should be named keep.
  8. saghm · 1789611359 · focus · HN ↗
    There's always the Ruby strategy of just making all the names work. `select` and `filter` are buddies and you can use whichever you want or even go back and forth. Not a fan of `reduce`? That's fine, `inject` has got your back. Miss getting to type `collect` from Java or Rust? Don't worry, just use it instead of `map`, it's the same thing.
    brabel · 1789628207 · focus · HN ↗
    I believe Ruby uses names inspired by SmallTalk.
    arnsholt · 1789628656 · focus · HN ↗
    Yeah, Smalltalk has select, reject (inverted filter), collect (map) and inject.
    saghm · 1789658509 · focus · HN ↗
    Right, I'm just saying that it has a lot of aliases, which is fairly uncommon in most mainstream languages
  9. rmunn · 1789613125 · focus · HN ↗
    The filter keeps the tea... it's just that you then lift the filter out of the cup, carrying the tea with it. Flip your brain around to see it from that direction and it might help you with the mnemonics.
  10. thaumasiotes · 1789631260 · focus · HN ↗
    > While map is a great name, I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them.
    In Common Lisp both functions exist, under the names `remove-if` and `remove-if-not`.
  11. ihumanable · 1789682514 · focus · HN ↗
    In elixir we have Enum.filter (run a predicate over the enumerable keeping the things that match the predicate) and Enum.reject (run a predicate over the enumerable removing the thing that match the predicate)
    I think since we have a pair of them and reject is so obvious it helps me remember which way filter works.
    I think Enum.keep and Enum.reject might be a better pair, but I've used them enough to internalize it now
2. zelphirkalt · 1789596421 · focus · HN ↗
  In GNU Guile `reduce` is described as a special case of `fold`, where the first element is suitable to be used as initial value, while `fold` is more general and lets you specify another initial value. I think that makes a lot of sense.
3. mitxela · 1789602770 · focus · HN ↗
  An IDE can fix that
  1. bawolff · 1789603664 · focus · HN ↗
    Meh, if you need a computer program to understand an API its a bad api.
    APIs should make sense inherently. An IDE can band-aid a bad design, but that doesn't make it a good design.
    atherton94027 · 1789604206 · focus · HN ↗
    There are lots of APIs where the order of argument isn't obvious, it doesn't mean they're bad designs
    mitxela · 1789621117 · focus · HN ↗
    That's why I only program in punched cards. If you need a visual editor you're a bad programmer.
    brabel · 1789628627 · focus · HN ↗
    Luxury! All I need is a magnetic needle and a steady hand to flip the bits directly on the silicone.
    jumpingscript · 1789629254 · focus · HN ↗
    excuse me, but real programmers use butterflies.
4. saghm · 1789611178 · focus · HN ↗
  It doesn't help that fold/reduce often have different orders depending on the ecosystem. Every few months when I have a reason to reach for `fold` in nutshell I forget that it has the next element as the first arg instead of the second, which is what I'm used to from Rust. I guess I should just be happy I don't need to specify which direction I want like in OCaml.
5. mamcx · 1789612291 · focus · HN ↗
  Also reduce is a weird name.
  1. ingonealan3 · 1789620887 · focus · HN ↗
    Why? It does, after all, reduce a collection to a single value.
    karmakurtisaani · 1789625356 · focus · HN ↗
    I suppose it's just so ... reductive, you know?
    ketzu · 1789627832 · focus · HN ↗
    Only in the sense that a collection is a single value, too.
    Reduce can write transforms, filters and whatever else.
    reduce(lambda x,y: x.extend([y+2,y*2,y**2]), [1,2,3,4], [])
    (or you could turn it into a tree)
    ketzu · 1789628728 · 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.
  2. EFreethought · 1789634917 · focus · HN ↗
    In the book "Simply Scheme", map is "every", filter is "keep", and reduce is "accumulate".
  3. nextaccountic · 1789636005 · focus · HN ↗
    What about fold?
    In rust iterators there's both fold (you supply the initial value) and reduce (it uses the first element as the initial value, doesn't work on empty iterators)
    <a href="https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.fold" rel="nofollow">https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...
    <a href="https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.reduce" rel="nofollow">https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...
6. kccqzy · 1789614683 · focus · HN ↗
  [delayed]
7. kccqzy · 1789615337 · focus · HN ↗
  Haskell got this right. You have foldr (right fold) and foldl' (left fold), and the order of the callback is opposite. If you do a left fold, then the initial accumulator is applied on the left; if you do a right fold, then the initial accumulator is applied on the right.
  foldr f z [x1, x2, ..., xn] == x1 `f` (x2 `f` ... (xn `f` z)...) foldl' f z [x1, x2, ..., xn] == (...((z `f` x1) `f` x2) `f`...) `f` xn
  The mnemonic here is that the folding function (aka the callback) replaces the comma.
  I find this slightly easier to remember than other languages. In contrast most other languages do not simultaneously provide a left fold and a right fold, so they do not consider this aspect, making things more difficult to remember.
  That said I totally agree this requires more brainpower to read and write than map or filter. For this reason I have sometimes refactored code to use foldMap instead of foldr or foldl', so one no longer needs to think of the direction of the fold or the order of arguments.
  1. pash · 1789618486 · focus · HN ↗
    In other words, look at the types. The type of the folding function, the first argument, shows you how they work.
    foldl' :: Foldable t => (b -> a -> b) -> b -> t a -> b folder :: Foldable t => (a -> b -> b) -> b -> t a -> b
    internet_points · 1789629487 · focus · HN ↗
    That's what I tend to do, but since foldr/foldl' is so ubiquitous in Haskell it would be nice if I could just remember the argument order of the callback. kccqzy's explanation might just help me do that :)
  2. arialdomartini · 1789625657 · focus · HN ↗
    Since you mention mnemonics, here are the mnemonics I use to remember the (symmetrical) differences between foldr and foldl
    <a href="https://arialdomartini.github.io/fold-mnemonics" rel="nofollow">https://arialdomartini.github.io/fold-mnemonics
  3. bananaflag · 1789626129 · focus · HN ↗
    I admit that I have always looked at an explanation like yours with x1,...,xn when using fold because I could never keep it straight in my mind.
  4. mcv · 1789635433 · focus · HN ↗
    It's still a complex and more abstract function than map or filter. Those do a single thing that's easy to grasp. reduce/fold can be easily abused to duplicate the effect of most other collection functions, at the cost of making the code less readable. Although for slightly-too-clever people, that could mean you only need to know one function instead of all of them.
    But it hurts readability. If you're going to do it, at least don't use it anonymously, but give it a name that clearly describes what's going on.
    But even then, there can be hidden performance traps. I've often seen javascript that used reduce and created the new accumulator by using a spread on the old accumulator and adding the new one: `[...acc, newValue]`. But that spread is another iteration inside a loop, turning it from O(n) to O(n^2). A for loop where you append it is much faster.
  5. shawn_w · 1789640369 · focus · HN ↗
    When the accumulator isn't the second argument in a fold, left or right, it feels wrong and I waste some time cursing whomever made a silly mistake like getting the order wrong.
    Luckily the functional languages I use the most are sane in that respect.
  6. cben · 1790163252 · focus · HN ↗
    Ruby's `[1, 2, 3].inject(:+)` alias for `reduce` (name borrowed from Smalltalk) nicely reinforces that very mnemonic: you inject the operator _between_ the elements: 1 + 2 + 3. :+ here is symbol meaning "send + message", more general form takes a block:
    [1, 2, 3].inject { |a,b| a + b }
    The downside of the "between" mnemonic is encouraging not handling an empty collection! Ruby's separate syntax to pass (args) {block} at least offers natural place to add initial value, but with symbol shorthand the API is harder to guess:
    numbers.inject(0) { |a,b| a + b } numbers.inject(0, :+)
    (Also, it's always a left fold ((a) OP b) OP c, even if you give a symbol like :* which parses right-assiciative without parens — making the "inject operator between values" mental model less accurate.)
8. d--b · 1789618699 · focus · HN ↗
  Exactly, and sometimes you also get the indez as argument of the function. `reduce(acc,(acc,elem,idx)=>…)`
  and in many case the accumulator is a tuple, and in many cases you need to know the length of the collection ( like average)
  all in all, it’s a lot just to avoid a for loop.
9. zzo38computer · 1789620987 · focus · HN ↗
  In some programming languages with RPN you can avoid this problem, because it makes sense to put it in the stack as the initial value, and then you can as easily have multiple initial values; and then the callback function can read that from the stack that you had put there, like anything else you will push into the stack to read it back later. For example, in PostScript you can write something like:
  0 exch {add} forall
  However, this is not as good if you want to use the first element as the initial value instead, but still it can be done but it is then not as simple (unlike in programming languages that do not use RPN but instead with function call with arguments, in which case it might be simpler).
  I guess names as SELECT and WHERE are like SQL (although SQL works differently than other programming langauges).
10. thaumasiotes · 1789631140 · 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.
  I don't understand. Map takes input of type a and size n and returns output of type b and size n.
  Filter takes input of type a and size n and returns output of type a and size ≤ n.
  They look nothing alike?
  1. dmi · 1789645945 · focus · HN ↗
    I think their point was that map/filter _individually_ look identical in most languages, i.e. map looks the same across most languages, and filter looks the same across languages, not that map and filter look identical to each other in most languages.
11. throw310822 · 1789650081 · focus · HN ↗
  More trivially, map and filter are operations that can be understood by what they do to individual elements, while reduce is a folding operation that is applied recursively on its own output. Much harder to think about
s-zeng · 1789447471 · focus · HN ↗
Even in the world of functional programming, there's an argument to be made that `fold` is a bit of a code smell, in a similar vein as `while` being slightly smelly in an imperative code base. There's good reasons for each to be used, but they are such low level iteration primitives that you might be better off with a higher one (e.g. for loops or iterators in imperative programs; in FP you might reach for monoidic reduces (as opposed to folds where the accumulator is a different type from the list element), monadic traverses, or recursion schemes). Even though you can implement iterators or for loops in terms of while loops, you probably shouldn't, and similar for functional traversals.
In languages like python or Java though, you don't really have access to many of the higher power functional traversals however. So that puts you into a similar kind of bind as working in a language with only while loops
1. grebc · 1789586721 · focus · HN ↗
  I’ve never ever heard while described as a smell, or even slightly smelly.
  Care to explain?
  1. polonbike · 1789587566 · focus · HN ↗
    If you can smell it, there's something fishy in the neighborhood
  2. theamk · 1789588601 · focus · HN ↗
    I assume OP refers to the cases where "while" is used to re-implement existing operations... imagine finding code like this:
    i = 0 while i != len(todo): process(todo[i]) i = i + 1
    sure, there may be a good reason to implement things this way (maybe "todo" grows during iteration?), but maybe not, and then the loop should be instead simplified to:
    for value in todo: process(value)
    (as an aside, this is exactly the case where the comments are required: "# not using for loop because todo might grow" will make it clear it's an intentional decision and not hallucination or something written from ignorance)
    grebc · 1789589965 · focus · HN ↗
    You can use iterators in a while loop like your for example, making it look as clean as the for.
    I feel like this is a case of personal preference over actual issue.
    adastra22 · 1789661071 · focus · HN ↗
    Iterative aren’t a thing in C, where that code smell notion comes from.
    grebc · 1789670515 · focus · HN ↗
    What are you even talking about.
    theamk · 1789664841 · focus · HN ↗
    [delayed]
    grebc · 1789671346 · focus · HN ↗
    Your for loop is using an iterator of some kind. Just because it’s hidden in your language of choice doesn’t mean it’s not there.
    While/for can achieve the same thing, sometimes while is more practical as the steps to complete are unknown. But sure, stick your simple iterating a fixed collection as why it demonstrates while is a lesser language feature.
    theamk · 1789762225 · focus · HN ↗
    [delayed]
    grebc · 1789790299 · focus · HN ↗
    Let's leave it there mate.
    You're not the OP, you/me we're only guessing what he/she might've meant.
  3. d--b · 1789619502 · focus · HN ↗
    Probably because while is the source of many infinite loops, and because it’s sometimes faster and more rigorous to compute the length ahead of going into the loop.
    That said, I personally don’t think it’s smelly at all.
  4. [deleted] · 1789661069 · focus · HN ↗
    [deleted]
2. nextaccountic · 1789636234 · focus · HN ↗
  > or recursion schemes
  Fold is a recursion scheme
  More complicated recursion schemes are progressively harder to read. Probably not great if you are not doing code golf
snackbroken · 1789450953 · focus · HN ↗
Map and Filter are nice because they let you reason locally about a single element in isolation. Reduce(Fold) forces you to reason globally about intermediate results. Reduce also forces you to conjure up a "zero" value of the relevant type, which isn't usually difficult but it does constitute some extra mental overhead.
1. mrkeen · 1789583193 · focus · HN ↗
  It's pairwise, not global reasoning.
  1. snackbroken · 1789584735 · focus · HN ↗
    The accumulator is global state. If you're folding from list<int> to int you're right that it's (usually) effectively a pairwise operation on ints. If the fold is something like list<foo> -> tree<bar> then you have to reason about each intermediate (tree<bar>, foo) -> tree<bar>, i.e. how global state should evolve over time with each update.
    IceDane · 1789619903 · focus · HN ↗
    What a load of nonsense. The only thing you have to do is think about your initial state, which is usually trivial and some sort of empty state (0, empty list) and how to combine two elements.
2. sigbottle · 1789585712 · focus · HN ↗
  Isn't reduce usually used for monoidal operations? Or do people implicitly absue ordering?
  If the algortihm doesn't work the same forward, backwards, and with a tree scan, it ain't reduce (as a first approximation not IFF)
  1. snackbroken · 1789590674 · focus · HN ↗
    That's what I'm used to as well, but in my experience a lot of programmers take fold and reduce to be synonyms. A monoidal reduce is much less "scary" than a general fold. I suspect most programmers have never[1] heard the word monoid, let alone know what it means, and having to remember the meaning of a weird new word is enough to make most people dislike something compared to the simpler more familiar operations.
    [1]Or if they have, their only encounter with it is the "a monad is just a monoid in the category of endofunctors" meme.
    sigbottle · 1789591490 · focus · HN ↗
    I do know what a monoid is, but a monad in the category of endofunctors is the scary word for me :sob:
    ndriscoll · 1789608461 · focus · HN ↗
    It just means if you have some functor F (generic type with a well-behaved `map` function, like List), then you have a `flatten` operation F[F[_]] - > F[_], and like a monoidal product, it's associative. So if you have a triply nested List, you can flatten inside first or outside first. Also, like a monoid, it has an "identity" function wrap: A->F[A] (e.g. x -> [x]). Identity in the sense that "multiplying" (flattening) with wrap does nothing. i.e. wrap(flatten(x)) = flatten(wrap(x)) = x when those things make sense.
    So basically wrapping and flattening behave in a sane way. Flatten is your multiply, wrap is your multiplicative identity, and it's like a monoid if you squint.
    adastra22 · 1789660962 · focus · HN ↗
    You have become the meme.
    ndriscoll · 1789664390 · focus · HN ↗
    "The meme" literally comes from a book immediately after a long definition that was offering it as an intuitive explanation, assuming you know what a monoid is. All the laws and stuff boil down to "if you generalize the idea of a monoid a little bit, and if you have some functor+flatten+map forming a monoid, we call that a monad."
    adastra22 · 1789701699 · focus · HN ↗
    The point is that the terminology surrounding this is impenetrable and non intuitive. Rather than acknowledge that, we get a lesson on category theory, which is missing the point.
    ndriscoll · 1789747264 · focus · HN ↗
    The person I replied to said they know what monoid means, so they're familiar with algebra. The explanation is intuitive for someone familiar with undergraduate algebra. That's literally where the meme comes from, an intuitive remark. If you think it's impenetrable, it's not for you.
    adastra22 · 1789777073 · focus · HN ↗
    It may have come from an old textbook, but its origin as a meme is a 2009 joke blog post that gets its humor from making fun of how obtuse and pedagogically inept that explanation is. When people reference it today, this is what they are referencing: <a href="https://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html?m=1" rel="nofollow">https://james-iry.blogspot.com/2009/05/brief-incomplete-and-...
    ndriscoll · 1789782775 · focus · HN ↗
    I'm aware of the meme, but it's not obtuse pedagogically inept.
    Like if someone says they're familiar with groups and Fourier transforms, but not what it means to say wavelets are the Fourier basis for the affine group, and I break that down, and you don't know what any of those words mean, that's not me being obtuse, that's you wandering into the wrong conversation.
    antonvs · 1789627278 · focus · HN ↗
    Do you want to understand monads, or do you want to understand the original quote that the joke you referenced was based on?
    For the record, the original quote by Saunders Mac Lane is "a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor."
    That quote is a statement in category theory. The author probably never heard of, say, Haskell - he was a pure mathematician. You can't usefully express that quote in Haskell code. You can treat it as a kind of formal description of what monads are, and Haskell generally conforms to that. But in that context, the quote itself is essentially using category theory as a metalanguage, in the same sort of way as one might write a mathematical statement that captures the semantics of some programming language expression.
    That said, the quote can be handwavingly understood if you know what a monoid is, and that for monads, the identity object is the identity functor, its product is `join`[1] and its unit and multiplication satisfy the usual monoid laws.
    For a concrete example, consider this Haskell expression using the `Maybe` monad:
    do x <- Just 3 return (x + 1)
    That desugars to:
    Just 3 >>= \x -> Just (x + 1)
    Which we can desugar to an expression in terms of the monad's monoidal product, `join`, by substituting the definition of `>>=` in terms of `join`[1] to get:
    join (fmap (\x -> Just (x + 1)) (Just 3))
    You can evaluate that in Haskell and you'll get `Just 4`, just like the original expression.
    So what happened there? The inner expression `fmap (\x -> Just (x + 1)) (Just 3)` applies the anonymous function to `Just 3` to get the double-wrapped `Just (Just 4)`. One of the `Just` wrappers is then eliminated with `join`.
    (Btw, the fact that we have a Maybe within a Maybe here is related to the fact "monads are monoids in the category of endofunctors" - a category that maps to itself. That's where that part of the quote comes from.)
    In this simple example, there's some unnecessary machinery - you can get the same result with `fmap (\x -> x + 1) (Just 3)`, without the extra `Just` wrapper or the `join` to eliminate it. But then you lose the ability to do things "in the monad": the anonymous function becomes just an ordinary function, it doesn't have access to the monadic wrapper. Many of the useful things that monads can do are because the wrapper is available in every function, so you can store state in it (Reader monad), create new wrapper instances with different state and pass those on (Writer and State monad), etc.
    ---
    [1] x >>= f = join (fmap f x)
  2. txhwind · 1789609350 · focus · HN ↗
    If the contraint is not in the signature, and cannot trigger a test failure with typical implementation, it doesn't exist.
3. mcphage · 1789587755 · focus · HN ↗
  > Reduce also forces you to conjure up a "zero" value of the relevant type, which isn't usually difficult but it does constitute some extra mental overhead.
  It's always worthwhile to consider what the result will be when you pass in an empty list.
  1. snackbroken · 1789589973 · focus · HN ↗
    Right. It's just one more thing you have to think about with Reduce that's not something you have to consider with Map/Filter.
    Lvl999Noob · 1789619359 · focus · HN ↗
    If you have need of a reducing operation though, you will still need to think about that value. If you are summing up a list of numbers, it doesn't matter whether you use reduce or a loop, you need to set some initial value.
    mcphage · 1789655915 · focus · HN ↗
    I agree, although most of the time you do end up needing to consider it with Map/Filter. It's just, it doesn't force you to. Which means either you think about it later, or it bites you in the ass because you didn't consider the empty case. Not always—and for those cases where you don't end up needing the empty case, Reduce is probably not necessary, and Map/Filter is sufficient.
4. globular-toast · 1789628673 · focus · HN ↗
  > Reduce also forces you to conjure up a "zero" value of the relevant type
  It's more accurately an identity. If you are multiplying the identity is 1. While I think most people are comfortable saying the sum of no elements is 0 it's perhaps less intuitive that the product of no elements is 1. This makes me think reduce might be preferred by those with a mathematical background.
chubot · 1789583290 · focus · HN ↗
Related to the point about worse performance, I'm pretty sure I was there when reduce was "banished" from Python 3 -- demoted to functools.reduce(), instead of the builtin reduce() in Python 2
The story is that sometime in 2006 or 2007, Guido van Rossum was debugging why a web page in Google's internal code review tool (which he wrote) was taking 30+ seconds to render.
This is basically a "production" incident, since thousands of Google engineers relied on the tool. Requests like this were probably tying up threads and exhausting thread pools, perhaps
Eventually it was tracked down to a line wrapping algorithm written with reduce(). I don't think he wrote it -- it may have come in through a dependency. As many know, reduce() is basically:
```
     s1 + s2
     s1 + s2 + s3
     s1 + s2 + s3 + s4 
     ...
```
And that's O(n^2) when s_i are strings. And I think it showed up if you viewed a 5000+ line diff, or a 5000+ line file. (Newer programs like Github also suffer here)
I believe, in Python at that time, += was already optimized to avoid this (just like essentially all JS VMs are). Or you can use the idiom of append() to list and join() after.
But reduce() basically forces the inefficient implementation, and I'm sure this is still true in Python 3.
---
So basically Guido spent a long time debugging a performance problem related to reduce(), and made the decision to eject it, to help users avoid "footguns". I was his officemate at the time, so I recall this, but I wasn't involved directly
Also, somebody contributed reduce() to Python way back in the 90's, as well as other functional idioms. He wouldn't have added that himself -- it was never his preferred style.
He preferred a more imperative style. But he allowed those contributions, and then slightly regretted it later.
<a href="https://docs.python.org/3/library/functools.html#functools.reduce" rel="nofollow">https://docs.python.org/3/library/functools.html#functools.r...
1. taeric · 1789584000 · focus · HN ↗
  This always feels odd to me. It would seem a fairly straight forward optimization of the interpreter to special case the different types that it can reduce.
  That is, why couldn't they have done the essentially same trick that you reference for += with reduce?
  1. kelipso · 1789584404 · focus · HN ↗
    I think many people don’t want to say this publicly but Python developers are really not the smartest of the bunch.
  2. justonceokay · 1789584622 · focus · HN ↗
    That sounds nice but in practice it’s probably not super helpful. Yes you could make a special case for reducing “+” over integers. But in python you can generally not promise that all the inputs are strictly integers, and you can’t even promise that your “+” function has no side effects.
  3. bmandale · 1789584647 · focus · HN ↗
    There is no such trick. Python is only now getting those style of JIT style optimizations, and that one in particular still hasn't hit. Do not use += on strings in a loop unless you are certain the iteration count will be small.
    There is an optimization for lists, and maybe that's what GP is remembering. l += is functionally different from l = l +. The former mutates l, whereas the latter creates a new l. The difference matters when the line above is m = l. The mutation version will mutate m as well (they're the same reference), the creates new version will not. This optimization can just as easily turn into a footgun if the programmer is unaware of it, and in that sense is unpythonic.
    Maxatar · 1789598756 · focus · HN ↗
    Python has optimized string appending in the form of:
    s = s + "foo"
    and
    s += "foo"
    Since 2005 with the release of Python 2.4:
    <a href="https://docs.python.org/3/whatsnew/2.4.html" rel="nofollow">https://docs.python.org/3/whatsnew/2.4.html
    kenferry · 1789601125 · focus · HN ↗
    I’m not a fan of this kind of “fancy” optimization anyway.
    It’s too fragile. I may make some innocuous change, now the compiler cannot recognize the pattern and performance falls off the cliff.
    I’d rather have the reliability that the absolute fastest possible result the compiler can produce. Then if there’s an issue I can catch and fix it reliably with profiling, not deal with a heisenbug based on whether the compiler can match the pattern.
2. bjourne · 1789585071 · focus · HN ↗
  Maybe you are misremembering the story? += deferred concatenation requires lazy strings and that didn't come until 10-15 years later. However, concatenating string lists with sum() was a common Python idiom at the time and it indeed incurred O(n^2) complexity. Gvr's reduce dislike was more about its syntax. It doesn't mesh well with Python's lambda syntax.
  1. Maxatar · 1789599731 · focus · HN ↗
    > += deferred concatenation requires lazy strings and that didn't come until 10-15 years later.
    CPython's += does not perform deferred concatenation and CPython does not use lazy strings. The optimization uses an eager in-place realloc if the string's ref-count is 1. This remains the optimization used even to this day and was introduced in 2005:
    <a href="https://docs.python.org/3/whatsnew/2.4.html#optimizations" rel="nofollow">https://docs.python.org/3/whatsnew/2.4.html#optimizations
    >However, concatenating string lists with sum() was a common Python idiom at the time
    It could not possibly have been a common Python idiom since sum() explicitly rejected strings by throwing a TypeError. This was explicitly special cased to avoid the degenerate performance and the TypeError even has an error message saying "TypeError: sum() can't sum strings [use ''.join(seq) instead]".
    >Gvr's reduce dislike was more about its syntax. It doesn't mesh well with Python's lambda syntax.
    No it had nothing to do with mixing with lambda syntax, on the contrary GvR actually wanted to remove reduce and lambda (and map and filter as well). Here is the actual article by GvR regarding removing reduce, absolutely nothing in it involves how it mixes with lambda expressions.
    <a href="https://www.artima.com/weblogs/viewpost.jsp?thread=98196" rel="nofollow">https://www.artima.com/weblogs/viewpost.jsp?thread=98196
    >So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.
    chubot · 1789606336 · focus · HN ↗
    Yes thanks for finding the Python 2.4 release page which shows the optimization! So I remembered correctly -- Python already had that optimization back then.
    And the March 2005 Artima post is also a very good reference! That actually predates my story, since Guido hadn't joined Google by then. (I recall that he joined in December 2005.)
    So maybe the bug I remember was more of a "push" in the direction he had already thought of, not the direct inspiration.
    It is clear from the blog post that he disliked all of map / filter / reduce, and then I'm sure that users or python-dev pushed back a bit, so he settled for banishing reduce() to the stdlib.
  2. vhcr · 1789614413 · focus · HN ↗
    It was never possible to sum() strings.
    <a href="https://github.com/python/cpython/commit/a70b19147fd163744be34745d393af7be603629f" rel="nofollow">https://github.com/python/cpython/commit/a70b19147fd163744be...
3. hn_go_brrrrr · 1789585694 · focus · HN ↗
  2006...would that have been Mondrian?
  1. chubot · 1789606493 · focus · HN ↗
    Yes!
4. rienbdj · 1789594557 · focus · HN ↗
  So rather than provide a runtime or compiler optimization, we force the programmer to do it by hand. This is why I don’t like Python philosophically.
  1. j2kun · 1789596519 · focus · HN ↗
    I don't believe Python had a compiler in 2006...
    paradox460 · 1789601701 · focus · HN ↗
    It had a runtime
    chubot · 1789606064 · focus · HN ↗
    Python has always had a bytecode compiler that did some minor optimizations, since its inception in the 90's. The issue is that optimizations are very hard to do correctly in the compiler because Python is so dynamic. Any piece of code could suddenly redefine mytype.__add__() and so forth.
    Digit-Al · 1789716755 · focus · HN ↗
    Python 2.0 was released in October 2000. Maybe you're thinking of Python 3.0.
5. Zak · 1789596365 · focus · HN ↗
  I find that decision a bit odd given that accumulating a string with a loop is also quadratic in Python if you use = instead of +=, or even if you use += when the left operand isn't provably unshared. I don't believe removing loops was seriously considered.
  The footgun isn't `reduce` in particular, but failing to use `join`.
  1. edflsafoiewq · 1789602243 · focus · HN ↗
    Doesn't reduce fundamentally makes the accumulator shared though? Both the reduce and the lambda are holding onto references to acc.
    ndriscoll · 1789603958 · focus · HN ↗
    def reduce(acc, f): for v in self: acc = f(acc, v) return acc
    The current acc goes out of scope each time you call f. There's no shared reference.
    edflsafoiewq · 1789609189 · focus · HN ↗
    The binding for acc in the reduce call is still active during the f call, which means there are at least two references to acc.
    ndriscoll · 1789610699 · focus · HN ↗
    Why is it still active? Even an interpreter with no lookahead could see that it goes out of scope immediately when f returns (it gets shadowed on that line), so as long as there's no guarantee about when finalizers get called, it should be able to mark it dead inside of reduce as soon as it's passed to f. Like move semantics here should be a general pattern for optimization, no?
    edflsafoiewq · 1789611170 · focus · HN ↗
    Does Python actually do that? If the f call throws, you can still observe the (unchanged) binding of acc in reduce.
    ndriscoll · 1789611684 · focus · HN ↗
    Fair, I suppose there's no end to the level of insanity that a programmer can do in a dynamic language. I'd think it could perhaps still look to see there's no catch, but maybe eval makes even that impossible.
    Zak · 1789604292 · focus · HN ↗
    Yes. My point is that it's better to use the explicit optimized method for joining strings in a performance-sensitive context than to try to meet the conditions for an implicit optimization.
    vhcr · 1789614878 · focus · HN ↗
    The problem with:
    ret = "" for s in strings: ret += s
    is that it re-allocates O(n) times, even if ret is referenced only once.
    edflsafoiewq · 1789616798 · focus · HN ↗
    If the s are small the usual geometric buffer growth mitigates that. Of course you can compute the final buffer size in this case, but often you have a bunch of dynamically-generated strings of different sizes.
  2. OJFord · 1789631262 · focus · HN ↗
    I suppose `reduce` as built-in is the footgun because it's too easy to reach for. Now if someone doesn't know about `join` perhaps they look up how to do it because they think 'surely there's a better way than a loop without an import'.
6. TZubiri · 1789602702 · focus · HN ↗
  The way I understand it, the map,filter,reduce functions in python exist as pythonic language constructs:
  -map: [x*2 for x in xs]
  -filter: [x for x in xs if x%0==2]
  -reduce: ummm..
  Maybe something like:
  sum = x+ret for x in xs from ret=0
  1. anitil · 1789603183 · focus · HN ↗
    Maybe the closest is 'join' similar to `",".join([...])`? If we could replace the string with an operator
  2. Izkata · 1789624831 · focus · HN ↗
    That one is built in:
    sum([1, 2, 3]) == 6
7. z500 · 1789661741 · focus · HN ↗
  [delayed]
semiinfinitely · 1789583415 · focus · HN ↗
you guys still reading and review code with ur eyes and brain?
1. mahboi · 1789597868 · focus · HN ↗
  Say I'm not and Claude mentions somewhere that we had a bug involving reduce(), I'm telling it to remove all uses of reduce from the codebase
mcphage · 1789587542 · focus · HN ↗
I like it, but don't care for the name. I find it easier to think about in terms of an accumulator.
adverbly · 1789593648 · focus · HN ↗
Speaking as someone who often tries to reduce my use of reduce by replacing it with map and filter where possible, for me, falling back to reduce is analogous to falling back to a while loop or a for loop: I avoid it if I can.
The problem with reduce is that it can do so much, and therefore it is less clear when reading it quickly what it might be doing.
hungryhobbit · 1789593757 · focus · HN ↗
It's simple really: looping is something we've all done a ton. Map is just a specialized version of something you do all the time, made better/simpler: what's not to like (and learn quickly)?
Reduces are used much, much less often. Most devs don't get familiar with them as a result, so every time they have to read a `reduce` they have to re-learn it. And of course, it's a much more involved/complex function, so that exacerbates it.
scelerat · 1789594452 · focus · HN ↗
One of the books that most affected my programming understanding, ability, and joy was Mark Jason Dominus' "Higher Order Perl."
So I love reduce, and have for many years.
jakub_g · 1789595112 · focus · HN ↗
I dislike reduce because people sometimes do wild things in the callback that take a lot of mental effort to understand.
Sometimes people abuse .map as well to do things that are not obvious (i.e. instead of mapping elements of an array to another array, they modify global variables in a for-loop fashion, and discard the result). But reduce is abused more often and you always need to think really hard if e.g. the accumulator is passed or not (it's optional in some languages!), if a correct one is passed (when a compound type is used) and so on.
1. Terr_ · 1789598233 · focus · HN ↗
  [delayed]
bunderbunder · 1789595113 · focus · HN ↗
I've seen a lot of technical points about reduce, all of which are true.
But I think the real reason might be even simpler: you can't tell what it does just from the name. What `map` does is consistent with well-known programming jargon. What `filter` does is consistent with the word's everyday meaning. But if you don't already know what `reduce` does, it's name isn't even enough to hazard an educated guess.
That's not true in Clojure because for lisp programmers for two reasons. First, `reduce` is a ubiquitous and well-known concept in lisp.
Second, in most lisps manually doing the same task with imperative code is an ugly verbose eyesore. But in algol-style languages, the imperative alternative is only 1-2 extra lines of very simple code, so using `reduce` is arguably just code golf.
1. OkayPhysicist · 1789597454 · focus · HN ↗
  map() and reduce() are equivalent in terms of jargon, IMO. Map also suffers from name collision with dictionaries/objects/whatever your language wants to call a key-value pairing.
  1. bunderbunder · 1789606878 · focus · HN ↗
    The fact that a word has a second sense does not negate the existence of the first sense. Especially not in computing where nearly all of the jargon is wildly polysemous.
skybrian · 1789595126 · focus · HN ↗
It would be clearer if the operation were part of the name. The most common operations have good names, like sum(), product(), concat(), and so on.
If there's no standard function for it, it's trivial to write a utility function.
And as part of writing the function, give it a good name and think a bit about the order of operations?
So I think reduce() is just unnecessarily generic, unless it's part of a more complicated system like running a map-reduce.
fatih-erikli-cg · 1789595565 · focus · HN ↗
[dead]
dochne · 1789595777 · focus · HN ↗
I like it, but it is by far the most ungainly of the three with the most footguns in it's usage.
While not as functionally pure, I always appreciate the Ruby each_with_object <a href="https://ruby-doc.org/3.4.1/Enumerable.html#method-i-each_with_object" rel="nofollow">https://ruby-doc.org/3.4.1/Enumerable.html#method-i-each_wit... as a more pleasant interface for it.
agentultra · 1789595792 · focus · HN ↗
In my experience, it depends a lot on the language and the folks you work with. I’ve gotten an eyebrow and a stern talking to for using ‘map’ in JavaScript once. Some people are die-hard about statements and keywords and imperative programming and their world view and be myopic.
“We can’t have map in our codebase, we need to be able to fire anyone off the street and have them comfortable in our codebase.”
Well… since when did we hire random people off the street?
I’m used to functional programming. For me, reduce is perfectly normal. Fewer intermediate variables. No pesky statements, just a nice expression. Great.
Buuuut… some languages think implementing tail call optimization is too hard or bad or for ivory tower academics. Or they’re dynamically typed. And then reduce does become difficult to special case and make performant. So even if you like the juice it’s probably not worth the squeeze.
It was a great time working with Haskell professionally. I didn’t have to constantly defend my style of programming! But in “everything” languages… well you do. Everyone has to agree on which subset to use. And programmers are like cats. Good luck getting them to agree on anything. Even once you agree there will always be that one challenging the decree.
yipinwong · 1789595805 · focus · HN ↗
Reduce introduces state (accumulator), unlike map/filter which normally are used for immutability.
I use both, but do not like reduce at all. It's harder to read, yes. But I see the point of using them all.
the_other · 1789596419 · focus · HN ↗
(JS/TS is my main language) I love reduce()! It's a hammer/nail method for me. Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).
I really like taking the implementation away from the call site, so that the call site reads
```
    const myNewValue = data.reduce(doSomethingMagic); 
```
(and then `doSomethingMagic` is defined somewhere else). So simple.
I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop. Loops are easier, for sure, but they sprawl and are open to hacking. They can bring in state from outside the loop. They make the call site long (you always have to read the implementation to learn that you don't need to read it). The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier). That's the kind of "clever" I find unpredictable and hard to think about. Probably a good thing he rejected me.
1. anyfoo · 1789596509 · focus · HN ↗
  > I failed a job interview once by using reduce() in a coding test. The reviewer didn't understand why I hadn't used a loop.
  Honestly, sounds like the reviewer failed the interview, not the other way around.
  1. baxuz · 1789596624 · focus · HN ↗
    Nah. Reduce is less performant and less readable than a regular loop. In my anecdotal experience, only people who want to appear smart and minimize the number of characters prefer reduce.
    anyfoo · 1789599814 · focus · HN ↗
    I don't know about JavaScript, but those statements are definitely not universally true in other languages.
    the_other · 1789632589 · focus · HN ↗
    Reduce definitely does not reduce character count. It's the loop-hacking that does that.
    However, I agree it might be less performant, and it's a certain kind of thinking that isn't quickly grokked (and doesn't have to be). I deliberately tried to write my story about the interview so as to make it sound like there's positives and negatives to both positions expressed. _I_ have a preference for that functional style, but I know it's not for everyone. That's totally fine.
2. xp84 · 1789597368 · focus · HN ↗
  > The same interviewer actively liked to have loop bodies modify the loop conditions (e.g. by taking items out of the source array and decrementing the end condition, so the loop would end earlier).
  Wow. That is the kind of monkey business that would have me running for the exits. Yikes.
  1. Joker_vD · 1789652576 · focus · HN ↗
    IIRC both Dijkstra and Knuth used this approach extensively, instead of "if (some_cond) break;" — partly because the latter was not yet invented, partly because of their reliance on explicitly stated and documented right in the code loop invariants.
    xp84 · 1789704810 · focus · HN ↗
    That's fair. Let me modify my statement: If the person doing this was over 50 and had developed this habit in old languages where that was basically idiomatic, it wouldn't scandalize me - though I'd raise an eyebrow to see it in a modern language.
    But if someone's 28 and doing that stuff in Python or JavaScript, they're a bit of a loon, imho.
3. kenferry · 1789601347 · focus · HN ↗
  > Everything looks like a problem solvable by reduce. (I'm often wrong on that, but I quite enjoy learning why by trying).
  I agree, but I think that’s kind of the objection. It can be tempting to write your code as little brainteasers but…
catapart · 1789596564 · focus · HN ↗
For me it's the name[0]. map puts out an array that has been mapped from another array. filter puts out an array that is a filter of the input array. both of those are always true. reduce, on the other hand, may put out a reduction of the input array (probably most of the time), but the fact that it may not means that what is happening is not actually a reduction. In languages like js/ts, you don't even have to return anything of the same type as the input array's elements. You could literally "reduce" and array of integers to a cancellation token, or a state object, or anything else.
I realize it's not the most efficient way to work, but I like my code to read like instructions. There's nothing reduce will do that a for loop won't accomplish and the for loop (+ an accumulator, of course) is more clearly "readable" than reduce. If I read map, I know what's going on. If I read filter, I know what's going on. If I read reduce, I have to figure out what's going on, even if I'm pretty sure what is going on. If I could rely on reduce to always give me back an element of the input array, I would use it more. But since it can give back anything, I prefer the simplicity of a for loop.
[0] I don't have any suggestions for "better" names because the whole operation is hard to sum up in a word? "dispatch" makes sense, as a function dispatching a function over each element in an array, but it masks the concept of accumulation from return values. "transform" is accurate, but hardly descriptive at all. the list goes on. It's an undeniably useful little function, it's just hard to make it easy to understand and therefore debug.
1. scotty79 · 1789596870 · focus · HN ↗
  It doesn't have to be exactly correct. It just need to express intuitively the most common use(es?).
  Aggregate, accumulate, combine for example.
2. xp84 · 1789597210 · focus · HN ↗
  Ruby adds an alias `inject` for reduce. The #1 way I see it used there is like this:
  some_hash = my_array.inject({}) {|accumulator, item| ... }
  But I honestly very rarely use it (by either name) outside of a couple of pasted-in snippets (that I can't recall right now) where the strategy fits exceptionally well, probably because of the dumb reason that I tend to forget which block argument comes first (accumulator, or iterated item)! With other two-item argument lists such as `Hash#map` it being `key, value` makes sense, but with reduce/inject I don't see an obvious order. And I guess I learned before it was likely that some kind of AI autocomplete would be filling the args in for me.
  1. diegof79 · 1789599460 · focus · HN ↗
    The name inject and the argument order comes from Smalltalk (Ruby is heavily inspired by it). In Smalltalk arguments are part of the message name:
    collection inject: aValue into: aBlock
  2. jdougan · 1789601636 · focus · HN ↗
    Ruby inject appears to be derived from Smalltalk #inject:into:
    #(1 2 3 4 5 6 7) inject: 10 into: [ :sum :each | sum + each squared ].
    The way I remember the order is it reflects assignment.
3. adamddev1 · 1789598811 · focus · HN ↗
  I like the name `fold` as used by Haskell, Racket, et al. It gives me an image of folding up a long list into a ball, one chunk at a time.
  1. anitil · 1789603073 · focus · HN ↗
    I like fold too, but I can never remember foldl vs foldr, it's always backwards to what I expect somehow
    internet_points · 1789629689 · focus · HN ↗
    <a href="https://news.ycombinator.com/item?id=49736033">https://news.ycombinator.com/item?id=49736033 may help :)
    anitil · 1789690463 · focus · HN ↗
    Thanks! That visual style approach works better for me, hopefully it sticks
4. reddit_clone · 1789600558 · focus · HN ↗
  There is a big difference in there I think.
  'for' loop is mutating.
  Using 'reduce', you can do the same functionally. In some (somewhat) purely functional languages, there is no choice.
5. layer8 · 1789609938 · focus · HN ↗
  It reduces n items to one item, recursively. The items don’t have to have the same type. Arguably accumulate is a more fitting name. I think of “reduce” as in cooking, boiling a volume of stuff down to some essence.
  I also agree that a for loop is often clearer.
6. mkehrt · 1789618232 · focus · HN ↗
  > You could literally "reduce" and array of integers to a cancellation token, or a state object, or anything else
  This is what reduce does, though? It reduces a list to a single thing. It seems like you're thinking of filter.
scotty79 · 1789596687 · focus · HN ↗
Alternative theory - reduce is badly named.
combine, accumulate it aggregate would have way more use.
altruios · 1789596744 · focus · HN ↗
I'm the weird one here. In JS at least, I reach for reduce before map and filter in most cases. Often it is because I want the accumulator, particularly when I have a list of objects with various properties that I wish to sum together in a reduced object.
mahboi · 1789597098 · focus · HN ↗
Reduce always makes me question the performance.
mahboi · 1789597278 · focus · HN ↗
The most I'll do in Python is like
```
  sum(x[1] for x in args)
```
which is map + reduce. And that's only if x[1] is a number. That's about it. No equivalent in JS. Whenever some JS code has map, I'm like why, and rewrite it as a loop.
This is also assuming we're talking about regular code and not an actual map-reduce framework like Spark.
Terr_ · 1789597476 · focus · HN ↗
Sure, I'm up for some bike-shedding. [0][1] Unless performance demands otherwise, I prefer map+filter because:
1. It's cheaper/faster at communicating intent to humans reading your code. Since a reduce call can do all sorts of interesting things, people need to stare harder to realize "oh, it's just doing a a map and filter together."
2. Things are easier to debug. I can vet the process of transformation (and its intermediate results) and then vet the process of excluding some of those results.
___
[0] <a href="https://en.wikipedia.org/wiki/Law_of_triviality" rel="nofollow">https://en.wikipedia.org/wiki/Law_of_triviality
[1] <a href="https://www.smbc-comics.com/comic/noun" rel="nofollow">https://www.smbc-comics.com/comic/noun
xdavidliu · 1789599758 · focus · HN ↗
reduce has complexity to handle the edge case of an empty iterable, and also for the case of a binary function with different types for inputs and outputs. That makes it harder to reason about and "uglier" than map and filter. People probably hate sum and product significantly less, both those also have the edge cases of empty iterable, in which case the natural result is 0 for sum and 1 for product sure, but of what type?
While we're on the subject, can someone explain to me why in Rust, you need to annotate the type when you call .sum() on an iterable? For example
```
    let p: i32 = [1i32, 2, 3].iter().sum();
    println!(&quot;hello {}&quot;, p);
```
That works, but fails if I replace `p: i32` with `p` or `p: i64`, and I cannot find a satisfactory answer in any thread or llm. The obvious question is why the compiler cannot infer the type from the element type of the container, and the naive response to that is for flexibility summing into a bigger type. But in that case, why would `p: i64` be rejected? And what other type is allowed besides i32?
antfarm · 1789600222 · focus · HN ↗
I remember finally getting what closures and reduce are when I learned Ruby in 2008 for my first Rails job.
A clarifying moment on the same level as when I finally understood how recursion and pointers work in 1995 in my first semester CS class, two concepts I had only ever read in programming books about, but not been able to understand on my own.
In 2024 I did Advent of Code in Swift, without using mutable state, custom data types or loops, and used reduce rahther generously. [1]
[1] <a href="https://github.com/search?q=repo%3Aantfarm%2FAdventOfCode2024+reduce&type=code" rel="nofollow">https://github.com/search?q=repo%3Aantfarm%2FAdventOfCode202...
pmontra · 1789600463 · focus · HN ↗
Map maps a value into another value. It's a function call. Easy to understand.
Filter picks values according to a rule. It's a select from where condition. Maybe not as easy as map but familiar.
Reduce is, what? Even the name is ill fated. Who wants to be reduced? Hence, harder to understand and probably not as common as the other two.
kevinwang · 1789601290 · focus · HN ↗
In python: I've always thought it's funny that of the list functions (map, filter, reduce?), reduce is the one that was removed, but is the only one that I occasionally reach for. (When I remember it doesn't exist, I'm usually happy to write the more readable three-line for loop.)
The other two can be simply expressed as a list comprehension, but afaik you can't with reduce (and if you can, it's probably awful).
felizuno · 1789601689 · focus · HN ↗
IDK, in JS I love reduce and think it is invaluable. If you don't care about closures, never used underscore/lodash, and have not written several hundred var self = this; then you don't share my pain. IMO fat arrow const/let kids don't know about walking uphill to school both ways. Also I agree with commenters who use prev instead of acc, it is much easier on my brain to use prev.
TypeScript basically ruined reduce for me though, so there is that.
tantalor · 1789602171 · focus · HN ↗
My favorite gotcha is Java's `Stream.reduce(accumulator)` doesn't call the accumulator if your stream has zero or one elements. This is used for `min(comparator)` and `max(comparator)`. It's very funny when the comparator throws, but only when you have 2 or more elements.
1. ndriscoll · 1789612418 · focus · HN ↗
  How is that a gotcha? If there aren't two elements how could you possibly expect a function with two arguments to be called? What would you call it with?
  1. tantalor · 1789658111 · focus · HN ↗
    You can easily write the code with only one-arg functions. Example:
    myStream.min(Comparator.comparingDouble((obj) -> { ... }));
    You might think: it will map over the objects and convert each object to an number, and take the object with the lowest value. Except that's not what it does. You'd be wrong!
    ndriscoll · 1789659553 · focus · HN ↗
    Comparator.comparingDouble returns a comparator, which is a two argument function, which is what min expects. Min can't know how your comparator is defined without reflection to do that kind of peeking, and as you point out, that kind of peeking would cause observable differences in behavior.
    min is a generic method. All it knows is it has a Stream<T> and a function taking two Ts. The only thing it can do is plug in Ts it gets from the stream.
very-old-sw · 1789603179 · focus · HN ↗
reduce with barriers is essential in parallel functional programming. See the CUDA thrust package.
very-old-sw · 1789603240 · focus · HN ↗
Reduce with barriers is essential (and amazingly powerful) in parallel functional programming languages like CUDA Thrust.
1. odo1242 · 1789605001 · focus · HN ↗
  Yea, reduce is most useful as a parallel operation, like in MapReduce
Bayard_ne · 1789604005 · focus · HN ↗
Yeah, it usually adds cognitive load for anything beyond basic summation. Simpler to just use a good old `for` loop.
grommet_kit · 1789604554 · focus · HN ↗
Totally get it. `reduce` feels like a hammer for every nail; often `map` or `filter` makes intent clearer for others.
keychera · 1789604956 · focus · HN ↗
I came to like reduce when I learned clojure transducers. even in clojure, I always go for looping construct before transducer and then both reduce and transducer just clicked at the same time and I like reduce more now.
RomanKornev · 1789606146 · focus · HN ↗
Every single `reduce` can be replaced with a more intuitive `groupBy`, `partition`, `mapValues`, `keyBy`, etc.
Reduce can approximate anything, that doesn't mean we should use it.
My favorite antipattern is
```
  items.reduce(
    (acc, item) =&gt; ({
      ...acc,
      [item.id]: item,
    }), {}
  );
```
Like, why? Not only is this ridiculously inefficient O(N^2), it's also longer and less understandable than "build a new map" version.
1. wingman-jr · 1789608467 · focus · HN ↗
  I think this along with the other answers discussing the difficulty remembering the specific arguments of `reduce` (especially when varying by language!) are key reasons. After reading this conversational thread, I think maybe Microsoft got it right with LINQ: - `Where` is perhaps more intuitive than `filter` - `Select` seems no worse than `map` by invoking SQL-like syntax - While `reduce` is preserved as `Aggregate`, provide `GroupBy` and other handy methods as the preferred methods. In the code I write, it's probably these other methods that get called 95+% of the time. Who wants to `Aggregate` when they can simply `Sum` for example?
  1. int_19h · 1789797030 · focus · HN ↗
    LINQ was very intentionally designed to use SQL terminology for this because at the time (to remind, this was 2007), your typical C# or VB developer had no clue whatsoever about functional programming and the usual terminology there, while SQL knowledge would be much more widespread.
2. tehnub · 1789619225 · focus · HN ↗
  This one doesn't seem expressible in those terms:
  from functools import reduce df = reduce(DataFrame.union, dfs)
remywang · 1789606741 · focus · HN ↗
I’m so confused, how are you supposed to perform aggregation without reduce? This is like saying “I like plus and times, but I don’t like divide because it’s hard.” I mean sure, but you need it??
1. jay_kyburz · 1789607311 · focus · HN ↗
  Yeah, but you never _need_ reduce. You can just have a boring loop.
  I like boring code.
  1. lkuty · 1789623360 · focus · HN ↗
    Not in Elixir. Unless you use tail recursion to simulate the loop. I love reduce and the other functions of the Enum module, so I have 165 calls to reduce in my code base (plus 338 map and 116 filter). It's the swiss army knife of functional programming and I don't see any problem with its usage.
hibikir · 1789607826 · focus · HN ↗
You didn't get that complaint in Clojure, just like you wouldn't in Scala or Haskell, is that once you have any expectation that your users know a little bit of category theory, and possibly also thinking in types, it's all quite easy. Even fold is kind of easy, with the more complex signature. But passing [A][A,A =>A] kind of sucks for those that don't think of functional programming. and [A][A,B => A] is even worse. It's often bad enough to get people to build a comparator.
Every industry language keeps gaining more and more functional features: Many a new Java version is adding a bunch of scala features with worse syntax. But we don't train people on functional programming at all, so by the time they've built their instincts, passing functions makes no sense to them, immutability is alien, and the idea of a pure function seems irrelevant to them. Thus, they don't get exposed to the building blocks that make reduce seem simple. We always teach them recursion, but the rest? Too little, too late.
I could tell you of a bunch of ways to simplify the signature by, say, mandating that one passes a monoid or something like that, but while the signature would be easier, the very same people that are only used to imperative OO will not have an easier time, because they might have studied 2 years of calculus, but they've never even smelled abstract algebra. You can walk out of not just a programming bootcamp, but many a computer science degree without learning a word of this. Therefore, it all remains complicated.
1. yen223 · 1789608621 · focus · HN ↗
  Clojure specifically elevated the status of the reduce function because of transducers, a powerful but not very intuitive (imo) approach to composing functions.
2. runeblaze · 1789617708 · focus · HN ↗
  > once you have any expectation that your users know a little bit of category theory
  I don't know that's a safe assumption tbh. Try throwing them some chapter 2 exercises from any category theory textbook.
jan_m_savage · 1789607886 · focus · HN ↗
[dead]
elgertam · 1789608196 · focus · HN ↗
The only part of "hard to read" that has ever made sense is that the callback takes multiple args and sometimes I can't remember the order of the initial value versus the accumulator.
Incidentally, reduce is also powerful enough to implement both map and filter in terms of itself, though that's more of a teaching exercise than a good recommendation.
I mostly interpret it as of the same spirit with those who oppose proper tail calls because it "ruins" their debugging stack traces.
txhwind · 1789609804 · focus · HN ↗
In imperative languages, it's a leaky abstraction not reducing the cognition overhead, compared with the plain loop.
ggorlen · 1789611860 · 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://wiki.c2.com/?PrincipleOfLeastPower" rel="nofollow">https://wiki.c2.com/?PrincipleOfLeastPower
1. marcta · 1789623425 · focus · HN ↗
  Why is arr.filter().map() better than arr.reduce()? Doesn't arr.reduce() only loop once through the array?
  1. FlameWolf · 1789624453 · focus · HN ↗
    Exactly. If I need just filter/map/some etc., I use it. But if I need a combination of more than one, that's a job for reduce().
    ggorlen · 1789650764 · focus · HN ↗
    So you prefer
    arr.reduce((acc, el) => { if (el % 2 === 0) { acc.push(el * 2); }
    return acc;
    }, []);
    over
    arr.filter(e => e % 2 === 0).map(e => e * 2)
    The only advantage of the reduction as I see it is performance, but this is highly dubious and would need to be profiled for proof (I've never seen this matter in practice). And if perf does matter, a for..of loop would be clearer and one-pass:
    const result = []; for (const el of arr) { if (el % 2 === 0) { result.push(el); } }
    Exercises like this illustrate why technical verbal job interviews are useful in the age of LLMs--micro-taste preferences like this seems high signal (albeit not something I'd solely base a decision on).
    FlameWolf · 1790161373 · focus · HN ↗
    In my case, it's more of a personal preference than any measurable impact. Practically, `for...of` would be the best approach. But I like to avoid chaining and avoid manually building an array (in your example I'd replace `acc.push(el * 2);` with `return acc.concat(el * 2);` -- even though I suspect `push` might be more performant but not sure). Why do I prefer it? Can't explain. If the nanoseconds really mattered then I might change it. Otherwise it's just one of the many ways of achieving the same goal.
  2. QuercusMax · 1789625172 · focus · HN ↗
    Chained filter and map don't necessarily iterate multiple times. They certainly can but depending on how things are built they very often run as a single loop with the operations chained.
  3. ema · 1789628051 · focus · HN ↗
    For me it's about the speed of understanding what the code does. Because filter and map are very constrained in what they can do they quickly tell me a lot about the shape of the computation I'm working with. In contrast reduce is much more flexible and so I need to do a much more detailed analysis to just answer a basic question like "is the result a scalar or another collection?".
2. codethief · 1789635842 · focus · HN ↗
  One could also phrase this principle in terms of entropy (in the information-theoretic sense): If I read some code and come across filter() and map(), I already have a pretty good idea of what the code is doing, without even looking at the filter criterion or the mapping function. Entropy is low. (There's only so many filter and map functions you could write for any given type or pair of types.)
  Meanwhile, if I see reduce(), "anything" could happen. (Well, of course not anything but the set of possible reducers is surely much larger.) So entropy is high.
  Avoid high-entropy constructs in your code. Try to keep entropy as low as possible. (For the same reason, code with a principled approach regarding side effects is a lot better than code where any function could mutate global state at any given time.)
3. timtas · 1790027211 · 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 doe using it. Id be willing to use other functional method chains. But I would never listen to anyone who suggested using a procedural loop instead.
myaccountonhn · 1789617972 · focus · HN ↗
I personally find recursive functions mentally easier to write than folds. Maybe because I can never remember the argument ordering and the inferred types throw me off.
vova_hn2 · 1789619040 · focus · HN ↗
> reduce is less elegant in languages I use, like JavaScript, Python, and Swift. In my blissful stint as a Clojure developer, I did not get this feedback.
Two notes:
1. reduce if a part of functional programming vocab, so, obviously, a Clojure dev has to internalize it to be able to use the language properly. For other mentioned languages is not that necessary.
2. As a (mostly) Python dev, I think that list comprehensions and generator expressions are much easier to read and understand than map and filter. Although, people coming from other languages and having limited experience with Python specifically might disagree with me. Perhaps, we should think about inventing some nice syntax sugar that around the concept of `reduce`ing and `fold`ing, similar to what list comp/gen expr in Python did to concepts of `map`ing and `filter`ing.
1. vova_hn2 · 1789620881 · focus · HN ↗
  Actually, now that I think about it, with this new(-ish) (in)famous walrus operator and itertools recipes, I could sort of emulate reduce using gen expr
  First, I will need to steal a "consume" function from Itertools Recipes [0]:
  from collections import deque from itertools import islice def consume(iterator, n=None): "Advance the iterator n-steps ahead. If n is None, consume entirely." # Use functions that consume iterators at C speed. if n is None: deque(iterator, maxlen=0) else: next(islice(iterator, n, n), None)
  Isn't it a bit weird, that the fastest and easiest way to consume an iterator entirely is to feed it to a zero length deque? It is weird, but it was just an apéritif, lets move to the main course:
  lst = [1, 2, 3] acc = 0 consume((acc := acc + item for item in lst)) # this is the actual reduce print(acc)
  This is the line where the actual `reduce`ing happens:
  consume((acc := acc + item for item in lst))
  Basically, we use the fact that a "walrus" expression has a side effect and we just throw away the actual results of the iterator, because we don't need them.
  Is it more readable then normal reduce? I'm not sure. If I seen it in the actual production code, it would certainly raised my eyebrows. It is not a part of the normal Python "vocab" - a set of idioms that are considered "pythonic" and that you expect every Python dev to intuitively understand, so I would be very cautious in using it in the code that is intended to be read by other people.
  Why did I do it? I don't know, just a fun "what if?" thought experiment.
  [0] <a href="https://docs.python.org/3/library/itertools.html#itertools-recipes" rel="nofollow">https://docs.python.org/3/library/itertools.html#itertools-r...
  1. vova_hn2 · 1789621934 · focus · HN ↗
    Of course it is also possible to just create a temporary list and throw it away immediately:
    lst = [1, 2, 3] acc = 0 [acc := acc + item for item in lst] # this is the actual reduce print(acc)
    It should be possible to optimize away the creation of the temporary list and avoid wasting CPU and memory on it. But I don't know if CPython actually has this optimization, that's why I didn't mention it initially. I would love someone more knowledgeable in CPython internals to tell me how this would work.
fatbird · 1789624387 · focus · HN ↗
I had a client call me up and complain about my reduce code because it was hard to read and he couldn't tell what was going on. I broke through to him when I added comments to it that showed a particular data structure going in, and what was coming out. Once the transformation was clear, the apparent complexity was no longer a problem, leaving me to believe that the problem with reduce is almost entirely about legibility.
_moof · 1789625340 · focus · HN ↗
What's hard to understand about it? It's just
```
  x = initial
  for y in collection:
    x = f(y, x)
```
1. ema · 1789628755 · focus · HN ↗
  It's easy but it ain't simple. Because `f` can do arbitrary things to `x` you have to look at it just to know the general shape of the computation. Reduce gives you a lot of the flexibility of imperative programming but with that also a lot of the problems. Sometimes that's the right trade-off but it is good to be aware that it is a trade-off.
2. Joker_vD · 1789652747 · focus · HN ↗
  You mean "f(x, y)", right? Half of the languages that have reduce/fold use this ordering, another half uses yours.
  So in effect, as some other commenter said, it's just the loop with worse syntax.
dwoldrich · 1789626565 · focus · HN ↗
I am always happy when I find an opportunity to reduce or zip, so handy.
I also like Lodash'es transform[1]. It's like reduce, but expressly for transforming one collection to another. The signature is a slightly different from reduce in that the accumulator is a collection that is passed as an argument to the iteratee who is expected to mutate the accumulator with no need to return it. This frees up the return value from the iteratee for a new purpose: if the iteratee returns a boolean false, then transform early outs. I have used that feature more than once!
[1] <a href="https://lodash.com/docs#transform" rel="nofollow">https://lodash.com/docs#transform
globular-toast · 1789627545 · focus · HN ↗
Most programmers aren't comfortable with higher-order functions, in my experience. Map and filter are special cases that they may have learnt, but other less common cases they don't understand.
asgr · 1789628755 · focus · HN ↗
reduce is great - love it.
gg582 · 1789629513 · focus · HN ↗
Some conventions are socially made... In C, some uses
#if 0 these_lines_are(); not_executed(); #endif
but most of the cases people just use
/* comments * these_lines_are(); * not_executed(); * * end comment */
Then, why?
#if 0 #endif
looks clear and it definitely says how a computer skips many lines.
But we just don't use it because it implies low-level knowledge "that every C developers have"
1. draven · 1789632672 · focus · HN ↗
  My C is really rusty but aren't those different ? If using #if/#endif the compiler won't even see the comments.
  1. gg582 · 1789973400 · focus · HN ↗
    Yep that's right. Using #if/#endif excludes whole lines(so compiler won't see any lines). And this difference can prevent when struggling with nested comments :)
molvqingtai · 1789629822 · focus · HN ↗
I am using reduce to replace the nonlinear loop in the code instead of the for statement.
Anoian · 1789630381 · focus · HN ↗
I am a typescript dev and I like reduce but also feel like I am the exception.
The standard linter plugin eslint-plugin-unicorn even has a rule "no-array-reduce" that is part of the recommended config, which means most people using this plugin will have no reduce in their codebases:
<a href="https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-array-reduce.md" rel="nofollow">https://github.com/sindresorhus/eslint-plugin-unicorn/blob/m...
pjmlp · 1789630468 · focus · HN ↗
Not really, programmers only educated in traditional imperative programming I would assert.
flossly · 1789635061 · focus · HN ↗
Reduce is like `fold` in Haskell right? Fold in Haskell has many variant, I forgot exactly which, but I remember there were many.
I never met so many different variants of the `map` or `filter` function in Haskell.
Maybe this shows, in a different way from the reasons in the article, why reduce is harder than map/filter.
iforgotmypasswo · 1789635923 · focus · HN ↗
I liked reduce. You know, back when writing code was actually a thing we all did.
However, in those times of yore, I would often go back and remove it before committing. Unless you’re surrounded by other clever people, or it’s a personal project, you’re leaving behind some very elegant looking anxiety for the less gifted developers. Usually just to save one or two lines of code.
FacelessJim · 1789638972 · focus · HN ↗
Have they heard of our lord and saviour “mapreduce”?
``` x = mapreduce(f, r, arr, init) ```
equivalent to ``` x=init for e in arr r(x, f(e)) end ```
Of course, if r is ever something different than a simple operator, slap yourself. But otherwise it’s an absurdly powerful construct.
gorjusborg · 1789651766 · focus · HN ↗
I would guess that a dislike for reduce overlaps with a preference with imperative languages.
Filter and map are easy because you can make more assertions about them without inspection:
- they take a list-like as input
- they take a function as input
- they return a list-like as output
As opposed to reduce:
- it takes a list-like as input
- it takes a function as input
The output type is not fixed, and its behavior is not fixed. If you pass the right function, reduce is filter, or map, or something else we've never seen.
amluto · 1789660755 · focus · HN ↗
One issue I haven’t seen mentioned: map and filter have both obvious semantics and obvious implementations in the sense that (aside from possible laziness) there is really only one thing they could do, a parallel implementation is essentially semantically identical to a non-parallel implementation, and there are no potential numerical issues (used broadly in the sense of functions that are, say, ideally associative but not actually associative in real life). You apply the function to the input and you either collect or filter the results.
Reduce could mean one of quite a few things. (How many folds does Haskell have? At least six.) And most of them are, in a sense, so trivial that there is no real benefit to spelling it “fold” or “reduce” instead of just calculating it explicitly. (Okay, one can sometimes lazily fold a lazy list, for example by applying the identity. This is not the normal case, especially in eager languages, which is most of them.) And, if you just write a loop instead of “reduce”, then it’s more obvious what’s going on and why the code might be inefficient.
IMO the actually interesting case of reduce is the associative case, which can be parallelized. This is not the default in most languages.
cmrx64 · 1789661896 · focus · HN ↗
there are more interesting recursion schemes to traverse and aggregate with, but they are intricate to express without a powerful language and confuse small minds so aren’t worth often using.
randyrand · 1789691320 · focus · HN ↗
IMO it's primarily because it's a bad name. Names are important, as they reinforce your mental model.
Reduce means to take away.
But reduce isn't taking something away. It's squeezing something together. Combining multiple things into one. Reduce is poor verb for that.
It should've been called squash. Just like squash-merge.
romellem · 1789735493 · focus · HN ↗
It is too easy to write O(n^2) code using reduce, in fact I wrote an eslint rule to catch a common pattern I see other developers write.
- <a href="https://github.com/romellem/eslint-plugin-no-spread-in-reduce" rel="nofollow">https://github.com/romellem/eslint-plugin-no-spread-in-reduc...
It catches code that looks like this:
```
    items.reduce((acc, item) =&gt; {
      return {
        ...acc,
        [item.id]: item
      };
    });
```

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.