Easier to read version:

    let logNow = (importance, message) => log(new Date(), importance, message);
    let debugNow = message => logNow("DEBUG", message);

And with this implementation, current IDEs provide a more informative auto-complete.

Wrong. Your implementation loses all parameter typing, defaulting to "any". IDEs have correct TS definitions for .bind().

That is not currying, it’s partial application.

Currying makes it implicit, but it's the same thing.

    const one = curriedSum(1)
    one(2)

is the same as

    const one = sum.bind(null, 1)
    one(2)

with the exception that the latter is explicit and not as slow as `curriedSum`.

Both `sum` and `curriedSum` can be used the same way:

    curriedSum(1)(2)
    sum.bind(null, 1)(2)

or just:

    curriedSum(1, 2)
    sum(1, 2)

One of the advantages is that non-curried functions make the return value explicit. You can't implement `sum(...addends)` with currying because curried functions have a fixed number of parameters. Once past that, a call will not return a function anymore.

    sum.bind(null, 1).bind(null, 2).bind(null, 3).bind(null, 4) // Still not called
    curriedSum(1)(2)(3)(4) // Maybe it works, maybe undefined is not a function

They're technically correct. And if you gotta write on HN, you better get the terminology correct (and that derails threads into interesting tangents often) so my bad.

Gotta say currying seems to be useless in real world. No advantage whatsoever over partial application.

Ah, TIL.

If we are being pedants. Wikipedia says:

> currying is the technique of converting a function that takes multiple arguments into a sequence of functions that each takes a *single argument*.

So the article isn't currying either. It's a hybrid between currying and partial application.

TBH I can't think of a practical case where you'd prefer currying over partial application. Theory/philosophy aside.

> So the article isn't currying either. It's a hybrid between currying and partial application.

Sure.

> TBH I can't think of a practical case where you'd prefer currying over partial application. Theory/philosophy aside.

For eager-evaluation uncurried language (like javascript) I would also struggle to think of one.

For curried languages, it can sometimes be useful to uncurry functions in order to make types match, after which you might have to curry them back into the "normal" form to use them.