[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

[John Goerzen]

Donn Cave wrote:
> Quoth Robert Greayer <robgreayer at yahoo.com>:
> 
>> 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