On Jan 10, 2009, at 4:11 PM, Donn Cave wrote:
Quoth "John A. De Goes" <[email protected]>:
| 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.
Python has pure interfaces to all the major databases. While it's true
there are no "native" GUI libraries, there are pure Python libraries
for just about everything else. Haskell is not yet to this point.
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.)
I don't think it's a bold assertion. If I'm using a Haskell library
that wraps a C library, and find a bug in it, my chances of tracking
down the bug in C code and submitting a patch to whatever group
maintains it are exactly zero. On the other hand, if it's a pure
Haskell library, I'll at least take a look. What would you do?
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.)
Safe, composable IO needs to be pushed into the core (ideally, into
the standard). And it needs to be powerful enough to handle the
different use cases: text parsing, binary data, random IO, and
interactive IO. The currently exposed semantics are neither safe nor
composable.
Regards,
John
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
