Comment by somehnacct3757 | Hacker News Reader

Comment by somehnacct3757 | Hacker News Reader

Parent Full thread

I mostly agree but every tool has its purpose. Currying is indispensable in some composability workflows.

Consider advanced component creation in virtual dom frameworks. Components may want to yield some render responsibilities to the end-user while not exposing their inner api. They can use currying here to hide details from the end-user while providing their own public api.

I've also seen it be useful when you have sub components editing different parts of a model. You write one generic prop-assigner setModelProp(prop, val) alongside the model in the scope that owns the model. Then you give each subcomponent a curried setter with the prop locked in. Those sub-components don't have the ability to edit the model any other way now, and you haven't written a ton of boilerplate setters.

> every tool has its purpose.

That's really not true. The Y combinator is not generally useful for instance, because every modern language supports recursion.

> Currying is indispensable in some composability workflows.

It's not.

> Then you give each subcomponent a curried setter with the prop locked in.

That's partial application, not currying.

There are convenience use cases for libraries providing curried versions of some functions e.g. you might want to provide both `setModelProp(prop, val)` and `setModelProp(prop)(val)`. But that's because you expect significant use cases fo partially applied versions of the utility functions. Currying is not necessary for this, it just makes things more convenient for users.

I see, I had these two concepts conflated. I guess the difference is currying returns a function and partial application invokes the function.

In that case I don't know any indispensible situations for currying.

> The Y combinator is not generally useful for instance

I wish I had been told that before trying to understand and actually use it. I once wrote a JS benchmark based on Rosetta code to compute Fibonacci numbers. Not only is the Y combinator code convoluted and quite hard to understand, it's also between 1e5...2e5 times slower than a plain iterative implementation.

Somehow I find it ironic to post such a result here.

Reply on news.ycombinator.com