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 <[EMAIL PROTECTED]> wrote: > On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[EMAIL PROTECTED]> wrote: >> consalus: >>> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
