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

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 wrote:

On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart wrote:

...

consalus:

...

On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley 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@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@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