[Haskell-cafe] Re: A suggestion for the next high profile Haskell project

[Donald Bruce Stewart]

> Quoting Bulat Ziganshin <bulat.ziganshin at gmail.com>:
> > Haskell can't provide fast execution speed unless very low-level
> > programming style is used (which is much harder to do in Haskell than in C,
> > see one of my last messages for example) AND jhc compiler is used

I have to dispute this Bulat's characterisation here. We can solve lots
of nice problems and have high performance *right now*. Particularly
concurrency problems, and ones involving streams of bytestrings.
No need to leave the safety of GHC either, nor resort to low level evil
code.

This obsession with mutable-variable, imperative code is unhealthy, Bulat ;)

> ajb:
> The PGP format is heavily character stream-based.  We know how horrible
> the performance of character streams are in Haskell.  On one hand, this
> would be an excellent test case.  On the other hand, performance would
> indeed suck now.

Unless you used a stream of lazy bytestrings! 
As Duncan did for his pure gzip and bzip2 bindings:

    compress, decompress :: ByteString -> ByteString 

    http://haskell.org/~duncan/zlib/docs
    http://haskell.org/~duncan/bzlib/docs

With underlying stream fusion, you keep the nice high level code. And no
imperative gunk required! I see no reason a PGP tool couldn't be
implemented similarly.

-- Don

P.S.  The comments on this thread makes me think that the state of the
art high perf programming in Haskell isn't widely known. Bulat-style 
imperative Haskell is rarely (ever?) needed in the GHC 6.6 Haskell code
I'm writing in these days. Solving large data problems is feasible
*right now* using bytestrings.

Trying to write code using an imperative style is likely to do more harm
than good, and certainly not something to suggest to beginners on the
mailing list ;)