4 ms·

I've gone pretty deep down this particular FP rabbit hole in JS before. I'm not saying that it shouldn't be in your toolbox, but in my experience currying shoul

I've gone pretty deep down this particular FP rabbit hole in JS before. I'm not saying that it shouldn't be in your toolbox, but in my experience currying should not be something you regularly reach for.

toastal 3y ago
Agree & disagree. What you need is a language where all of these features are first class, piping/compose operators, etc. but without this, the code base becomes unidiomatic, hard to read, and difficult for coworkers to understand. Forcing it into JS is where you have a bad time – there are many options for functional languages that compile to JS tho.
- RussianCow 3y ago
  > there are many options for functional languages that compile to JS Arguably, depending on what you're building, the pain of integrating an entirely different language into your stack is greater than the pain of simply using something like Ramda (or, better yet, just writing simple, imperative code). YMMV of course—if the problems you're solving lend themselves naturally to purely functional code, maybe something like Rescript or PureScript may be worth it, but for most projects, I'd guess probably not.
  - scns 3y ago
    Rescript compiles to really efficient JS. Learning React with ReasonML (Rescripts predecessor) spoiled me, in a bad way. Waiting for TS to compile was really painfull. In Reason it took fractions of a second.
    - sprkv5 3y ago
      +1 the ReScript compiler is a beast: not only is it fast at generating JS, the JS it generates is optimised for performance[1]. If you are using React, it's better to go for ReScript rather than using Ramda or lodash-fp. 1. https://twitter.com/KrComet/status/1653351666446655488 https://twitter.com/KrComet/status/1653351666446655488
  - nine_k 3y ago
    Integrating a starkly different language has an upside: you have a clear separation line.
- Supermancho 3y ago
  > the code base becomes unidiomatic, Idiomatic describes the common practices of the ecosystem, without the features (specifically currying, since it's the only one mentioned). How does a codebase that doesn't use these features become unidiomatic?
  - toastal 3y ago
    Idiomatic JavaScript doesn’t use currying. If you add it to your code base, you are now siloing your project to folks that understand currying which has two problems: 1) hiring Joe Schmo to add/maintain will be harder 2) folks that understand currying will almost certainly be more happy & productive in a language that has currying by default & is idiomatic. For instance, the audience that sees fp-ts as a necessary, useful library to code in a manner they find most appropriate will find JavaScript/TypeScript ergonomics verbose, hard to read, and require someone with functional programming experience (see the verbosity according to their docs of TypeScript+fp-ts vs. PureScript: https://gcanti.github.io/fp-ts/guides/purescript.html https://gcanti.github.io/fp-ts/guides/purescript.html). That audience would be better suited doing compiled option such as the aforementioned PureScript, or js_of_ocaml, ReScript, derw, Idris, GHC.js/whatever the new GHC compiler JS output is, or similar option. These languages will have the idioms of fp-ts without the heavy reliance on singularly library most of the TypeScript community doesn’t understand that bloats their code bases without requiring the safety (someone can just call .value on a Maybe/Option breaking the safety). (This is not a knock against fp-ts which is a marvel in & of itself, but the audience doesn’t line up with the idioms of the average TypeScript project).

toastal 3y ago

Agree & disagree. What you need is a language where all of these features are first class, piping/compose operators, etc. but without this, the code base becomes unidiomatic, hard to read, and difficult for coworkers to understand. Forcing it into JS is where you have a bad time – there are many options for functional languages that compile to JS tho.

RussianCow 3y ago
> there are many options for functional languages that compile to JS Arguably, depending on what you're building, the pain of integrating an entirely different language into your stack is greater than the pain of simply using something like Ramda (or, better yet, just writing simple, imperative code). YMMV of course—if the problems you're solving lend themselves naturally to purely functional code, maybe something like Rescript or PureScript may be worth it, but for most projects, I'd guess probably not.
- scns 3y ago
  Rescript compiles to really efficient JS. Learning React with ReasonML (Rescripts predecessor) spoiled me, in a bad way. Waiting for TS to compile was really painfull. In Reason it took fractions of a second.
  - sprkv5 3y ago
    +1 the ReScript compiler is a beast: not only is it fast at generating JS, the JS it generates is optimised for performance[1]. If you are using React, it's better to go for ReScript rather than using Ramda or lodash-fp. 1. https://twitter.com/KrComet/status/1653351666446655488 https://twitter.com/KrComet/status/1653351666446655488
- nine_k 3y ago
  Integrating a starkly different language has an upside: you have a clear separation line.
Supermancho 3y ago
> the code base becomes unidiomatic, Idiomatic describes the common practices of the ecosystem, without the features (specifically currying, since it's the only one mentioned). How does a codebase that doesn't use these features become unidiomatic?
- toastal 3y ago
  Idiomatic JavaScript doesn’t use currying. If you add it to your code base, you are now siloing your project to folks that understand currying which has two problems: 1) hiring Joe Schmo to add/maintain will be harder 2) folks that understand currying will almost certainly be more happy & productive in a language that has currying by default & is idiomatic. For instance, the audience that sees fp-ts as a necessary, useful library to code in a manner they find most appropriate will find JavaScript/TypeScript ergonomics verbose, hard to read, and require someone with functional programming experience (see the verbosity according to their docs of TypeScript+fp-ts vs. PureScript: https://gcanti.github.io/fp-ts/guides/purescript.html https://gcanti.github.io/fp-ts/guides/purescript.html). That audience would be better suited doing compiled option such as the aforementioned PureScript, or js_of_ocaml, ReScript, derw, Idris, GHC.js/whatever the new GHC compiler JS output is, or similar option. These languages will have the idioms of fp-ts without the heavy reliance on singularly library most of the TypeScript community doesn’t understand that bloats their code bases without requiring the safety (someone can just call .value on a Maybe/Option breaking the safety). (This is not a knock against fp-ts which is a marvel in & of itself, but the audience doesn’t line up with the idioms of the average TypeScript project).