> For example, the Haskell function elem returns whether an element exists in a list. Do you call it with the list first or thing to search? There's no way to know.
Well, the type of `elem` is
(Eq a, Foldable t) => a -> t a -> Bool
Yes of course because the parameters are usually designed with currying in mind, so the order is from most general on the left to the most specific on the right. In the case of elem, both orders are reasonable, but often times only one makes sense and then it is easy to remember.
The point of my comment was more that one of the beauties of Haskell is that positional arguments are made so elegant because every positional argument is accompanied by a type. I wasn't making a statement about the order of parameters themselves, but how all parameters are typed.
> In the case of elem, both orders are reasonable, but often times only one makes sense and then it is easy to remember.
In some languages where callbacks taking positional arguments are idiomatic (like Javascript), untyped functions can cause a lot of problems by making it really hard to discern/remember what gets passed in where. In Haskell, there's often very little onus on the developer to remember anything at all; the type system will make sure they got the order right.
Obvious exceptions are non-associative functions of the type
a -> a -> a
You mean "non-commutative"
x 'elem' xs
As a former Perl guy, my opinion is that when you get people the opportunity to use ASCII to produce illegible code, you're sure to find people to do exactly that. That's one of the things that turned off Haskell (and Scala to a lesser extant).
Also, I think one crucial thing is that the strictness of usage, enforced by the compiler, can help ensure that the code is used in the right way. I would feel a lot less safe doing it with Python for example (what I use day-to-day).
Also, Haskell has unicode source files, so there's even more scope, and it can lead to some funny results: https://hackage.haskell.org/package/acme-lookofdisapproval
For example, the author complains about the obscure operators. I'd agree, some can be obscure, but the beautiful thing about Haskell is that they are not language operators, but rather just functions, that anyone can define themselves in the language! The fact that the power to do that is made available to the programmer, in a safe way, is something very few other languages manage.
The point about map, fmap and liftM (as I understand it, I might be wrong) is not entirely correct, in that they apply certain constraints to their usage. This helps to document the code, and also allows us to use precisely what we need, and no more, which leads to safer programming.
As for whitespace - no one likes to read or maintain code with inconsistent whitespace, which means whitespace is significant, regardless of whether the compiler cares or not. So I find this complaint is worth less than many people think.
Finally, the infix notation doesn't look particularly pretty, but you can also define infix functions, so in practice I'm not sure this matters too much.