Why is Haskell like this?
I don't have that feeling when using other FP languages like Lisp or OCaml.
I don't have that feeling when using other FP languages like Lisp or OCaml.
You can follow them to their deep dark places - but they have travelled far, and finding them in their tunnels is a journey of many moons. To the Haskell programmer, us surface dwellers are all confused - missing the essential True Names of programming. Don’t despair - you can travel where you will; but know that discovering the hidden truths will humble and age the best of us. Why? I know not. Perhaps realising we’re small and stupid is the cost of staring into the abyss of Math.
It turns out that when you do that, all sorts of stuff that simply doesn't fly in other languages "just works", particularly around representing things using structures otherwise rarely seen outside of mathematical logic and category theory. This is all very powerful and elegant, but it means the landscape is unfamiliar, confusing, and intimidating to programmers who don't have that background or the inclination to learn about it.
Hence all the monad tutorials — not because monads are particularly special, but because beginners encounter them quickly due to IO, so they need some sort of explanation (it's like how if you teach a beginning programmer Java, there's loads of ceremony to explain around classes and public and so on just to do "hello world")... whereas you can get away with using haskell for longer without learning about, say, functors and monoids — though it somewhat misses the point of the language if you do so.
In Prolog there is another kind of revelation about inputs and outputs: There's no distinction between inputs and outputs and they aren't even necessarily ordered in time any more.
Currying is a mechanism of representing all functions with two or more arguments using functions of only one argument; with currying we can "bootstrap" functions of higher arities in a substrate like a lambda calculus that has only one argument functions.
This arrangement of implicit partial application is a syntactic sugar.
Syntactic sugar for partial application is not partial application itself. Manual partial application is just as "functional". Functions are being applied, and passed around as values.
Implicit partial application can be obtained with Lisp macros, but that can never be fully general for at least two reasons.
One is that Lisps support something very useful, namely variadic functions, and functions with optional arguments. Variadic functions mean that you don't need ugly shims like "zipwith3" in a Lisp.
However, implicit partial application also requires static typing. In order to know that f is a three argument function being called with two arguments, and therefore reduced to a partially applied one-argument function, our syntactic sugar processor needs complete arity information about f.
In a Lisp, f can be redefined at run-time from having three arguments to having four.
In principle, in spite of that, all function calls could be treated as partial applications in a very generic way, but it would be horribly, horribly inefficient --- and the diagnostics when things go wrong would be pretty terrible.
And yes currying is not the same thing but it's common in informal settings to say "Haskell has automatic currying" and everybody knows you're talking about automatic partial application.
Lisp can of course do partial application and currying but not automatically; as you say you'd have to write special macros and sacrifice variadic functions to make it work (and I have done so). And it's really not that necessary in Lisp because we have parentheses; Haskell is the only example I've yet found of a Lisp-like language that has successfully removed most of the parentheses, and it succeeded because of its implicit partial application. But it had to sacrifice variadic functions.
When I first started using Haskell I lamented not having macros, and then I realized that many of my use cases for macros in Common Lisp weren't necessary in Haskell because of its laziness.
CL is still my daily-use language. But Haskell expanded how I think about programming almost as much as Lisp did all those years ago; that happened because Haskell took the functional metaphor to an extreme. I now write better Lisp programs because of my exposure to Haskell.
Different people find different things confusing.