5 ms·

I'm not opposed to using `reduce` where it solves a problem in a readable or performant way, but it seems there's a trend among JS developers recently (I notice

I'm not opposed to using `reduce` where it solves a problem in a readable or performant way, but it seems there's a trend among JS developers recently (I noticed this in the react ecosystem) to use `map` / `reduce` for _everything_. Sure, _some_ problems can be solved elegantly and efficiently with it, but a lost of the time it just impedes readability, and maintainability of the code. A `for of` loop (or your C-styled for loop) would sometimes be better suited.

Waterluvian 7y ago
I think it's perfectly fine in many cases. Like say writing a listToKeyed function. Where I find it fails is when there's a ton of imperative code that's really hard to understand the premise. The beauty of functional programming is that you can take these stanzas and break them into nicely testable, named functions.
- minitech 7y ago
  What’s a listToKeyed function?
  - spoiler 7y ago
    I think they mean something that turns a list (array) of unique elements into a keyed collection (like a map or an object). So something like: [ {id: 1, name: 'Jane'}, {id: 2, name: 'John'} ] becomes { 1: {id: 1, name: 'Jane'}, 2: {id: 2, name: 'John'} }
    - imtringued 7y ago
      This is driving me mad. This operation is called groupBy and it is a solved problem. How on earth is HN oblivious to such a fundamental operation?
      - minitech 7y ago
        Who’s HN here? What’s driving you mad? Not really clear what your point is.
noir_lord 7y ago
You have to know both methods and the trade off for each. The performance differences can be quite marked as well. I wrote some code the other day that could have been done with forEach more readably but I just used regular for loops because I was working with what was effectively a 3D array (grid/cell/contents) and know that for can be nearly twice as fast as foreach.
snek 7y ago
in ##javascript on freenode this comes up so often we have a macro saved to one of our irc bots explaining why forEach, map, etc are better alternatives to reduce in many common situations. by far the most common situation is people reducing arrays into an object when they could be using a simple forEach. The first example in the article is actually this exact thing. It's also awkward considering they mention they're trying to do a "lookup" which makes it sound like they could just do find on the array and be done with it. sidenote, i really do enjoy code typeset with typewriter fonts for short codeblocks like in the article
PopeDotNinja 7y ago
Wouldn't map and reduce be more readable if you were used to reading it? I've been using a lot of Elixir and Ruby, both of which use map and reduce, and neither of which make extensive use of for loops. Map and reduce are what I am used to reading.
- spoiler 7y ago
  When you have some imperative code inside the reduce function and you have to go out of your way to achieve something (ie, immutability by using Object.assign, spread, or Array.prototype.concat, etc) and on top of that have some conditional and imperative code, then the reduce function stops being elegant, and looks horrible. Sure, every problem can be solved in a functional way, but JavaScript is not a purely functional language. Why limit yourself to a subset of the language? IMO, you should use the best tool you can for the problem. Sometimes that's reduce, sometimes it's not. Also, I love Ruby (and used Elixir), and it's not really a comparison that makes sense, they're different languages with different APIs, syntax, and there's a category of problems in JS you never have to think about when using Erlang/Elixir, or Ruby. I could say that I'm used to seeing maps and folds in Haskell code; doesn't really mean anything in this discussion.
hn_throwaway_99 7y ago
I agree. I'm a big fan of functional-style JS but I've seen people waste a ton of time tying themselves in knots trying to get a reduce solution working where a for loop would be trivial (and more readable). For example, the "use reduce to run asynchronous calls in sequence" is an important pattern, and was pretty much the best way to do this (or another way that was basically equivalent) before async/await. With async/await, though, it's trivial (and in my opinion more readable) to just do this in a for loop with await. So I found it a bit odd that his reducer function used async/await syntax. There was an article on HN recently about "don't compromise simplicity for dogma", and I think that applies here.

Waterluvian 7y ago

I think it's perfectly fine in many cases. Like say writing a listToKeyed function. Where I find it fails is when there's a ton of imperative code that's really hard to understand the premise. The beauty of functional programming is that you can take these stanzas and break them into nicely testable, named functions.

minitech 7y ago
What’s a listToKeyed function?
- spoiler 7y ago
  I think they mean something that turns a list (array) of unique elements into a keyed collection (like a map or an object). So something like: [ {id: 1, name: 'Jane'}, {id: 2, name: 'John'} ] becomes { 1: {id: 1, name: 'Jane'}, 2: {id: 2, name: 'John'} }
  - imtringued 7y ago
    This is driving me mad. This operation is called groupBy and it is a solved problem. How on earth is HN oblivious to such a fundamental operation?
    - minitech 7y ago
      Who’s HN here? What’s driving you mad? Not really clear what your point is.

noir_lord 7y ago

You have to know both methods and the trade off for each. The performance differences can be quite marked as well. I wrote some code the other day that could have been done with forEach more readably but I just used regular for loops because I was working with what was effectively a 3D array (grid/cell/contents) and know that for can be nearly twice as fast as foreach.

snek 7y ago

in ##javascript on freenode this comes up so often we have a macro saved to one of our irc bots explaining why forEach, map, etc are better alternatives to reduce in many common situations. by far the most common situation is people reducing arrays into an object when they could be using a simple forEach. The first example in the article is actually this exact thing. It's also awkward considering they mention they're trying to do a "lookup" which makes it sound like they could just do find on the array and be done with it. sidenote, i really do enjoy code typeset with typewriter fonts for short codeblocks like in the article

PopeDotNinja 7y ago

Wouldn't map and reduce be more readable if you were used to reading it? I've been using a lot of Elixir and Ruby, both of which use map and reduce, and neither of which make extensive use of for loops. Map and reduce are what I am used to reading.

spoiler 7y ago
When you have some imperative code inside the reduce function and you have to go out of your way to achieve something (ie, immutability by using Object.assign, spread, or Array.prototype.concat, etc) and on top of that have some conditional and imperative code, then the reduce function stops being elegant, and looks horrible. Sure, every problem can be solved in a functional way, but JavaScript is not a purely functional language. Why limit yourself to a subset of the language? IMO, you should use the best tool you can for the problem. Sometimes that's reduce, sometimes it's not. Also, I love Ruby (and used Elixir), and it's not really a comparison that makes sense, they're different languages with different APIs, syntax, and there's a category of problems in JS you never have to think about when using Erlang/Elixir, or Ruby. I could say that I'm used to seeing maps and folds in Haskell code; doesn't really mean anything in this discussion.

hn_throwaway_99 7y ago

I agree. I'm a big fan of functional-style JS but I've seen people waste a ton of time tying themselves in knots trying to get a reduce solution working where a for loop would be trivial (and more readable). For example, the "use reduce to run asynchronous calls in sequence" is an important pattern, and was pretty much the best way to do this (or another way that was basically equivalent) before async/await. With async/await, though, it's trivial (and in my opinion more readable) to just do this in a for loop with await. So I found it a bit odd that his reducer function used async/await syntax. There was an article on HN recently about "don't compromise simplicity for dogma", and I think that applies here.