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

Quoting Bulat Ziganshin :

...

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 ;)