Hacker News new | comments | show | ask | jobs | submit login

Once you manged to grok the basic stuff about Typeclasses, Functors, Applicative, Monads, Monad Transformers, different notions of recursion, a minimal understanding of how lazyness can be quite tricky, the multitude of different ways of how errors and exceptions are handled in various libraries, and perhaps basic STM, Haskell has a tendency to become even more complex. If you want to do efficient IO and prevent space leaks, you have to learn about Iteratees, Enumerators and Enumeratees. If you wish to create GUIs in a bearable manner, its imperative that you learn about FRP and Arrows eventually. Then there's the innumerable amount of language extensions to Haskell of the GHC flavor, each of which comes with only scarce documentation and examples, but with a lot of theory (Fundeps, Type families, Existential types, GADTs ...). But there's more: Comonads, Kleisli Arrows and probably things I haven't even heard about. The whole point being: If you want to be able to handle 'real world stuff' in Haskell, its not enough to stay 'mostly pure' and use StateT, unfortunately. I like Haskell - I shudder when I think of C, C++ and Java - but at this point in time I find it overwhelming.



So what? I'm a computer scientist. I dig this stuff!

Take a look at this stuff in your favorite flavor of the Blub programming language. Most of the same stuff that the Haskell community calls with strange names exists in the imperative/OO world. However, in the imperative/OO world these things tend to be ad-hoc constructions ("design patterns"?) that don't have any theoretical background and are difficult to reason about.


Are most of those names for simple concepts / design patterns / types?

I'm finding more and more that the hardest part of haskell is understanding the syntax and the terminology.


A lot of stuff is quite easy, after reading http://learnyouahaskell.com/ - but there is a tendency in the Haskell community, perhaps not in the core but at the fringes to look more elite, and with a lot of hand waving to make simple things (Monads come to mind) something complex sounding.

Take the IO Monad. Everyone who wrote some web/servlet code, that needs to output stuff to the web over several classes (might not be the best design in the beginning) uses a Writer (or other class) to aggregate output. He therefore, as global vars are bad (and thread local are worse ;-) adds a Writer to every method.

public T doSomeStuff(T input, Writer io)

This is nasty and ugly, and the IO monad is in essence just another way to write this in a neat form, make it composable and control the IO environment.

public IO<T> doSomeStuff(IO<T> input)

But you would not get this insight from any of the monad tutorials written by Haskell people (except the link above). Simple monad insight comes form other people outside the Haskell community, e.g. James Iry

http://james-iry.blogspot.com/2007/09/monads-are-elephants-p...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: