Hypothetical Haskell job in New York

classic Classic list List threaded Threaded
80 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

John Goerzen-3
John A. De Goes wrote:

>
> Hi Austin,
>
> How do you know it's not your experience with FFI code that isn't
> biased? As far as I know, there has been no systematic attempt to
> document whether pure Haskell or FFI-based libraries are better designed
> and better maintained. Which means your statements come from your
> experience, and my statements come from my experience, and the truth is
> probably somewhere in between.
>
> In my experience, FFI code is often based on bulk translation of C
> header files into the IO monad. It requires an exact version of a
> library to work (usually much older than the current), it does not
> compile out of the box, there's scant documentation, and very little
> high-level design has been imposed on the low-level C interface (may as
> well use C!). Exceptions to this rule, there are, but as I said before,
> my experience leads me to believe they *are* exceptions to a *general* rule.

Which libraries are you talking about?  I haven't ever used *any* like
that, as far as I know.

Current libraries almost always do build right out of the box with
standard cabal commands.

Maybe part of what you state was accurate a few years ago, but right now?

As far as selection bias is concerned, that would apply equally well to
both of us, would it not?

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Low-level networking [Haskell not ready for Foo]

Jeff Zaroyko
In reply to this post by Andrew Coppin
On Sat, Jan 10, 2009 at 5:20 AM, Andrew Coppin
<[hidden email]> wrote:

> Dominic Steinitz wrote:
>>
>> John Goerzen <jgoerzen <at> complete.org> writes:
>>
>>>>
>>>> Any idea how I get Haskell to send ICMP ECHO packets? (And, obviously,
>>>> receive the replies.)
>>>>
>>>
>>> SocketType claims to support Raw, which I think is the conventional
>>> means for doing this.  Whether all the infrastructure for that is there,
>>> I don't know.  I have never worked with raw sockets though, so I may be
>>> leading you down a dark mugger-laden alley here
>>
>> Here's an example of a Haskell version of ping, now sadly bit-rotted.
>>
>> Dominic.
>>
>> http://haskell.org/networktools/src/ping/test.hs
>>
>
> I have a worrying feeling this might be too Unix-specific to work on
> Windows. But I guess it's a start...
>

If you want to "ping" on windows, you need to use IcmpCreateFile,
IcmpSendEcho, IcmpCloseFile for IPv4 or for IPv6, use the
Icmp6CreateFile, Icmp6SendEcho2, and Icmp6ParseReplies which are part
of iphlpapi, should be fairly trivial to use the loadLibrary and
getProcAddress functions from System.Win32.DLL  module to access
these.

-Jeff
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Tim Newsham
In reply to this post by Bardur Arantsson-2
> Don't get me wrong -- the socket support is pretty decent, but there are also
> some weird idiosyncrasies, for example requiring that the PortNum is
> specified in network byte order and lacking a function to convert
> host->network byte order (hton).

PortNum is indeed strange, but it does allow yo to specify the
value in your local endian without swapping:

    > print (toEnum 0x0102 :: PortNumber)
    258

what is misleading you is that the obvious construction doesn't:

    > print (PortNum 0x0102)
    513

I'm suprised htonl comes up so often.  You can unmarshall data directly
from a byte stream to an Int type without caring about the underlying
representation of your Int.  Why do people want the htonl function?

> Bardur Arantsson

Tim Newsham
http://www.thenewsh.com/~newsham/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Brandon S Allbery KF8NH
On 2009 Jan 9, at 20:51, Tim Newsham wrote:
> I'm suprised htonl comes up so often.  You can unmarshall data  
> directly from a byte stream to an Int type without caring about the  
> underlying representation of your Int.  Why do people want the htonl  
> function?


