Donn Cave wrote:

Quoth Robert Greayer :

...

The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.). Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program.

To me this argument can cut both ways. To come back to the LDAP example, Perl gets exactly this benefit from its natural implementation, compared to Python's interface to C OpenLDAP - you don't have to install OpenLDAP, eliminating a big nuisance for an interface that might have only a trivial role in your application. Perl is more portable in this particular respect, because it can do LDAP on its own.

This cuts both (and many) ways. Someone else touched on how Haskell binaries are easier to deploy than Python programs because you don't have to have Python and a runtime set of things on all your machines. That is true. It is also true that Python programs are easier to install than Haskell ones because I can just apt-get install python-whateverIneed on every machine they'll run on, and don't have to worry about compiling them for that architecture. Moreover, I don't have to recompile them when a security bug is found in one of the libraries I use; I just upgrade the library, something that my OS might do for me automatically. Haskell is currently in somewhat of an unfortunate static linking stage. Dynamically-loaded libraries are pretty much the norm in C, as well as in many other languages. But if, say, the ByteString module has a security hole, I can't just upgrade it on a target box; I have to recompile all programs that use it, on all platforms. I have the luxury of not having to work with proprietary dinosaur systems. My package manager will just handle the LDAP stuff for me, whether it's Perl, Python, or Haskell. But to say that the Perl approach is better, or even more portable, I think misses the mark. Does it have the same level of stability and reliability as the C version? Is it as compatible with other servers? As full-featured? Does it get new features added as fast? The answers to all of these may be "yes"; I don't know. There are legitimate reasons for reimplementing things in other languages. But to return to the very beginning of the thread -- I do not see the simple fact that some Haskell modules have bindings to C underneath the covers as either a plus or a minus to those modules. Haskell code can be written well, or poorly, as can C code. Not using C is no guarantee of quality, and neither is using C. A well-designed FFI binding to a quality C library can turn out very nicely, as can pure Haskell code. -- John