4 ms·
Haskell: The Confusing Parts
- neonscribe 17y agoThis page immediately crashes Firefox 3.5.3 on Snow Leopard!
- petercooper 17y agoDitto. 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?
- mncaudill 17y agoChecks out fine with 3.5.3 on WinXP, but I'd point the finger at that poorly-formatted HTML.
- mattyb 17y agoAlso works fine with 3.5.3 on Ubuntu 9.04.
- PoisonInkwell 17y agoThe 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.
- telemachos 17y agoUsing Pandoc like a good Haskell user, eh?
- petercooper 17y agoReally? That's weird. I've used Hoefler Text in mockups before (though ultimately decided against it). Useful to know though!
- joevandyk 17y agoSame here. Pretty big bug. Had to load up Safari. Someone report the bug, I'm too lazy.
- jbalogh 17y agoReported at https://bugzilla.mozilla.org/show_bug.cgi?id=520569 https://bugzilla.mozilla.org/show_bug.cgi?id=520569
- enum 17y agoMisses laziness, which is arguably the most confusing part.
- joevandyk 17y agonot sure why this is here, it's not really worth reading yet.
- steveklabnik 17y agoAs 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 17y agoAlso does not tackle monads.
- maxtilford 17y agoI 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 17y agoI 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 17y agoIf 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 http://metafoo.co.uk/practical-monads.txt The two sections "Binding lines together" and "Lines that don't return values" explain it nicely.
- PoisonInkwell 17y agoDeliberately. Please note the links to two existing (and very good) monad tutorials... The last thing the Haskell community needs is another lackluster one.
- johnwatson11218 17y agoI had one semester of Haskell in school and thought I knew a thing or two about it. The last thing I attempted in Haskell was the game of blackjack. The two big problems there were user input, and the random numbers that were used to shuffle the deck of cards. Very quickly I had to combine two monads in my code to get anything going and I found it very confusing. It seemed like my entire program had become tainted with the non functional aspects. The tutorials didn't really clear things up either, I'm trying Scala now and that at least seems like it will let me pull in the functional pieces where I can use them.
- diiq 17y agoThe 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-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad..., though, and I am finding that very enlightening.
- jimbokun 17y ago"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.
- tel 17y agoI 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.
- shrughes 17y agoI 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.
- jriddycuz 17y agoI 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.