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

[Jefferson Heard]

Kyle, I would say that most apps don't actually require that you write
a mutation heavy inner loop.   They can be written either way, and
Haskell gives you the facility to do both. Even my field, which is
visualization can be written either way.  I write with a mutation
heavy inner loop myself, because it's how I started out, and I haven't
had any trouble with performance.  OpenGL is always my upper bound.
Even 2D code, which I've written on occasion seems not to suffer.

On Tue, Nov 11, 2008 at 5:23 PM, Kyle Consalus <consalus at gmail.com> wrote:
> 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).
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards