7 ms·

John-David Dalton, the lodash author, wrote [this last year][1]: > For the lodash rewrite I’m declaring tech debt bankruptcy. Starting from scratch with TypeSc

John-David Dalton, the lodash author, wrote [this last year][1]: > For the lodash rewrite I’m declaring tech debt bankruptcy. Starting from scratch with TypeScript and Rollup. No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Don’t know if he’s sticking to this 100% but seems pretty close. [1]: https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238

gorgoiler 3y ago
What were FP wrappers and what was the fad?
- stolenmerch 3y ago
  "Auto-curried function style (reversed arg) wrappers" https://twitter.com/jdalton/status/1571870137690591236 https://twitter.com/jdalton/status/1571870137690591236
  - legulere 3y ago
    And what is that?
    - janehdoch 3y ago
      [flagged]
    - gorgoiler 3y ago
      Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments. A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs. Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.
    - eddythompson80 3y ago
      https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide Basically flipping around the args in a function and returning a "curried" function call. So instead of _.map(["1"], parseInt) it's the other way around, _.map(parseInt, ["1"]) That way you can do something like const parseArrayFunc = _.map(parseInt) const parsed = parseArrayFunc(["1"]) This pattern is called currying in functional programming.
      - kristjansson 3y ago
        The complaint, I would think, being with the machinery to make _.map return a function or a value depending on the number of args, not with the flipping/arg order stuff?
        deleted 3y ago
        [deleted]
        eddythompson80 3y ago
        Yeah I’d think so too. FP languages like Haskell or F# has partial application as part of the language itself and you get it for free by just ordering the parameters that way.
      - gorgoiler 3y ago
        Partial application makes sense to me as a useful computer science concept. Reasoning about functions when they always have 1-arity makes proofs possible. In software though, it just seems like code golf for people who can’t or won’t write a function as a way of sharing code between call sites: def serialize(fn, data, path): … yamlize = partial( serialize, yaml.dump ) jsonize = partial( serialize, json.dumps ) Presumably some of these people wake up in a cold sweat about the shame of typing “partial(serialize, …)” twice and do this: def serialize(fn, data, path): … a = lambda f: partial(serialize, f) yamlize = a(yaml.dump) jsonize = a(json.dumps) A good example of Don’t Repeat Yourself mutating into Never Repeat Yourself with ill effect, because the developer has self flagellated so much that the following code is deemed to have too much repetition in it: def write(data, path): … def write_yaml(data, path): write(yaml.dump(data), path) def write_json(data, path): write(json.dumps(data), path)
    - RedNifre 3y ago
      As an illustration, I wrote a Sokoban game in that style (no mutation, no side effects, partial application everywhere). See https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game.js https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game...
  - mostlylurks 3y ago
    Calling these "FP wrappers" is doing quite a disservice to functional programming, which by no means necessitates that functions are curried, and which is basically the idiomatic way of writing javascript / typescript these days. You don't need (and probably shouldn't use) wrappers of any kind to write perfectly ordinary FP-style code in javascript / typescript. I'd hope people wouldn't associate such wrappers with FP, because what they accomplish is something relatively orthogonal to FP.
    - bradrn 3y ago
      Absolutely. I use Haskell as my main language for personal projects, and I like FP a lot — but I’ve seen some really horrible stuff marketed as ‘FP’ lately, especially in languages like JavaScript.
  - yawnxyz 3y ago
    Functional programming wrappers? I recently discovered Ramda JS as an alternative to Lodash / Underscore and it's surprisingly fresh to write in. It can get a bit complicated sometimes, but that's when GPT-4 comes to the rescue...
- technion 3y ago
  One of the big issues with the fp javascript trend was that coding patterns which work well in languages like closure or Haskell had a kind of "let's shoehorn this into js". There was a tonne of blogspot on "how to write functional javascript" that followed this pattern of currying all the time in a language where it just doesn't result in particularly readable code. I'm glad it's falling out of fashion.
  - at_a_remove 3y ago
    One of my subtle peeves is people who loved doing A Thing in one language feel like they have to cram it into the next language they move to, whether or not it works. Python is becoming a victim of this weird habit.
    - thristian 3y ago
      "...the determined Real Programmer can write Fortran programs in any language."
      - at_a_remove 3y ago
        And you know I originally made that mistake! Only with Pascal. I was hoping for functions and procedures in Python, but I eventually had to learn that Python isn't about that. I had to take the language on its own terms.
        EVa5I7bHFq9mnYK 3y ago
        Pascal was a peak programming language IMO, everything went downhill from there ...
    - EdwardDiego 3y ago
      What's bad and happening to Python? If it's type hints, they're an invaluable addition for large codebases IMO, and they're entirely optional unless you set up tooling to enforce them.
