Hacker News Reader

Comment by graftak | Hacker News Reader

Currying is nice but in practice it’s rather esoteric in the JavaScript ecosystem. I’ve only seen currying being used (if at all) when transforming data with utility libraries like ramda[1]. What makes it worse it that partial application is rather cumbersome to type.

Lucky for us there is a partial application proposal, albeit still in stage 1, which makes partial application—to make functions curried—a lot easier[2].

[1] https://ramdajs.com/docs/#curry

[2] https://github.com/tc39/proposal-partial-application

View on HN

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.”

https://blog.dream11engineering.com/lessons-learned-from-run...

Wow, that is pretty awful.

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.

What’s unergonomic or unidiomatic about 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.

It also pollutes the call stack, making stepping through functions that much more laborious.

Wow. Was that just from the extra function instances and closures being created?

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.

1: https://github.com/ramda/ramda/blob/master/source/curry.js 2: https://github.com/ramda/ramda/blob/master/source/internal/_... 3: https://github.com/ramda/ramda/blob/master/source/internal/_...

I have strong doubts that partial application will ever advance from stage 1. The reason is that partial application was supposed to compliment the pipeline operator[1].

    value |> fn(?, "static string")

However earlier this month they advanced a version of the pipeline operator with a definite topic marker which makes partial application useless in the RHS of the pipeline operator. This was of course really controversial, as you can see if you read thought the most resent issues (particularly the closed ones).

https://github.com/tc39/proposal-pipeline-operator

The partial application proposal looks reasonable and intuitive. Definitely something I would use. Is there any prior art (other languages etc.)?

Mh, it's already 4 years old. What a shame.

Scala has partially applied functions that use a very similar idiom

It is used heavily in Scala https://alvinalexander.com/scala/how-to-use-partially-applie...

Clojure has the "thread-as" macro (`as->`), but I don't think it's used much: usually thread-first (`->`) and thread-last (`->>`) will more than do the job and have less mental overhead due to their regularity.

There’s a lot of bikeschedding on how to use it in conjunction with the (also stage 1 proposal and forever delayed) pipeline operator[1] unfortunately. Add in never ending arguments on which symbol we should use (the questionmark has a lot of responsibilities already) and here we are.

To make matters worse it appear that generally OOP style darlings such as static class blocks and true private fields seem to gain more momentum.

[1] https://github.com/tc39/proposal-pipeline-operator/wiki

Reply on news.ycombinator.com