IP address math.  (see @ipcalc in #lopsa's lambdabot)

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John A. De Goes
In reply to this post by John Goerzen-3

Hi John,

Take two examples I gave up getting to work: a Haskell wrapper for a popular GUI library; and a Haskell wrapper for a database. I understand the former has a new team of developers, so perhaps it's time to revisit the library. Then again, writing 5000 line GUIs in an imperative style in a Haskell program just doesn't seem very appealing to me. And that's one of the problem with FFI-based libraries: it exposes the functionality (when it works), but in a strictly imperative way.

Selection bias applies to us both. To quote myself, "Which means your statements come from your experience, and my statements come from my experience, and the truth is probably somewhere in between."

Regards,

John

On Jan 9, 2009, at 1:42 PM, John Goerzen wrote:

John A. De Goes wrote:

Hi Austin,

How do you know it's not your experience with FFI code that isn't
biased? As far as I know, there has been no systematic attempt to
document whether pure Haskell or FFI-based libraries are better designed
and better maintained. Which means your statements come from your
experience, and my statements come from my experience, and the truth is
probably somewhere in between.

In my experience, FFI code is often based on bulk translation of C
header files into the IO monad. It requires an exact version of a
library to work (usually much older than the current), it does not
compile out of the box, there's scant documentation, and very little
high-level design has been imposed on the low-level C interface (may as
well use C!). Exceptions to this rule, there are, but as I said before,
my experience leads me to believe they *are* exceptions to a *general* rule.

Which libraries are you talking about?  I haven't ever used *any* like
that, as far as I know.

Current libraries almost always do build right out of the box with
standard cabal commands.

Maybe part of what you state was accurate a few years ago, but right now?

As far as selection bias is concerned, that would apply equally well to
both of us, would it not?

-- John


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John A. De Goes
In reply to this post by Creighton Hogg-4
On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:

> 2009/1/9 John A. De Goes <[hidden email]>:
>>
>> If you're looking for a project to take on, I would suggest  
>> starting with
>> the following:
>>
>> A high-level, type-safe AMQP client written in 100% Haskell, which  
>> provides
>> a clean way of handling hundreds of unique message types.
>>
>> Then it would be possible to hook it up to any AMQP broker (most  
>> likely
>> RabbitMQ). There are logical steps beyond the above (an embedded  
>> Haskell
>> broker), but the above project is far from trivial. And the main
>> undertaking, I think, consists not in coding to the spec (for which  
>> there is
>> some help; a JSON representation of the AMQP specification can be  
>> processed
>> and used to emit language-specific code), but in finding a design  
>> that works
>> well in Haskell.
> <snip & reorder>
> I apologize, but my question was geared more towards understanding
> what high-level OTP-like libraries Haskell is lacking, not full blown
> applications that haven't been written in Haskell.  It sounded like
> you had some specific insight into this.


A Haskell AMQP client is not an application, but a library that  
Haskell applications would use (if it existed). The use of the word  
"client" refers to the client/server metaphor used in centralized  
message broker systems like AMQP.

Regarding the OTP specifically, Haskell doesn't have anything like it.  
Haskell has bits and pieces, but they're not integrated in a single  
stack, and much functionality is missing. For example, there's no way  
to dynamically poke running Haskell code, to see what it's doing; no  
way to update code on the fly as a process is running; no scalable  
distributed database system; etc.

Regards,

John

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John A. De Goes
In reply to this post by John Goerzen-3
On Jan 9, 2009, at 8:23 AM, John Goerzen wrote:
> Well, you pretty much always have to get down to the C level on a *nix
> platform at some point, anyhow.  You've got to make syscalls  
> somewhere.

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.

> I don't think FFI is so evil.  There is value in avoiding wheel
> reinvention, too.  If zlib already works great, why re-invent it when
> you can easily just use what's there?

There are lots of reasons:

1. If there's a bug in a library, Haskellers are more likely to fix  
the bug if the library is written in Haskell.
2. Haskellers are more likely to improve code that is written in  
Haskell.
3. A chain is only as strong as its weakest link -- libraries with  
more dependencies are more fragile, more likely to break, and less  
likely to work across platforms.
4. Haskell-only libraries are easier to build, easy to use, and easier  
to include in your program (this is subjective and we don't agree on  
this one, so ignore it if you like).
5. Haskell libraries are generally more commercial friendly than the  
GNU-licensed libraries that inevitably back FFI-based libraries.
6. Haskell libraries can more easily offer tight integration with  
Haskell code, and take advantage of features unique to Haskell, such  
as purity and laziness, and a declarative coding style.

A shining role model is the Java ecosystem. No platform has as many  
open source, commercial-friendly, robust, feature-rich, and community-
supported libraries than Java does. These libraries are, in the vast  
majority of cases, written in 100% Java, work identically on all  
platforms, are as easy to use as adding a single file to your project  
(Java also has Maven, which functions similarly to Cabal).

That's where I'd like Haskell to be in 5 years.

Regards,

John


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John Goerzen-3
In reply to this post by John A. De Goes
John A. De Goes wrote:
>
> Hi John,
>
> Take two examples I gave up getting to work: a Haskell wrapper for a
> popular GUI library; and a Haskell wrapper for a database. I understand

Is this database HDBC?  If so, then I would appreciate detailed
description of your problem so I can address it.  If not, do you have
the same criticism of HDBC?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John A. De Goes

No, it's not HDBC -- which I have not yet tried. I'll tell you what:  
I'll give HDBC a try this week and let you know if it's as easy as you  
say it is. :-)

