What if your functions would only, actually, take a single argument? Currying is a very nice feature that Haskell offers that allows cleaner code to be written and leverages composition.

Currying is the process of transforming a function that takes multiple arguments into a function that takes just a single argument and returns another function if any arguments are still needed.

Alright, so I have read this exceprt on an answer to the question on Quora: What programming language do people hate the most, and why?

Haskell is too goddamn opinionated on FP. FP is a wonderful paradigm for programming, but most FP enthusiasts champion it as a be all and end all for every task on the planet. And that simply is not true. This is most obvious in the Haskell community. I hate the community more than the language. That being said, any language that hogties me to prevent me from using basic constructs like loops and multi argument functions is not worth spending even a microsecond on.
(...)
I dont believe currying is a better way to do things. Currying is like building stuff with lego blocks. But its asymptotically more unreadable as a result of increasing complexity. f(g(x)) = y is what currying solves, but I expressely want f(x, y) = z as it reads better, makes more sense and does not hogtie me to define two separate methods when I just wanted one piece of functionality that does exactly one thing. Think about a how a curryied impl would look like if you have 50 different things that is happening to the inputs?
I use scala so i know how to curry stuff, but its way more elegant to use multi var functions when code bases implode in size. Its a restriction that is no palatable to me.
Same goes for loops. Loops map cognitively to certain tasks that recursion does not (vice versa is also true,but I find loops way more elegant for a vast majority of problems).

What I have to say

First, if a language makes you think differently about programming it already is worth spending a microsecond on it.

I dont believe currying is a better way to do things. Currying is like building stuff with lego blocks.

I disagree because I believe that complexity is better built by composing simple parts together.

Your example about “what curry solves” it’s not even a currying example but a function composition example. Consider for example the sum function:

(+) :: Num a => a -> a -> a

So by currying:

1 + 2  == (+1) 2

And this is useful because you can compose partial applications in a very clean and readable way.

About your “f(x, y) = z as it reads better”. Does it really? I don’t really see your problem here. Is it about the brackets? you can have exactly the same style in Haskell, you just don’t have the brackets.

For instance:

elem :: Eq a => a -> [a] -> Bool

you can use it like:

elem x list

If you mean that elem(x, list) reads better, that’s a just an opinion without much more to add, and with arguments against (more characters involved, more messy to look at)

So the conclusion is that currying doesn’t stop you from invoking functions like you do in Scala. It just provides something extra.

An alternative to curry (in such cases) is using anonymous lambdas. For the two functions above you can either do:

map (+1) list
--or
map (\x -> x+1) list

and

filter (elem 3) listOfLists
--or
filter (\list -> elem 3 list) listOfLists

I guess you are not really arguing that the second versions are more readable?

And comparing such thing to Java for example:

list.stream().map(x -> x +1).collect(Collectors.toList());

and

listOfLists.stream().filter(list -> list.contains(3))
   .collect(Collectors.toList());

Is it even necessary to discuss which style is cleaner, more concise and readable?

“Think about a how a curryied impl would look like if you have 50 different things that is happening to the inputs?”

Ok, again, I’m not sure if you confused currying with function composition.

I hope we both agree that functions should not have more than few arguments, so a case of 50 arguments might not be what you meant but maybe composing 50 functions instead?

Even in such hypothetical case, that would straight away be a case to better breakdown the computation into better smaller blocks, first of all. And, sorry, I just don’t see any strength in your arguments even for such case. Would it be better in an imperative style?

“but I find loops way more elegant for a vast majority of problems”. It happens that I don’t like for or while loops. Now what? Where’s your argument? Loops in general are far from being elegant. In Haskell you have map, filter, fold, etc etc that are way more elegant ways of doing these reductions applications. Still, I agree that a loop might be a good fit for some problems but why would you be so against other ways of thinking about programming?

"A language that doesn’t affect the way you think about programming, is not worth knowing." – Alan Perlis