5 ms·

> Is functional style dead? No, the javascript ecosystem is just full of people who have taken some pattern that occurs frequently in functional programming, s

> Is functional style dead? No, the javascript ecosystem is just full of people who have taken some pattern that occurs frequently in functional programming, such as currying, to itself be functional programming, and thus write wrappers and overly complicated libraries to implement that feature and call it a functional wrapper or the functional version of the API, despite those features having very little to do with functional programming. Idiomatic javascript and typescript are full of functional programming, far more so than other major programming languages. Avoiding functional constructs would, in fact, make your code unidiomatic. So the functional style is about as far from dead as it could possibly be. Additionally, not only has the ecosystem been adopting a more functional style as time passes (especially due to features that have been added such as destructuring and spreading, which heavily encourage a more functional style), some of the core APIs in the standard library that used to make (pure) functional programming a bit more awkward by mutating their arguments now have pure equivalents [0][1] as well. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toReversed https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

recursive 3y ago
reduce() abuse is a peeve of mine.
- earthboundkid 3y ago
  I used to always use .forEach but now I use “of” as much as possible.
  - yakshaving_jgt 3y ago
    Map, reduce, and forEach are each for quite different things. When you say you always used to use forEach, are you saying that you used it for pure computations? Or is near enough everything you write effectful?
- virtue3 3y ago
  What got me to stop using reduce was when I and another sr. held a theoretical "gun" to a jr devs head and asked him what a block of code involving reduce did and they didn't have a clue. They were pretty bright; so I just threw it the towel at it being useful to the health of a large codebase after that. Still love map. But reduce can feel very "code golf" real quick.
  - yakshaving_jgt 3y ago
    I’m confused. Do you not think that would have been a good opportunity to teach that person what folds are for? Fold/reduce is fundamental. It’s weird to me that its use would be discouraged or outlawed somewhere.
    - jrockway 3y ago
      If your language has a `for` keyword, I would just say use the `for` keyword.
      - yakshaving_jgt 3y ago
        But why? The language I use has various flavours of `for`. It also has various flavours of map and fold. It also has recursion. They each do different things. Those differences are meaningful and useful. Why would you limit yourself to just using `for`?
      - izietto 3y ago
        It depends. It isn't the case for Ruby, for example.
  - thesnide 3y ago
    So. That. https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies.html https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies... "Easy to read" means "easy for others". Current efficiency is usually borrowed on future one.
    - 3y ago
- WirelessGigabit 3y ago
  How would you abuse reduce()?
  - Too 3y ago
    MDN even had to make a whole chapter to discourage overuse of it. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#when_to_not_use_reduce https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - masklinn 3y ago
    Using reduce to perform a map is a fun way to annoy colleagues.
    - 5e92cb50239222b 3y ago
      Or .map() as a for..of replacement. I always wanted V8/SpiderMonkey developers to make .map()/.reduce() "pure" in the sense of "optimizing away" the expression if its result is not assigned to anything, and see the world burn.
      - Zababa 3y ago
        I think .map() as a for...of replacement makes sense for simple cases. newArray = oldArray.map(el => aFunction(el)) is short, sweet and clean.
        orra 3y ago
        It's definitely short, but are you doing it for the side effects? Then I find .map() misleading. I'd much prefer a .forEach(), or a for...of.
        masklinn 3y ago
        If you’re mapping for side effects you deserve a good rap on the head. The main value of “map” is to denote a 1:1 data transformation. Plus this gets very fraught with many langages mapping lazily, and some not guaranteeing the order of operation.
- da39a3ee 3y ago
  Yes. In Scala people seem to say it's the idiomatic way to sum a list of numbers which never felt right to me. It just seems to much code to look at for that.
  - yakshaving_jgt 3y ago
    It definitely is the idiomatic way. How would you do it otherwise? Recursion?
  - secdeal 3y ago
    in Scala the idiomatic way to sum is the method sum on collections List(1,2,3,4).sum Although this is indeed implemented with reduce. But is it really too much code? List(1,2,3).reduce(_ + _)
  - BigJono 3y ago
    Summing a list of numbers is the exact kind of use case you should use reduce for. If it feels wrong to you it's just because you have more experience with for loops than reducers. In languages like JS that have both styles, the place you probably want to use for loops over reducers is for more complex operations where mutation can simplify the code. For example if you have 10,000 elements in an array that you want to aggregate into 1,000 properties on an object (with a non trivial relationship between array elements and object properties), it's probably going to look nicer in a for loop than it is in a reducer with a bunch of spread and ternary operators. IMO .reduce calls should probably be one line. If not then it's time to either write a for loop or compose more smaller functions. Avoiding them entirely is just FUD though. To compare summing an array in JS: let sum = 0; for (const n of numbers) { sum += n; } const sum = numbers.reduce((acc, n) => acc + n, 0); The latter is much nicer to read if you're used to both styles. What I particularly like about it is it clearly signals that 'sum' is a variable that we will be using further down. The for loop style leaves ambiguity as to whether 'sum' is going to be used later or if it's just some context for something that's happening inside the loop. Actually, to throw a hot take in the mix here, I think people should be more accepting of multiple statements across single lines in C-style languages. let sum = 0; for (const n of numbers) sum += n; That would be a perfectly fine way to signal to the reader that "this is a specific line of code to produce a sum value" (much the same as the reduce example), but people seem to have a dogmatic aversion to leaving braces off if/for statements or putting multiple statements on a single line.
