Quoth Tomasz Zielonka :
...
| What I fear about the future of Haskell, is that we will have so many
| libraries FFIying to C, that our programs will crash as often as
| programs written in C.
|
| FFI is necessary, but IMO it shouldn't be used when it doesn't have
| to be.
I spent some time recently trying to make a trivial text analysis
run fast enough to use it on large data sets. I eventually achieved
a satisfactory result - twice as fast as simple awk and Python versions.
Of course I used the FPS packed string library functions, and I spent
a lot of time profiling. One thing I found that way, is that FPS.words
iterates over the string byte by byte, in Haskell, but there's a function
(breakSpace?) that calls C to find the next space - and it's a lot faster.
On the other extreme, I have found it surprisingly painless to call
OpenLDAP functions from Haskell, which means I don't have to write my
own LDAP protocol in Haskell, but also SASL, SSL, GSSAPI and Kerberos.
The effort to do that would be enormous and eventually misguided, not
a good thing for Haskell programmers in any way.
So -- well, I actually agree with you in principle, but I'm just thinking
it depends a lot on when we decide we `have to' use FFI, and in the end
the advantages will very often be too compelling. Even for basic data
manipulation without Haskell overhead, like FPS.
Donn Cave, donn@drizzle.com
