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

[Kyle 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. XMonad does all of its
mutation in a custom monad that is ReaderT StateT IO or something
similar, and it apparently works beautifully. However, my
understanding is that stack of monad transformers tend not to be
particularly efficient, and while that usually isn't an issue, the
case that I'm talking about is that where mutation
performance is a major concern.
Other languages offer similar expressive power, minus the joys of
laziness and referential transparency.
Persistent data structures are great, but if you're not using the
persistence it is less convenient and less efficient.
So again, Haskell _can_ do mutation and IO just fine, but if laziness,
purity, and immutability will be the rare exception
rather than the rule, might be easier to use a language that makes
strictness and impurity easier.
(Unless you're a Haskell guru, in which case I imagine Haskell is
always the most convenient language to use).