
Haskell: The Confusing Parts - fogus
http://echo.rsmw.net/n00bfaq.html
======
jimbokun
"Lisp is known for hating infix notation, but Haskell embraces it. ... There
are ten levels of operator precedence (0 through 9)"

This is one of the things I prefer about Lisp. Am I the only one who still has
to stop and think occasionally about what binds more tightly with what when
reading and writing code in languages with many precedence levels? Never a
problem in a Lisp.

~~~
shrughes
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.

------
enum
Misses laziness, which is arguably the most confusing part.

------
neonscribe
This page immediately crashes Firefox 3.5.3 on Snow Leopard!

~~~
petercooper
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?

~~~
PoisonInkwell
The HTML is autogenerated by my Markdown program. Sorry it looks weird.
Anyway, the CSS (in particular, the use of the Hoefler Text font) is what
brings Gecko to its knees.

~~~
petercooper
Really? That's weird. I've used Hoefler Text in mockups before (though
ultimately decided against it). Useful to know though!

------
diiq
The article itself was perhaps a little disappointing --- it mostly discussed
syntax rather than semantics that I find confusing. It did link to
[http://blog.sigfpe.com/2006/08/you-could-have-invented-
monad...](http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-
and.html), though, and I am finding that very enlightening.

------
jriddycuz
I still find the most confusing aspect of Haskell to be that it makes me feel
like I have to think like a mathematician rather than a programmer.

------
joevandyk
not sure why this is here, it's not really worth reading yet.

~~~
steveklabnik
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.

------
adharmad
Also does not tackle monads.

~~~
maxtilford
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.

~~~
barrkel
I understand monads just fine. I would like to see a readable explanation of
the exact syntactic transformation of the 'do' notation to the actual function
that the monad is to logically return the wrapped application of.

~~~
maxtilford
If I'm reading that right, you want to see how do-notation is desugared? The
best explanation I could find was <http://metafoo.co.uk/practical-monads.txt>
The two sections "Binding lines together" and "Lines that don't return values"
explain it nicely.

