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

[John A. De Goes]

On Jan 10, 2009, at 4:11 PM, Donn Cave wrote:
> 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.

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