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

[John A. De Goes]

My statements refer not to the FFI, but as I said, to "FFI code". FFI- 
based libraries seldom compile without excessive amounts of work,  
they're often poorly documented, and in general they seem to be  
maintained much less than pure Haskell libraries. The FFI is  
necessary, of course, but in general I view it as a bootstrapping  
process leading to pure Haskell libraries -- a crutch you have to live  
with until you can afford to pay the price of walking.

Regards,

John

On Jan 8, 2009, at 3:15 PM, John Goerzen wrote:

> On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote:
>> But really, what's the point? FFI code is fragile, often uncompilable
>> and unsupported, and doesn't observe the idioms of Haskell nor take
>> advantage of its powerful language features. Rather than coding  
>> through
>
> That is an extraordinarily cruel, and inaccurate, sweep of FFI.
>
> I've worked with C bindings to several high-level languages, and I
> must say that I like FFI the best of any I've used.  It's easy to use
> correctly, stable, and solid.  If anything, it suffers from
> under-documentation.
>
> The whole point of FFI is to bring other languages into the Haskell
> fold.  So you can, say, talk to a database using its C library and
> wind up putting the strongly-typed HaskellDB atop it.  Or you can
> write an MD5 algorithm in C and make it look like a regular Haskell
> function.
>
>> You can indeed fit a square peg in a round hole, if you pound hard
>> enough. That doesn't mean it's a good thing to do.
>
> And with that, I fully agree.
>
> -- Joh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090109/9ee30510/attachment.htm