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

[Donn Cave]

Quoth "John A. De Goes" <john at n-brain.net>:

| Take a language like Ruby or Python (or Java, or C#, etc.). The vast  
| majority of code written in these languages does not "get down to the  
| C level". When I say, "vast majority", I'm referring to > 99.999%.  
| That's because the standard libraries provide sufficiently  
| comprehensive platform-agnostic abstractions to do what most people  
| need to do. As a result, libraries for these languages are built on  
| the standard libraries, and do not require native code.

Maybe I haven't been paying enough attention, but I see Python and
Haskell in about the same position on this, especially in light of
how different they are (Haskell's FFI is a lot easier!)  Plenty of
Python software depends on C library modules and foreign code.  The
particular examples you mention - DB and UI - are great examples
where it's sort of crazy to do otherwise for just the reasons you
go on to list.

Of the cases I myself am familiar with in these languages, LDAP is
the one that seems most likely to benefit from a native implementation,
as Perl does (but not Python.)  The protocol is fairly simple, and
the common open source C implementation makes an awkward FFI and is
relatively troublesome to install and maintain.  But it also represents
a long legacy of hacks and features that allow it to interoperate as
well as it does with other implementations that supposedly also support
this same "fairly simple" protocol, a history that would be expensive
and unpleasant to repeat just for the sake of a cleaner interface.

The arguments you list in favor of native code are reasonable (though
some of them cut both ways - in particular it's a bold assertion
that bug fixes and general development are more likely in a Haskell
implementation, compared to a widely used C implementation that it
parallels.)  But each case has its own merits, and it's perilous to
generalize.  It would have been absurd for Python to take the approach
that Java takes (lacking the major corporate backing), and probably so
also for Haskell.  (Though Haskell may in the end need it for APIs
that involve I/O, the way things seem to be going in GHC.)

	Donn