On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley
Hi everyone
So I should clarify I'm not a troll and do "see the Haskell light". But one thing I can never answer when preaching to others is "what does Haskell not do well?"
Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;)
Cheers,
Dave
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I think some would disagree with me, but I would advise against using haskell for a task that necessarily requires a lot of mutable state and IO and for which serious performance is a big factor. I'm not talking about stuff that can be approximated by zippers and whatnot, but rather situations where IORefs abound and data has identity. Haskell can quite capably do mutable state and IO, but if your task is all mutable state and IO, I'd lean toward a language that makes it easier (OCaml, perhaps). Also, I think there are some tasks which are more easily coded using an OO approach, and while this can be done in Haskell, I tend not to think it is worth the effort. I've worked multiple projects in which big hierarchies of business objects were used, and it had to be easily to add new subclasses with minor variation and to treat any as their parent. Considered by many in FP community to be bad style, but I've never seen the equivalent implemented in any other way effectively. Haskell's record system gets in the way, as does the (as perceived by me) esotericism of existential types. Oh, also, any task that requires a good hash table. :-P Mind you, Haskell is my first choice for a leisure project and I think it is an excellent choice for quite a few tasks and still capable of what I list above, just not in my opinion the best choice.