I frankly don't like these features even in Haskell. There are a few specific places where it makes things more elegant, but in general I dislike having to think about "how do I arrange params to allow for the greatest possible use of partial application in the rest of my code?", and then the inevitable "oh I can fix that with (flip (flip flip))" or some nonsense. It's tangential to the requirements of getting my app done, and generally time / brain cells wasted. I'd rather it simply not be part of the language in the first place.

Granted most of my Haskell work is in boring line of business apps, so maybe partial application is more important in other fields.

It's one of those things where you can take a simple tool and probably make something hideously complicated with it if you go too far, but in simple cases it's useful all over the place.

For example, I very often write functions that take an initial parameter representing some sort of customisable context and then further parameters that are the right types to use with some standard higher order function like a map, filter or fold. Partial application then supplies the context and gives back something ready to pass into that HOF.

If you were to get rid of curried functions everywhere, how would change the applicative pattern.

I just find the "plain_fn <$> weird_type <*> weird_type ..." e.t.c really convenient.

I would rather chunks of functionality not be removed from tools to suit other peoples aesthetic sensibilities.

Not all features have equivalent upside (I.e. Some features have very limited upside and significant cost, in terms of maintainability etc.) When creating a codebase we should be conservative with the features we use - and this is all the article is arguing for.

I feel this way about the destructuring assignment and spread syntax in javascript, or at least a little bit.

It's incredibly convenient to use, but sometimes when I look at 'idiomatic' React code, in particular in the context of Redux, I can't help but feel it's a bit too much, especially when I look at the code through 'teacher' eyes, and especially when it's combined with JSX. And that's not even mentioning the arrow function variants, default parameters, and other ESNext goodies.

And yet I find it difficult to keep my hands off it, because it's just so damn convenient.

I believe I've heard it said: the most difficult thing when building a language is not deciding which features to add, but which features to leave out.

This is a pretty common maxim, and applies to any design exercise :)

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. "

-- Antoine de Saint-Exupery

Sometimes they have different characteristics even though they produce the same result. Such as when composing transducers, which has performance implications.