Regards,

John

On Jan 10, 2009, at 10:09 AM, John Goerzen wrote:

> John A. De Goes wrote:
>>
>> Hi John,
>>
>> Take two examples I gave up getting to work: a Haskell wrapper for a
>> popular GUI library; and a Haskell wrapper for a database. I  
>> understand
>
> Is this database HDBC?  If so, then I would appreciate detailed
> description of your problem so I can address it.  If not, do you have
> the same criticism of HDBC?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2
In reply to this post by John A. De Goes
john:

> On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:
> >2009/1/9 John A. De Goes <[hidden email]>:
> >>
> >>If you're looking for a project to take on, I would suggest  
> >>starting with
> >>the following:
> >>
> >>A high-level, type-safe AMQP client written in 100% Haskell, which  
> >>provides
> >>a clean way of handling hundreds of unique message types.
> >>
> >>Then it would be possible to hook it up to any AMQP broker (most  
> >>likely
> >>RabbitMQ). There are logical steps beyond the above (an embedded  
> >>Haskell
> >>broker), but the above project is far from trivial. And the main
> >>undertaking, I think, consists not in coding to the spec (for which  
> >>there is
> >>some help; a JSON representation of the AMQP specification can be  
> >>processed
> >>and used to emit language-specific code), but in finding a design  
> >>that works
> >>well in Haskell.
> ><snip & reorder>
> >I apologize, but my question was geared more towards understanding
> >what high-level OTP-like libraries Haskell is lacking, not full blown
> >applications that haven't been written in Haskell.  It sounded like
> >you had some specific insight into this.
>
>
> A Haskell AMQP client is not an application, but a library that  
> Haskell applications would use (if it existed). The use of the word  
> "client" refers to the client/server metaphor used in centralized  
> message broker systems like AMQP.
>
> Regarding the OTP specifically, Haskell doesn't have anything like it.  
> Haskell has bits and pieces, but they're not integrated in a single  
> stack, and much functionality is missing. For example, there's no way  
> to dynamically poke running Haskell code, to see what it's doing; no  
> way to update code on the fly as a process is running; no scalable  
> distributed database system; etc.

There are at least two ways to do dynamic code update, via compiled
code, and via bytecode.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Donn Cave-4
In reply to this post by John A. De Goes
Quoth "John A. De Goes" <[hidden email]>:

| 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]>:
>
> | 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John Goerzen-3
On Thu, Jan 15, 2009 at 09:17:55AM -0700, John A. De Goes wrote:

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

By "pure" do you mean "containing python code only"?  I'm looking
through a few, and:

PostgreSQL - psycopg - C
PostgreSQL - pgsql - C
PostgreSQL - pygresql - C
MySQL - mysqldb - C
MS SQL Server - pymssql - C

And any interface that uses ODBC will, by necessity, be calling to C,
because ODBC is defined as a C API and not a network protocol.

Where are all these pure-Python drivers?

> 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

Why?

> least take a look. What would you do?

You have to balance that against the chances of there being bugs in
code that is used by far fewer people.  I don't care what language
you're talking about -- I'm going to expect the C PostgreSQL library
to be less buggy than a pure reimplementation in any other language,
and will have less concern about its maintenance and stability in the
future.

It's a lot of wheel reinvention to try to re-implement a database
protocol in n languages instead of do it in 1 and bind to it
everywhere else.

AFAIK, the only language where that sort of wheel reinvention is
popular is Java.  But then Java seems to encourage wheel reinvention
anyhow ;-)

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John A. De Goes

On Jan 15, 2009, at 9:31 AM, John Goerzen wrote:
> By "pure" do you mean "containing python code only"?  I'm looking
> through a few, and:

Search for "pure python mysql" or "pure python postgresql" and you'll  
see at least two implementations. In addition, there are plenty of  
pure Python databases for those who want and are able to stay strictly  
within Python.

>> 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
>
> Why?

