Haskell: The Confusing Parts

I appreciate both, honestly. Lisp achieves a great deal through purity of syntax, but that sort of thing was never Haskell's goal. Personally, I almost never think about how precedences compare; instead you learn a Haskell coding style that support the syntactic tricks allowed by operator precedence. A pretty common one goes something like this:

  forM [1..] $ \n -> do
    a <- monadicAction1 n
    b <- monadicAction2 a
    return b

Which is sort of ugly from a Lisp point of view, but I think it's a great trick enabled by having $ be an ultra-low precedence sequencing combinator. It looks like a Ruby block almost, but has zero extra syntax and very clear semantics.

I haven't noticed it being a problem in Haskell. Most of Haskell's weird operators are either uncommon enough so that everybody uses parentheses with them (such as bitwise (.|.) and (.&.) and so on), common enough that you don't forget (but (&&) and (||) are the two I always forget, and occasionally some people don't use parentheses with them), or weird and common but it's very hard to use them incorrectly without getting a compile error ((.) and ($) and (>>=) and (<$>) and (<*>) and (++) and (:) and (&&&) and so on). I don't think most of the operators in the last list would be usable without static type checking.

In particular, operators like ($) and (.) are hugely beneficial and the latter's existence is one of the main reasons people like Haskell's syntax.

Ditto. Like, immediately and hard.

I had a look at the source in Safari and there's little contentious on there. No JavaScript, Flash, or whatever. The only oddity is some horrifically formatted HTML with the end of tags coming on the next line every time - could merely that be killing FF though?

Same here. Pretty big bug. Had to load up Safari.

Someone report the bug, I'm too lazy.

Reported at https://bugzilla.mozilla.org/show_bug.cgi?id=520569

As he says in the first part, feel free to discuss what parts of Haskell are confusing to _you_, and then it can be made by the community, rather than just by him.

I don't believe tutorials are the right way to figure out monads. For one thing, they aren't as extremely important as they're made out to be, people have just latched on to the name. If you really want to understand monads you have to actually try to write code using them, and struggle through it.

Deliberately. Please note the links to two existing (and very good) monad tutorials... The last thing the Haskell community needs is another lackluster one.

Monads are nothing special. "They" somehow acquired some stigma of being "difficult", which caused people to write tutorials to help others understand them. Then the proliferation of tutorials led people to believe that they are difficult to understand, which caused people to write more tutorials. And here we are today, where people avoid a programming language because they think there is some incredibly hard concept they have to master but will never be smart enough to understand.

Anyway, the Typeclassopedia is recommended reading: http://www.haskell.org/haskellwiki/Typeclassopedia

Once you understand the relationship between functions, applicative functors, monads, and arrows, everything will make sense -- they are all the same thing.

(The next issue is, "why would I want this kind of abstraction", but that's best for you to decide on your own.)