(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.
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.
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.
> 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.
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.
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.
the_other · · focus · HN ↗
I really like taking the implementation away from the call site, so that the call site reads
(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.
anyfoo · · focus · HN ↗
Honestly, sounds like the reviewer failed the interview, not the other way around.
baxuz · · focus · HN ↗
anyfoo · · focus · HN ↗
the_other · · focus · HN ↗
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.
xp84 · · focus · HN ↗
Wow. That is the kind of monkey business that would have me running for the exits. Yikes.
Joker_vD · · focus · HN ↗
xp84 · · focus · HN ↗
But if someone's 28 and doing that stuff in Python or JavaScript, they're a bit of a loon, imho.
kenferry · · focus · HN ↗
I agree, but I think that’s kind of the objection. It can be tempting to write your code as little brainteasers but…