I'm tired of C. I'm not going to use any unpaid time writing or  
maintaining anything written in C.

I assume if C were my favorite language, I'd be hanging around c-cafe  
instead of haskell-cafe. :-)

> You have to balance that against the chances of there being bugs in
> code that is used by far fewer people.

That's true.

> It's a lot of wheel reinvention to try to re-implement a database
> protocol in n languages instead of do it in 1 and bind to it
> everywhere else.

Why is wheel reinvention a bad thing? A combination of cooperation and  
competition is best for every endeavor. We have lots of companies in  
the business of making tires, each trying to outdo the other, but for  
any given company, they are all united behind the goal of producing  
the best possible tire. The consumers benefit.

> AFAIK, the only language where that sort of wheel reinvention is
> popular is Java.  But then Java seems to encourage wheel reinvention
> anyhow ;-)

The Java reinventions look and feel like Java, because they're native  
implementations. This is even more important in Haskell where the  
differences between Haskell and C is about as large as you can get.

Regards,

John


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Robert Greayer
In reply to this post by Achim Schneider




----- Original Message ----
From: John A. De Goes <[hidden email]>
On Jan 15, 2009, at 9:31 AM, John Goerzen wrote:
>> AFAIK, the only language where that sort of wheel reinvention is
>> popular is Java.  But then Java seems to encourage wheel reinvention
>> anyhow ;-)

> The Java reinventions look and feel like Java, because they're native implementations.
> This is even more important in Haskell where the differences between
> Haskell and C is about as large as you can get.

The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.).  Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program.  


     
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

David Leimbach


On Thu, Jan 15, 2009 at 10:11 AM, Robert Greayer <[hidden email]> wrote:




----- Original Message ----
From: John A. De Goes <[hidden email]>
On Jan 15, 2009, at 9:31 AM, John Goerzen wrote:
>> AFAIK, the only language where that sort of wheel reinvention is
>> popular is Java.  But then Java seems to encourage wheel reinvention
>> anyhow ;-)

> The Java reinventions look and feel like Java, because they're native implementations.
> This is even more important in Haskell where the differences between
> Haskell and C is about as large as you can get.

The Java reinventions largely exist because of the huge deployment-time benefits you get from pure-Java code (cross-platform portability of compiled (byte) code, dynamic loading of compiled code over a network, etc.).  Such reinventions are much less important for Haskell, since the typical deployment model for a Haskell program is much closer to that of a C program than a Java program or even a Python program.

I think deployment of Haskell is even easier than that of python, in that you don't have to have all the developer packages installed on target machines to have other's benefit from their use in your binary.... at least with GHC that is.

I've often been quite happily surprised what can be done with little in terms of runtime dependencies with Haskell.

Dave
 



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Manlio Perillo-3
In reply to this post by John Goerzen-3
John Goerzen ha scritto:

>> 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.
>
> By "pure" do you mean "containing python code only"?  I'm looking
> through a few, and:
>
> PostgreSQL - psycopg - C
> PostgreSQL - pgsql - C
> PostgreSQL - pygresql - C
> MySQL - mysqldb - C
> MS SQL Server - pymssql - C
>
> And any interface that uses ODBC will, by necessity, be calling to C,
> because ODBC is defined as a C API and not a network protocol.
>
> Where are all these pure-Python drivers?
>

Time ago, I implemented a client for the network protocol used by
PostgreSQL:
http://hg.mperillo.ath.cx/twisted/pglib/

it covers almost all the protocol features (only extended queries are
not supported).

It is implemented using Twisted.
I would like to reimplement it in Haskell, sometime in the future.


I tried to implement the MySQL network protocol, too, but it is a
*mess*, so I gave up (and, at that time, there were strange claims about
copyright).

It is also possible to support MSSQL and Sybase, implementing a client
for the TDS (Tabular Data Stream) protocol.

TDS, too, is a mess (well, if you compare it with the PostgreSQL
protocol), and last time I studied it, the freeTDS project only had a
reversed engineered protocol documentation; now Microsoft has made the
TDS variant used my MSSQL public:
http://msdn.microsoft.com/en-us/library/cc448435.aspx


So, in theory, it should not really be a problem to implement native and
robust support for PostgreSQL, MySQL, MSSQL and Sybase.


One benefit of these implementation would be builtin support to
concurrency [1].
For PostgreSQL, a native implementation can be useful to listen notifies.


 > [...]

