4 ms·

That's a fair point, currying is the main offender here, partial application is just making a new function. With the right name it's not harder to understand. I

That's a fair point, currying is the main offender here, partial application is just making a new function. With the right name it's not harder to understand. It does add complexity because you have layers of dependencies instead of everything being in the same place. The example is always some simple math, but usually functions are doing more, and when they get changed it isn't always obvious that the things that rely on partial applications of those functions are also affected. But that is true of anything that uses any dependencies, and a fundamental part of how we usually code. I prefer to reasonably minimize the number of dependencies, and then of course good tests protect you against this problem.

deleted 9y ago
[deleted]
catnaroek 9y ago
Just to be clear, I don't advocate currying everywhere. To me, the distinction between uncurried and curried functions lies primarily in the kinds of usage they suggest: (0) Uncurried functions are easier to pass as arguments to higher-order functions, because the author of the latter doesn't have to anticipate the arity of the former. (1) Curried functions are easier to partially apply. This is particularly useful for collection-traversing higher-order functions (map, filter, reduce, etc.). Furthermore, functions of three or more arguments can be “partially curried” in various ways, and the optimal choice ultimately depends on how you intend to use them. That being said, when in doubt, I tend to go for uncurried.
marcosdumay 9y ago
> The example is always some simple math, but usually functions are doing more On a language like Haskell, 90% of the time you see partial application it is something like `(+1)`, or `inClass isSpace`. That insistence on functions doing more is a very OOP thing. Functions that do too much do not compose well.
- emerongi 9y ago
  Well in Haskell it all makes sense, since you have other powerful tools (function composition and application, very large standard library of small functions, etc) that all compose into readable and nice code. If you just use currying randomly, it's going to create more headaches than solve. Ultimately you'd need to adopt something like Ramda in your project if you want to do this in your JS codebase, but even then I think Ramda-dependent code is way less readable than Haskell.

deleted 9y ago

[deleted]

catnaroek 9y ago

Just to be clear, I don't advocate currying everywhere. To me, the distinction between uncurried and curried functions lies primarily in the kinds of usage they suggest: (0) Uncurried functions are easier to pass as arguments to higher-order functions, because the author of the latter doesn't have to anticipate the arity of the former. (1) Curried functions are easier to partially apply. This is particularly useful for collection-traversing higher-order functions (map, filter, reduce, etc.). Furthermore, functions of three or more arguments can be “partially curried” in various ways, and the optimal choice ultimately depends on how you intend to use them. That being said, when in doubt, I tend to go for uncurried.

marcosdumay 9y ago

> The example is always some simple math, but usually functions are doing more On a language like Haskell, 90% of the time you see partial application it is something like `(+1)`, or `inClass isSpace`. That insistence on functions doing more is a very OOP thing. Functions that do too much do not compose well.

emerongi 9y ago
Well in Haskell it all makes sense, since you have other powerful tools (function composition and application, very large standard library of small functions, etc) that all compose into readable and nice code. If you just use currying randomly, it's going to create more headaches than solve. Ultimately you'd need to adopt something like Ramda in your project if you want to do this in your JS codebase, but even then I think Ramda-dependent code is way less readable than Haskell.