- JuanPosadas 3y ago
  IME there was a fad (that thankfully never picked up) where people were talking about making giant unreable piles of curry functions and calling it finally, some good functional js. They looked like write-only code to me and at high-risk of assaulting the GC (aka slower than lodash).
tibbon 3y ago
I’m truly under-educated on JS issues. What is wrong with FP in this context?
- rutierut 3y ago
  Nothing really but besides it not working with typings too well it’s just quite uncommon. I love it personally but strictly use it on personal projects, this is really not something one should introduce to a project that multiple people are working on.
preommr 3y ago
> That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Is he not the original author? This is phrased like someone else added the complexity he's decrying. If he's the one that introduced it then instead of talking about it as an introspective or something that they learned from, he's talking about it like he develops projects according to fads and that's it's time to move on to the next one now that this one has ended.
- jauntywundrkind 3y ago
  lodash/fp is an optional distribution of lodash that did what the core library did, but did so in a more flexible, powerful, composeable way that makes it easier to construct powerful functions. it was separate from the core, but based heavily on it. https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide at the time, nothing was settled. we were in a pioneering mode of building; we didn't know what people would find useful or what the future would hold. there were a lot of different ideas floating around, and lodash was trying to stay the same while also offer a port to this barely-subtly-different paradigm, to see what value might be found there. saying that "introduced" it feels like a crude reduction to me; he allowed people the option they asked for. i personally think fp - in particular - "pointsfree" fp - has huge down sides to being understandable. but fp in general also is a much more succinct and capable way of expressing things, and multiple times a week i run into situations where auto-currying or reverse args would make the code i write much cleaner & not damage code comprehension. rather than call fp a fad, & insult the author for ever letting it in, i think there's room to say that it's sad that js had to stay on the lowest common denominator. the future was unable to be changed, the old ways stuck. we lost some really good opportunity & capabilities. that said, i still think the pointsfree style is hugely damaging & responsible for greatly reducing the chances we had to improve. instead, we're not "moving on", we're going back to square 1, to the only thing we've ever known or done. that makes me a little sad, to have the pioneers pack up & move back into the city. what really scares me is the attitude that every failed pioneering expedition is a "fad" and that we shouldn't ever try things. lodash-fp was a harmless small token offering to possibility, and should be respected, whatever your view on fp.

gorgoiler 3y ago

What were FP wrappers and what was the fad?

stolenmerch 3y ago
"Auto-curried function style (reversed arg) wrappers" https://twitter.com/jdalton/status/1571870137690591236 https://twitter.com/jdalton/status/1571870137690591236
- legulere 3y ago
  And what is that?
  - janehdoch 3y ago
    [flagged]
  - gorgoiler 3y ago
    Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments. A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs. Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.
  - eddythompson80 3y ago
    https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide Basically flipping around the args in a function and returning a "curried" function call. So instead of _.map(["1"], parseInt) it's the other way around, _.map(parseInt, ["1"]) That way you can do something like const parseArrayFunc = _.map(parseInt) const parsed = parseArrayFunc(["1"]) This pattern is called currying in functional programming.
    - kristjansson 3y ago
      The complaint, I would think, being with the machinery to make _.map return a function or a value depending on the number of args, not with the flipping/arg order stuff?
      - deleted 3y ago
        [deleted]
      - eddythompson80 3y ago
        Yeah I’d think so too. FP languages like Haskell or F# has partial application as part of the language itself and you get it for free by just ordering the parameters that way.
    - gorgoiler 3y ago
      Partial application makes sense to me as a useful computer science concept. Reasoning about functions when they always have 1-arity makes proofs possible. In software though, it just seems like code golf for people who can’t or won’t write a function as a way of sharing code between call sites: def serialize(fn, data, path): … yamlize = partial( serialize, yaml.dump ) jsonize = partial( serialize, json.dumps ) Presumably some of these people wake up in a cold sweat about the shame of typing “partial(serialize, …)” twice and do this: def serialize(fn, data, path): … a = lambda f: partial(serialize, f) yamlize = a(yaml.dump) jsonize = a(json.dumps) A good example of Don’t Repeat Yourself mutating into Never Repeat Yourself with ill effect, because the developer has self flagellated so much that the following code is deemed to have too much repetition in it: def write(data, path): … def write_yaml(data, path): write(yaml.dump(data), path) def write_json(data, path): write(json.dumps(data), path)
  - RedNifre 3y ago
    As an illustration, I wrote a Sokoban game in that style (no mutation, no side effects, partial application everywhere). See https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game.js https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game...
