Live data from Hacker News

The Haskell user experience

rickdzekman.com

1–10 of 50 posts

Re: The Haskell user experience

#2
My experience with learning Haskell was:

When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem.

When it's warty, it's really warty. Namespaces... oh god, namespaces. About three different rather poor ways to handle exceptions. A billion little unmemorable functions with symbolic names. Total lack of debugging tools. Trying to find where an a out-of-bounds list error was happening. Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluation happens.

Some of the warts are just embarrassing, and need fixing ASAP. Lack of information on a runtime exception is the biggest. Even BASIC would at least give me a line number!

Re: The Haskell user experience

#5
Personally I switched from learning Haskell to learning Racket and couldn't be happier. On the other side of banging my head I think Cabal is the biggest disappointment of my experience and it was the worst package management headaches for my own private builds.

Now that I am done with a book of Haskell and being a total hack at Haskell with very little skills (I did learn quite a bit of Lambda Calculus along the way) I think there is a BIG reason why Haskell has not grown in popularity in language usage and is beat by Scheme and almost beat out by ML. The experience pales to the praise and mind share in the vocal community of Haskell users.

Re: The Haskell user experience

#6
What I'd really appreciate (as one of those people who's read LYAH and is struggling to get going with real code) is a Haskell equivalent of Effective Java or Effective C++.

Re: The Haskell user experience

#8
post #6

What I'd really appreciate (as one of those people who's read LYAH and is struggling to get going with real code) is a Haskell equivalent of Effective Java or Effective C++.

Not sure if it's relevant, and unfortunately it's a bit outdated, but have you seen Real World Haskell? Also related is Beginning Haskell – A Project Based Approach.

Re: The Haskell user experience

#9

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluation happens.

This is a completely wrong assumption. The point of laziness is not so you won't have to care about evaluation order. Everyone would like to have a language in which you don't have to think about evaluation order, but that has proven to be rather hard. Not because the people who invented Haskell or implemented the compilers are idiots who don't know what they're doing, but because it a hard problem to tackle. With many pros and cons on both the lazy and the strict side.

This isn't embarrassing at all. At least you need to think less about evaluation order in Haskell than in most other languages.

Re: The Haskell user experience

#10

My experience with learning Haskell was: When it works, it's magical. Finally realising that monads allow little bubbles of cause-and-effect. STM, which is utterly magical. Realising that not having side effects is freeing, not restricting. Collapsing huge chunks of code into little bits of pattern matching. Finding myself casually using a higher-order type because it was the easiest way to solve a problem. When it's…

Personally, I've been spending a lot of my recent time trying to debug a Parsec parser (it seems to be going into loops of backtracking, but I can't figure out where and why), and it's been a clusterfuck.

* `trace` and `traceM` don't actually get evaluated, so I can't use printing to find my bugs.

* Even putting `trace "..." True` as a guard to my parser combinators doesn't seem to actually print anything.

* `seq` and `deepseq` require that I implement all kinds of instances for datatypes whose innards I can't actually access, so I can't force the evaluation.

* I'm getting tempted to use `unsafePerformIO` just to get some damn debug output, but can't figure out how to make it have the right type inside the Parsec monad.

Debugging Haskell sucks when you need to debug dynamic behavior rather than type errors.

Post reply on HN