[Haskell-cafe] What *not* to use Haskell for

Don Stewart dons at galois.com
Tue Nov 11 17:24:41 EST 2008


consalus:
> On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <dons at galois.com> wrote:
> > consalus:
> >> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <dukedave at gmail.com> wrote:
> >> > 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 at 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).
> >
> > Do you have an example of a mutable state/ IO bound application, like,
> > hmm, a window manager or a revision control system or a file system...?
> >
> > -- Don
> >
> 
> Of course, with a lot of skill, good design, and a pile of language
> extensions state/io-heavy Haskell code can be clean and flexible.
> Performance can be pretty good, and for complex algorithmic code
> arguably a better choice than most other languages. Still, neither of
> the projects you reference (to my knowledge) have a mutation-heavy
> inner computation loop.

Data.ByteString is full of mutation-heavy inner loops.
There's nothing magic about it.

-- Don


More information about the Haskell-Cafe mailing list