[1] the libpq API *has* support for async API, but it is not
     complete (and well tested like sync API, IMHO).
     As an example there is no support for async function call, although

     "The Function Call sub-protocol is a legacy feature that is
probably best avoided in new code. Similar results can be accomplished
by setting up a prepared statement that does SELECT function($1, ...).
The Function Call cycle can then be replaced with Bind/Execute."


P.S.: the PostgreSQL protocol is really well designed



Regards  Manlio Perillo
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Donn Cave-4
In reply to this post by Robert Greayer
Quoth Robert Greayer <[hidden email]>:

> The Java reinventions largely exist because of the huge deployment-time
> benefits you get from pure-Java code (cross-platform portability of
> compiled (byte) code, dynamic loading of compiled code over a network,
> etc.).  Such reinventions are much less important for Haskell, since
> the typical deployment model for a Haskell program is much closer to
> that of a C program than a Java program or even a Python program.  

To me this argument can cut both ways.  To come back to the LDAP example,
Perl gets exactly this benefit from its natural implementation, compared
to Python's interface to C OpenLDAP - you don't have to install OpenLDAP,
eliminating a big nuisance for an interface that might have only a trivial
role in your application.  Perl is more portable in this particular respect,
because it can do LDAP on its own.

In general, I think it may be absurd to make general statements on this.
(Though I imagine one generally valid comparison we can make between Java
and Haskell libraries, is that Java's development was better funded.)

        Donn
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John Goerzen-3
Donn Cave wrote:

> Quoth Robert Greayer <[hidden email]>:
>
>> The Java reinventions largely exist because of the huge deployment-time
>> benefits you get from pure-Java code (cross-platform portability of
>> compiled (byte) code, dynamic loading of compiled code over a network,
>> etc.).  Such reinventions are much less important for Haskell, since
>> the typical deployment model for a Haskell program is much closer to
>> that of a C program than a Java program or even a Python program.  
>
> To me this argument can cut both ways.  To come back to the LDAP example,
> Perl gets exactly this benefit from its natural implementation, compared
> to Python's interface to C OpenLDAP - you don't have to install OpenLDAP,
> eliminating a big nuisance for an interface that might have only a trivial
> role in your application.  Perl is more portable in this particular respect,
> because it can do LDAP on its own.

This cuts both (and many) ways.

Someone else touched on how Haskell binaries are easier to deploy than
Python programs because you don't have to have Python and a runtime set
of things on all your machines.  That is true.

It is also true that Python programs are easier to install than Haskell
ones because I can just apt-get install python-whateverIneed on every
machine they'll run on, and don't have to worry about compiling them for
that architecture.  Moreover, I don't have to recompile them when a
security bug is found in one of the libraries I use; I just upgrade the
library, something that my OS might do for me automatically.

Haskell is currently in somewhat of an unfortunate static linking stage.
Dynamically-loaded libraries are pretty much the norm in C, as well as
in many other languages.  But if, say, the ByteString module has a
security hole, I can't just upgrade it on a target box; I have to
recompile all programs that use it, on all platforms.

I have the luxury of not having to work with proprietary dinosaur
systems.  My package manager will just handle the LDAP stuff for me,
whether it's Perl, Python, or Haskell.  But to say that the Perl
approach is better, or even more portable, I think misses the mark.
Does it have the same level of stability and reliability as the C
version?  Is it as compatible with other servers?  As full-featured?
Does it get new features added as fast?

The answers to all of these may be "yes"; I don't know.  There are
legitimate reasons for reimplementing things in other languages.

But to return to the very beginning of the thread -- I do not see the
simple fact that some Haskell modules have bindings to C underneath the
covers as either a plus or a minus to those modules.  Haskell code can
be written well, or poorly, as can C code.  Not using C is no guarantee
of quality, and neither is using C.  A well-designed FFI binding to a
quality C library can turn out very nicely, as can pure Haskell code.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Don Stewart-2
In reply to this post by John A. De Goes
john:

>
> On Jan 15, 2009, at 9:31 AM, John Goerzen wrote:
> >By "pure" do you mean "containing python code only"?  I'm looking
> >through a few, and:
>
> Search for "pure python mysql" or "pure python postgresql" and you'll  
> see at least two implementations. In addition, there are plenty of  
> pure Python databases for those who want and are able to stay strictly  
> within Python.
>

FWIW, there are pure Haskell storage APIs. See e.g. HAppS-State and TCache.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1234