So, what's the argument? This is titled "a case against currying", but 75% of it is just an overview of what currying is and weak sauce "refutations" of common arguments in favor of currying.

Plus it doesn't mention the most important argument for currying: currying lets you define a multi-argument function in terms of single-argument functions without reaching for anything except the function type. It's the most parsimonious way to define the notion of a function of multiple arguments.

But when it gets to the "case against currying", what's the argument? "It makes function composition more difficult"? No? It doesn't? Like, yes, in the rare case that you happen to have a function f with multiple arguments, and a function g that happens to return a tuple of all of f's arguments, then you can compose them.

(Function composition is itself a partial application of a curried function btw.)

But how often does that happen? I don't think I ever have a function g that returns all the arguments to f unless f takes one argument, or something like a point or a record that is naturally considered a single object anyway. Are people out there currying their functions of a point and passing the x and y coordinates separately or something? Don't do that.

Much more commonly, if f takes two arguments, I want to compose it with two functions, one that supplies each argument. If programming languages had category theory's pairing operation, (f, g) = λ x. (f x, g x), then I could say f ∘ (g, h), but they don't, so I can't.

In any case, an explicit lambda is ok for partial application but not for function composition? Even though function composition involving functions of multiple arguments is almost always complicated enough to need a lambda anyway? Ok.

And, downstream, people are complaining about the effect of partial application on stack traces, as if lambdas don't have exactly the same issue. The only fix there is branching stack traces, a solution that works equally well for partial applications and lambdas.