Note that currying, especially with Ramda, has a very large negative performance impact.
” To improve the compositionality of our code we had defined a ton of curried functions using Ramda. But every abstraction has a cost associated with it. On profiling, we found out that the `curry` function was taking up a lot of CPU. Benchmarks show that removing curry from the code makes it up to 100 times faster. Curry function is at the core of Ramda, almost every function is curried.”
I'm a pretty big fan of strong, static type systems and FP in general, and I have been writing typescript professionally for a few years now.
I decided a long time ago that trying to write Haskell in TS just isn't worth the effort.
Adopting FP ideas such as pure functions, restricting side-effects and then otherwise just using the type system to model the flow of your program goes a very long way. You don't have to write Haskell in TS to reap most of the benefits.
You can also just not use TypeScript if you want something more appropriate for functional programming styles. I know it's not always practical to switch languages, but it's equally impractical to push unergonomic, unidiomatic styles on language not built for it. There are a lot of good options to compile an FP language to JavaScript, and frankly those languages deserve more mindshare than pressing so hard on fp-ts.
As far as I understand it TS is supposed to follow as closely to JS as possible. I always saw it as “let’s add types to JS” rather than a separate language. I’m not sure I’ve seen a “this is how you write TS vs JS” formal declaration from the TS team. Am I missing something?
Say you want first-class currying and function composition. You expect this coming from any functional language and now you don't have that ability without introducing another compiler or third-party library. Do you want algebraic data types and pattern matching? You can sort of fake it, but it's certainly uglier. Do you want managed IO or immutability? Well, you can code it by convention but it's hard to enforce it and many of the libraries you consume won't be following those conventions.
In this sense, where these features are not the default and aren't first-class, will almost likely never be idiomatic because to TypeScript because there's too much friction compared to something from the ML families or the LISPs. In trying to add types to JavaScript, as a result you keep a lot of that same friction as JavaScript. I'm not saying it doesn't have a place--it's clearly super popular--but I do think it does not offer a good experience for someone looking for FP-style programming. It's really odd to see job postings with an FP team, Haskell on the back-end, and then TypeScript on the front-end... it just doesn't match, and there were other good options, even if it requires writing some libraries for these communities.
The story doesn’t tell, but looking at the Ramda source [1][2][3], it sure looks like it: each application of a curried function creates a new curried function on the fly. Didn’t check deoptigate, but I’m willing to bet V8 doesn’t optimize that well.
” To improve the compositionality of our code we had defined a ton of curried functions using Ramda. But every abstraction has a cost associated with it. On profiling, we found out that the `curry` function was taking up a lot of CPU. Benchmarks show that removing curry from the code makes it up to 100 times faster. Curry function is at the core of Ramda, almost every function is curried.”
https://blog.dream11engineering.com/lessons-learned-from-run...