[an_ko]

Don't be too hard on yourself. It's not stupidity but unfamiliarity. Haskell's roots are pretty distinct from most other popular programming languages, so it's normal if your existing notions from unrelated programming languages don't translate. Like if the article were written in Finnish.

[k__]

Why is Haskell like this?

I don't have that feeling when using other FP languages like Lisp or OCaml.

[josephg]

Haskell programmers have delved the deepest and furthest in the mines of a certain kind of Truth. Decades under the earth gives them strange language and strange ideas - the monoid, applicators, all sorts of things.

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.

[MaxBarraclough]

The acolytes of laziness dug too eagerly and too deep.

[gimboland]

Haskell is what happens when you take the idea of pure functions (i.e. no side effects) _really_ seriously, and try to create a programming language that works in that world (modulo mechanisms for doing the side effects you _need_ such as I/O).

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.

[dreamcompiler]

It's because Haskell is more functional than Lisp. (Can't speak to OCaml). Lisp doesn't do automatic currying; Haskell does. When you finally grok the implications of partial evaluation and laziness everywhere then you begin to understand that descriptions of the inputs and outputs of functions, while remaining ordered in time, become fully associative: You can group them however you like.

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.

[kazinator]

Firstly, I suspect you might mean partial appplication; many functional languages in that family support implicit partial application, so that if f is a three argument function, f a b c is be regarded as the partial applications ((f a) b) c).

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.

[dreamcompiler]

Agree with all your points, and I did mean partial application, not partial evaluation.

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.

[freeone3000]

Read $ as <| and . as an empty space and it parses fine as F#. This article relies more on the underlying algebraic set theory than anything in particular about Haskell (sans the conclusion, which is an implementation detail - stick to your commutative monoids in f#'s PSeq.reduce please!).

[the_af]

A lot of people complain about all the parens in Lisp. I don't agree with that complaint either.

Different people find different things confusing.