- mostlylurks 3y ago
  Calling these "FP wrappers" is doing quite a disservice to functional programming, which by no means necessitates that functions are curried, and which is basically the idiomatic way of writing javascript / typescript these days. You don't need (and probably shouldn't use) wrappers of any kind to write perfectly ordinary FP-style code in javascript / typescript. I'd hope people wouldn't associate such wrappers with FP, because what they accomplish is something relatively orthogonal to FP.
  - bradrn 3y ago
    Absolutely. I use Haskell as my main language for personal projects, and I like FP a lot — but I’ve seen some really horrible stuff marketed as ‘FP’ lately, especially in languages like JavaScript.
- yawnxyz 3y ago
  Functional programming wrappers? I recently discovered Ramda JS as an alternative to Lodash / Underscore and it's surprisingly fresh to write in. It can get a bit complicated sometimes, but that's when GPT-4 comes to the rescue...
technion 3y ago
One of the big issues with the fp javascript trend was that coding patterns which work well in languages like closure or Haskell had a kind of "let's shoehorn this into js". There was a tonne of blogspot on "how to write functional javascript" that followed this pattern of currying all the time in a language where it just doesn't result in particularly readable code. I'm glad it's falling out of fashion.
- at_a_remove 3y ago
  One of my subtle peeves is people who loved doing A Thing in one language feel like they have to cram it into the next language they move to, whether or not it works. Python is becoming a victim of this weird habit.
  - thristian 3y ago
    "...the determined Real Programmer can write Fortran programs in any language."
    - at_a_remove 3y ago
      And you know I originally made that mistake! Only with Pascal. I was hoping for functions and procedures in Python, but I eventually had to learn that Python isn't about that. I had to take the language on its own terms.
      - EVa5I7bHFq9mnYK 3y ago
        Pascal was a peak programming language IMO, everything went downhill from there ...
  - EdwardDiego 3y ago
    What's bad and happening to Python? If it's type hints, they're an invaluable addition for large codebases IMO, and they're entirely optional unless you set up tooling to enforce them.
JuanPosadas 3y ago
IME there was a fad (that thankfully never picked up) where people were talking about making giant unreable piles of curry functions and calling it finally, some good functional js. They looked like write-only code to me and at high-risk of assaulting the GC (aka slower than lodash).

tibbon 3y ago

I’m truly under-educated on JS issues. What is wrong with FP in this context?

rutierut 3y ago
Nothing really but besides it not working with typings too well it’s just quite uncommon. I love it personally but strictly use it on personal projects, this is really not something one should introduce to a project that multiple people are working on.

preommr 3y ago

> That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Is he not the original author? This is phrased like someone else added the complexity he's decrying. If he's the one that introduced it then instead of talking about it as an introspective or something that they learned from, he's talking about it like he develops projects according to fads and that's it's time to move on to the next one now that this one has ended.

jauntywundrkind 3y ago
lodash/fp is an optional distribution of lodash that did what the core library did, but did so in a more flexible, powerful, composeable way that makes it easier to construct powerful functions. it was separate from the core, but based heavily on it. https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide at the time, nothing was settled. we were in a pioneering mode of building; we didn't know what people would find useful or what the future would hold. there were a lot of different ideas floating around, and lodash was trying to stay the same while also offer a port to this barely-subtly-different paradigm, to see what value might be found there. saying that "introduced" it feels like a crude reduction to me; he allowed people the option they asked for. i personally think fp - in particular - "pointsfree" fp - has huge down sides to being understandable. but fp in general also is a much more succinct and capable way of expressing things, and multiple times a week i run into situations where auto-currying or reverse args would make the code i write much cleaner & not damage code comprehension. rather than call fp a fad, & insult the author for ever letting it in, i think there's room to say that it's sad that js had to stay on the lowest common denominator. the future was unable to be changed, the old ways stuck. we lost some really good opportunity & capabilities. that said, i still think the pointsfree style is hugely damaging & responsible for greatly reducing the chances we had to improve. instead, we're not "moving on", we're going back to square 1, to the only thing we've ever known or done. that makes me a little sad, to have the pioneers pack up & move back into the city. what really scares me is the attitude that every failed pioneering expedition is a "fad" and that we shouldn't ever try things. lodash-fp was a harmless small token offering to possibility, and should be respected, whatever your view on fp.