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

On Jan 10, 2009, at 4:11 PM, Donn Cave wrote:

Quoth "John A. De Goes" :

| 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