Do you want to request a _feature_ or report a _bug_?
Feature
What is the current behavior?
https://gcanti.github.io/fp-ts/recipes/ramda: A lot of functions from ramda are missing. Some are quite popularly used: pluck, merge, prop, propEq, isNil.
For people coming from ramda-world, it seems end-developers need to re-write a lot of stuff.
What is the expected behavior?
What is the plan with these function?
- They won't be part of fp-ts? Should be in a 3rd-party fp-ts-compatible lib?
- They should be part of fp-ts? Just waiting to be worked on?
amaurymartiny
All 4 comments
I find it interesting that feedback like this crops up from time to time; it's certainly valid but also – and I speak only from my outside perspective – a tightrope to walk.
My first observation is about the boilerplate that needs to be written: this is certainly true. The thing is that other programming languages support the abstractions that fp-ts provides _at a language-level_, meaning they can reduce the boilerplate significantly. The reason you have to provide instances of, say, a Setoid to fp-ts functions is that TypeScript doesn't make this connection automatically.
My second observation is that some functionality is certainly there but hard to discover. For example prop can be achieved with monocle-ts in a – in my opinion – more powerful way, but there is _another_ learning curve to get productive with this. In that sense this is partly a failure of documentation, something I'm working on and hope to improve in the near future.
My third observation is that Ramda (and other libraries that originated in JavaScript) is less strict in many functions. I don't mean this in a bad way – it is right for these libs – but it is also something where fp-ts is trying to be much more strict to gain total functions and better polymorphism, for example (this is my unofficial understanding, at least 😅).
I know, I know, where do I want to go with my rambling?
I think there is a lot of potential in building easy to use functions/combinators like you describe on top of fp-ts. But it is unclear to me whether the current boilerplate is harmful to write or "just" difficult to understand – I don't find it as painful anymore as I did in the past (which doesn't mean it's good or bad, just that I don't notice it anymore). Which leads me to state that it might be best to start with providing something like fp-ts-ramda or contribute "ramda-like" functionality to fp-ts-contrib so we can all better understand the limits and the benefits.
Another place to start would be to add more documentation about how Ramda functionality can be achieved in fp-ts and then start from that understanding (for example all, any, etc. can be done in fp-ts but require a good understanding). What I noticed when I started to document some things was that it is much easier if there are already code snippets lying around that just need to be tied together into the docs, so such snippets would certainly help.
grossbart
on 31 Mar 2019
@amaurymartiny I documented some more functions from fp-ts that have a Ramda equivalent over here: https://github.com/gcanti/fp-ts/pull/827. There are some more that could be documented but that will require some new documentation.
Like I said before, there are some functions from Ramda that could make sense in fp-ts core and some that could be tried in a contrib repo of some kind.
grossbart
on 13 Apr 2019
But it is unclear to me whether the current boilerplate is harmful to write or "just" difficult to understand
I believe there is a clear line between harmful boilerplate and useful abstraction. pluck, prop and propEq are functions that we all use daily.
Thanks for the ramda fp-ts comparison by the way. 👌
developer239
on 20 Nov 2019
I would like to point out this project if anyone is interested in contributions (Ramda functions reimplemented in fp-ts): https://github.com/giogonzo/fp-ts-ramda
gcanti
on 21 Nov 2019
Related issues
FruitieX
·
3Comments
steida
·
4Comments
mattgrande
·
3Comments
josete89
·
3Comments
bobaaaaa
·
4Comments
Most helpful comment
I find it interesting that feedback like this crops up from time to time; it's certainly valid but also – and I speak only from my outside perspective – a tightrope to walk.
My first observation is about the boilerplate that needs to be written: this is certainly true. The thing is that other programming languages support the abstractions that
fp-tsprovides _at a language-level_, meaning they can reduce the boilerplate significantly. The reason you have to provide instances of, say, aSetoidtofp-tsfunctions is that TypeScript doesn't make this connection automatically.My second observation is that some functionality is certainly there but hard to discover. For example
propcan be achieved with monocle-ts in a – in my opinion – more powerful way, but there is _another_ learning curve to get productive with this. In that sense this is partly a failure of documentation, something I'm working on and hope to improve in the near future.My third observation is that Ramda (and other libraries that originated in JavaScript) is less strict in many functions. I don't mean this in a bad way – it is right for these libs – but it is also something where
fp-tsis trying to be much more strict to gain total functions and better polymorphism, for example (this is my unofficial understanding, at least 😅).I know, I know, where do I want to go with my rambling?
I think there is a lot of potential in building easy to use functions/combinators like you describe on top of
fp-ts. But it is unclear to me whether the current boilerplate is harmful to write or "just" difficult to understand – I don't find it as painful anymore as I did in the past (which doesn't mean it's good or bad, just that I don't notice it anymore). Which leads me to state that it might be best to start with providing something likefp-ts-ramdaor contribute "ramda-like" functionality to fp-ts-contrib so we can all better understand the limits and the benefits.Another place to start would be to add more documentation about how Ramda functionality can be achieved in
fp-tsand then start from that understanding (for exampleall,any, etc. can be done infp-tsbut require a good understanding). What I noticed when I started to document some things was that it is much easier if there are already code snippets lying around that just need to be tied together into the docs, so such snippets would certainly help.