Hacker News Reader

Comment by Lx1oG-AWb6h_ZG0 | Hacker News Reader

I used to love using array.reduce when I was first learning JavaScript, but over the years, my opinion has firmly shifted to Jake Archibald’s:

“All code using array.reduce should be rewritten without array.reduce so it's readable by humans.

Ok ok, fair enough, there are cases where array.reduce is the best thing to use.

Specifically, cases where you want to look really smart and don't care about readability.”

https://mobile.twitter.com/jaffathecake/status/1213077702300...

Seriously, even the simplified repro example in the bug is not immediately obvious - I can only imagine how bad the actual code is.

View on HN

That is why learning programming languages is important. I would argue this concept is picked from functional ones. `reduce` function is not hard to read if you understand how it works and code is a lot easier to read because it does not introduce mutability. Even better - it has almost the same signature in other languages so you only need to learn it once.

I always forget the order of arguments and what they mean. For me it is an awful function that should not exist.

Isn't the solution there to name variables well?

A reduce function turns an array into a single value, passing the result of computation of each element to the next element. So, the signature is:

function (accumulator, element) -> accumulator

So, you take in some accumulated value (or the initial value on the first iteration) and an element and return the accumulated value to the next element. If the values were swapped, it would be inconsistent with the rest of the array functions where optional arguments are tacked on to the end (e.g. index, array), so the obvious assumption is that the accumulator goes in front to keep the rest of it as similar to the other array functions as possible.

I think it's unfortunate that array.reduce takes the accumulator after the function, but that also makes sense since it's technically valid to omit the accumulator (defaults to undefined).

The problem, I think, is that reduce is often abused when another function might make more sense (e.g. as a ghetto "find" or something). If it's used properly, I think it's quite elegant. If it's not, it's a confusing mess.

The accumulator goes on the left if you're folding left and on the right if you're folding right.

try implementing it, you only need to learn it once

I don't know if you looked at the example but the example given has two anonymous function inside the reduce and returns things(???), it's unreadable to me and I'm very comfortable reading functional code, but I don't know what the hell the example is supposed to be

> but the example given has two anonymous function inside the reduce and returns things(???)

Are you a javascript programmer? If not, then it's ok if the code in an unfamiliar language looks cryptic. But if yes, then the code example (is it the one with the Promise.resolve as an accumulator?) is a very idiomatic way of writing sequential http requests before we had async functions and stuff.

I don't quite get the author's beef, even from the screenshot he has a couple down.

I personally love reduce. Reduce is probably my favorite function an iterable, or enumerable, can have... Is it really that clever to map and then reduce something?

You can totally use reduce when you shouldn't or when it makes your life more difficult, but you can also eat fried chicken and drink hot coffee driving naked down the freeway during rush-hour.... it's up to you to make smart choices.

It is much more clever just to use a for .. in loop and write the actions sequentially rather than as a set of anonymous functions. Writing software should not be a competition about who knows more new features.

Reduce shouldn't be considered in the same category as nullish-coalescing. Reduce is on par with array.map. It's perfect for when you have an iterable and want to reduce it down, pair by pair, to one item. It should be used when that situation comes up, and it shouldn't be used outside of it. This is pretty cut and dried.

Is Array.map worth keeping?

Ah reduce/fold, if only it were as intuitive as map and filter. Reduce is great for specific circumstances and contrived homework problems. But come back to it after a while and it confounds you and you have to relearn it. There is elegance to reduce and its solutions and I'm sure many find it intuitive.

Personally, I think that if reduce is a single, reasonable length line, it's probably being used correctly. If it's a giant function, you're probably better off just using a regular loop.

Use it when it's clear and elegant, don't when it's not. Unfortunately, relatively junior programmers try to force it because it seems like a cool tool to use.

The example with the promises, if I read it correctly, is basically using reduce as an alternative way to do a for loop.

One of the easiest ways to tell that it’s a misuse of reduce is that the result is not being assigned to anything.

The times I use reduce are simple. I want to “reduce” a collection of some sort to a single value, without any side effects. It’s additionally beneficial if the action being performed can be encapsulated in a function, so I can simply pass the function in, instead of code. However, this isn’t necessary.

JS doesn’t enforce it, but the code my team and I write requires that reduce has no side effects (we enforce through code review).

The point is that when I come across reduce in our team’s code, the intention is communicated to me immediately. A collection of some sort was converted to a single value, and there were no side effects.

That won’t be my expectation if it’s a for loop, or a forEach, or a while.

If those conditions are not met for a reduce, then it’s a bug in the code, as far as my team is concerned.

> The example with the promises, if I read it correctly, is basically using reduce as an alternative way to do a for loop.

> One of the easiest ways to tell that it’s a misuse of reduce is that the result is not being assigned to anything.

The example with Promises is using the accumulator, it's just referring to it as "sequence" to more accurately describe what it using the accumulator for (to "sequence" in serial a set of Promises).

While the final result from the accumulator isn't assigned to anything in snippet as shown, one would easily imagine it being used as a "finished loading all of the chapters" promise before some other action.

It would definitely be a better example if the side effect (`addHtmlToPage`) wasn't performed inside the promise callbacks but on the results, but it's still an alright example of promise composition.

Though reduce for promise composition isn't a great example today when most cases these days you'd just want to write it async/await and a traditional for loop, with the browser or your transpiler doing the composition work for you, leaving it a clearer to read sequence of events.

The main argument for using reduce is when you really want to accomplish what you're doing in a single expression:

- Because you have an un-braced arrow function

- Because you want to guarantee* no side-effects

- Because it's in the middle of a React render, or similar

Certain things can only be accomplished in a single expression by using reduce. But I agree that unlike other list-comprehensions it's generally harder to read than the imperative equivalent, outside of simple cases like summing numbers or concatenating arrays.

* Of course you could technically create side-effects from within any of your list-comprehension callbacks; like most things in JavaScript, this is only enforced by convention

Reply on news.ycombinator.com