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

[Don Stewart]

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