3 ms·
My main objection with currying, and partial application as it's presented, is the implicit argument ordering that's imposed. I can't tell you the number of bu
by cle 9y ago
My main objection with currying, and partial application as it's presented, is the implicit argument ordering that's imposed.
I can't tell you the number of bugs I've seen that were caused by out-of-order arguments, even without currying/PA. I would never use currying like this in any non-trivial codebase, because it's very easy to make ordering mistakes, even in statically typed languages (if multiple arguments are the same type, your compiler may not protect you).
I could accept using partial application if the arguments were required to be explicitly named and/or they all had distinct types. And at that point, the OOP line blurs even more.
- pera 9y agoBut isn't that true for functions in general? types may help you mitigating some of those bugs, but the real way to solve the issue is with good documentation: docstrings and well-named parameters is the way to go.
- cle 9y agoYes it is also true for functions in general, which is why you shouldn't have functions with lots of arguments (and especially lots of arguments with the same type). Currying exacerbates the problem because the function application doesn't occur in one place--not only do you have to get the ordering right, but the order in which the function is applied is scattered across your code and depends on the control flow. It's a neat trick, but most of the time it significantly reduces the clarity and maintainability of a program.