When someone writes
f = foobinade a b
g = foobinadd c d
Whereas with explicit syntax, the parentheses say what the author thinks they're doing, and the compiler will yell at them if they get it wrong.
Yes, but the exact FP idea here is that this distinction is meaningless; that curried functions are "actual results". Or rather, you never have a result that isn't a function; `0` and `lambda: 0` (in Python syntax) are the same thing.
It does, of course, turn out that for many people this isn't a natural way of thinking about things.
Everyone knows that. At least everyone who would click a post titled "A case against currying." The article's author clearly knows that too.
That's not the point. The point is that this distinction is very meaningful in practice, as many functions are only meant to be used in one way. It's extremely rare that you need to (printf "%d %d" foo). The extra freedom provided by currying is useful, but it should be opt-in.
Just because two things are fundamentally equivalent, it doesn't mean it's useless to distinguish them. Mathematics is the art of giving the same name to different things; and engineering is the art of giving different names to the same thing depending on the context.
Not when a language embraces currying fully and then you find that it’s used all the fucking time.
It’s really simple as that: a language makes the currying syntax easy, and programmers use it all the time; a language disallows currying or makes the currying syntax unwieldy, and programmers avoid it.
I write stuff like `map (printf "%d %d" m) ns` all the time. I daresay I even do the map as a partial application, so double currying.
I don't think parent is saying that partial application is bad, far from it. But to a reader it is valuable information whether it's partial or full application.
In a pure language like Haskell, 0-ary functions <==> constants
let f :: Int = foobinade a b
And if you think this is verbose, well many traditional imperative languages like C have no type deduction and you will need to provide a type for every variable anyways.
What you say is true. And it works, if you're the author and are having trouble keeping it all straight. It doesn't work if the author didn't do it and you are the reader, though.
And that's the more common case, for two reasons. First, code is read more often than it's written. Second, when you're the author, you probably already have it in your head how many parameters foobinade takes when you call it, but when you're the reader, you have to go consult the definition to find out.
But if I was willing to do it, I could go through and annotate the variables like that, and have the compiler tell me everything I got wrong. It would be tedious, but I could do it.
let result =
input
|> foobinade a b
|> barbalyze c d
let f = foobinade a b >> barbalyze c d
let result = f input
let f = barbalyze(c, d, foobinade(a, b, $))
let result = f(input)
let result = barbalyze(c, d, foobinade(a, b, input))
let result = (barbalyze(c, d, $) . foobinade(a, b, $)) input
let result = input
|> foobinade(a, b, $)
|> barbalyze(c, d, $)
let result = input
|> add_prefix_and_suffix("They said '", $, "'!") let foos = foobinate(a, b, input)
let bars = barbakize(c, d, foos)
It can, or it can't; depending on the situation. Sometimes it just adds weight to the mental model (because now there's another variable in scope).