I wouldn't say a bad experience necessarily, but I ended up working from the O'Reilly book and Learn You a Haskell alternatively, working from the front and back of each book alternatively. That was because neither of them managed to explain things to me in the order I wanted to hear about them, and as my interest was in actually making something useful with Haskell I kept needing to look at the useful (later) parts of the books to get any of that.
There's lots of wiki pages. Among the links i liked the Wash Univ of St. Louis breadcrumbs and these cheats. Also the Hutton, Thompson, "school of expression" and "road to logic" books:
One thing I noticed as a Haskell noob is that the terse syntax makes it impossible to Google for solutions. Say I'm trying to understand a code snippet. I have to know what the (insert random string of punctuation) operator is called before I can proceed.
Very open ended question. The trickiest thing for me is the GHC "instance" extensions: TypeSynonymInstances, -XUndecidableInstances, Flexible, Overlapping, etc
--------------
I think there's general agreement that cabal has limitations:
Not clear if you're interested in pure language design or looking at the state of standard library, editor/testing/deployment toolchains etc but as far as language design debates go vs. the SML line, you could read Harper's
I found the Haskell operators to be particularly unenjoyable, and that's coming from someone who started to program in Perl. I don't see any logical purpose in such a large deviation from most languages even in basic things like comment operators. It felt like I was writing code in a different (spoken) language.
In short, Haskell's modernity didn't offer enough for me to consider it over Clojure.
To read code (or math) I find life easier when I can "read" it inside my head. The terse and heavy symbolic syntax make understanding code less comfortable for me.
The other thing is that currying + lack of parens around function arguments makes it not visually clear where each argument goes or what expressions are part of what. Only someone familiar with each function and it's arity (in some Haskell-relevant sense) could read the stuff at a glance.
10 comments
[ 5.8 ms ] story [ 33.9 ms ] threadhttp://blog.codeslower.com/static/CheatSheet.pdf
http://sites.google.com/site/haskell/notes
http://acm.wustl.edu/functional/hs-breads.php
http://www.cl.cam.ac.uk/~ns441/files/thips.pdf
---------------
http://www.haskell.org/tutorial/
http://haskell.org/haskellwiki/Blow_your_mind
http://www.haskell.org/haskellwiki/Meta-tutorial
http://haskell.org/haskellwiki/Category:Tutorials
http://www.haskell.org/haskellwiki/Tutorials
--------------
I think there's general agreement that cabal has limitations:
http://www.yesodweb.com/blog/2012/04/replacing-cabal
http://www.yesodweb.com/blog/2012/04/cabal-meta
http://www.reddit.com/r/haskell/comments/qdjha/which_command...
http://www.reddit.com/r/haskell/comments/r5h81/google_summer...
http://www.reddit.com/r/haskell/comments/rurn4/cabalmeta_tra...
-----------------
Not clear if you're interested in pure language design or looking at the state of standard library, editor/testing/deployment toolchains etc but as far as language design debates go vs. the SML line, you could read Harper's
http://existentialtype.wordpress.com/2011/04/24/the-real-poi...
http://existentialtype.wordpress.com/2011/05/01/of-course-ml...
In short, Haskell's modernity didn't offer enough for me to consider it over Clojure.
The other thing is that currying + lack of parens around function arguments makes it not visually clear where each argument goes or what expressions are part of what. Only someone familiar with each function and it's arity (in some Haskell-relevant sense) could read the stuff at a glance.