dfgdfg34545456 3y ago
But lodash has a curry wrapper? So I'm still not understanding what functional wrappers the author is talking about that are so problematic.
ahartmetz 3y ago
> currying Ugh. It seems like such a combination of shallow, weird, and useless to me, I find it hard not to stop reading any "Intro to FP" article that sings its praises as one of the first things. The big deal about FP is that you can see more easily what the damn function will do when you call it. A weird and long-winded notation for multiple inputs contributes jack.

recursive 3y ago

reduce() abuse is a peeve of mine.

earthboundkid 3y ago
I used to always use .forEach but now I use “of” as much as possible.
- yakshaving_jgt 3y ago
  Map, reduce, and forEach are each for quite different things. When you say you always used to use forEach, are you saying that you used it for pure computations? Or is near enough everything you write effectful?
virtue3 3y ago
What got me to stop using reduce was when I and another sr. held a theoretical "gun" to a jr devs head and asked him what a block of code involving reduce did and they didn't have a clue. They were pretty bright; so I just threw it the towel at it being useful to the health of a large codebase after that. Still love map. But reduce can feel very "code golf" real quick.
- yakshaving_jgt 3y ago
  I’m confused. Do you not think that would have been a good opportunity to teach that person what folds are for? Fold/reduce is fundamental. It’s weird to me that its use would be discouraged or outlawed somewhere.
  - jrockway 3y ago
    If your language has a `for` keyword, I would just say use the `for` keyword.
    - yakshaving_jgt 3y ago
      But why? The language I use has various flavours of `for`. It also has various flavours of map and fold. It also has recursion. They each do different things. Those differences are meaningful and useful. Why would you limit yourself to just using `for`?
    - izietto 3y ago
      It depends. It isn't the case for Ruby, for example.
- thesnide 3y ago
  So. That. https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies.html https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies... "Easy to read" means "easy for others". Current efficiency is usually borrowed on future one.
  - 3y ago
WirelessGigabit 3y ago
How would you abuse reduce()?
- Too 3y ago
  MDN even had to make a whole chapter to discourage overuse of it. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#when_to_not_use_reduce https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- masklinn 3y ago
  Using reduce to perform a map is a fun way to annoy colleagues.
  - 5e92cb50239222b 3y ago
    Or .map() as a for..of replacement. I always wanted V8/SpiderMonkey developers to make .map()/.reduce() "pure" in the sense of "optimizing away" the expression if its result is not assigned to anything, and see the world burn.
    - Zababa 3y ago
      I think .map() as a for...of replacement makes sense for simple cases. newArray = oldArray.map(el => aFunction(el)) is short, sweet and clean.
      - orra 3y ago
        It's definitely short, but are you doing it for the side effects? Then I find .map() misleading. I'd much prefer a .forEach(), or a for...of.
        masklinn 3y ago
        If you’re mapping for side effects you deserve a good rap on the head. The main value of “map” is to denote a 1:1 data transformation. Plus this gets very fraught with many langages mapping lazily, and some not guaranteeing the order of operation.
da39a3ee 3y ago
Yes. In Scala people seem to say it's the idiomatic way to sum a list of numbers which never felt right to me. It just seems to much code to look at for that.
- yakshaving_jgt 3y ago
  It definitely is the idiomatic way. How would you do it otherwise? Recursion?
- secdeal 3y ago
  in Scala the idiomatic way to sum is the method sum on collections List(1,2,3,4).sum Although this is indeed implemented with reduce. But is it really too much code? List(1,2,3).reduce(_ + _)
- BigJono 3y ago
  Summing a list of numbers is the exact kind of use case you should use reduce for. If it feels wrong to you it's just because you have more experience with for loops than reducers. In languages like JS that have both styles, the place you probably want to use for loops over reducers is for more complex operations where mutation can simplify the code. For example if you have 10,000 elements in an array that you want to aggregate into 1,000 properties on an object (with a non trivial relationship between array elements and object properties), it's probably going to look nicer in a for loop than it is in a reducer with a bunch of spread and ternary operators. IMO .reduce calls should probably be one line. If not then it's time to either write a for loop or compose more smaller functions. Avoiding them entirely is just FUD though. To compare summing an array in JS: let sum = 0; for (const n of numbers) { sum += n; } const sum = numbers.reduce((acc, n) => acc + n, 0); The latter is much nicer to read if you're used to both styles. What I particularly like about it is it clearly signals that 'sum' is a variable that we will be using further down. The for loop style leaves ambiguity as to whether 'sum' is going to be used later or if it's just some context for something that's happening inside the loop. Actually, to throw a hot take in the mix here, I think people should be more accepting of multiple statements across single lines in C-style languages. let sum = 0; for (const n of numbers) sum += n; That would be a perfectly fine way to signal to the reader that "this is a specific line of code to produce a sum value" (much the same as the reduce example), but people seem to have a dogmatic aversion to leaving braces off if/for statements or putting multiple statements on a single line.

dfgdfg34545456 3y ago

But lodash has a curry wrapper? So I'm still not understanding what functional wrappers the author is talking about that are so problematic.

ahartmetz 3y ago

> currying Ugh. It seems like such a combination of shallow, weird, and useless to me, I find it hard not to stop reading any "Intro to FP" article that sings its praises as one of the first things. The big deal about FP is that you can see more easily what the damn function will do when you call it. A weird and long-winded notation for multiple inputs contributes jack.