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
On Jan 10, 2009, at 4:11 PM, Donn Cave wrote:
Quoth John A. De Goes j...@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%.
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
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
- Original Message
From: John A. De Goes j...@n-brain.net
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
On Thu, Jan 15, 2009 at 10:11 AM, Robert Greayer robgrea...@yahoo.comwrote:
- Original Message
From: John A. De Goes j...@n-brain.net
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
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
Donn Cave wrote:
Quoth Robert Greayer robgrea...@yahoo.com:
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
Quoth Robert Greayer robgrea...@yahoo.com:
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
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
On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:
2009/1/9 John A. De Goes j...@n-brain.net:
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
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
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
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
john:
On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:
2009/1/9 John A. De Goes j...@n-brain.net:
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
Quoth John A. De Goes j...@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
Bryan O'Sullivan ha scritto:
On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo manlio_peri...@libero.it
mailto:manlio_peri...@libero.it wrote:
Another example is the multipart parser:
-- | Read a multi-part message from a 'Handle'.
-- Fails on parse errors.
hGetMultipartBody
On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
The number of applications requiring the implementation of a custom
web
server is an insignificant fraction of the number of applications
requiring a messaging system. I don't think anyone would dispute
Haskell's ability to do
You must be referring to erlang-0.1, an alpha release of a package
that impersonates an Erlang node.
Which is surely useful to someone, somewhere, but is not useful to
write a messaging application.
Regards,
John
On Jan 8, 2009, at 4:17 PM, Bryan O'Sullivan wrote:
On Thu, Jan 8, 2009
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
On Jan 8, 2009, at 4:34 PM, Bryan O'Sullivan wrote:
I actually think that we're very close to being in fantastic shape
here.
I think that's Haskell zeal speaking. :-)
Not that I don't appreciate your zeal (I do), and I'm definitely
excited about the stuff you're working on, but we're a
John A. De Goes wrote:
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
Examples?
I maintain a couple of FFI libraries, and strive to have
John A. De Goes said:
If you're looking for a project to take on, I would suggest starting with
[AMQP]
See:
http://www.reddit.com/r/haskell_proposals/comments/7ihpt/amqp_client/
This isn't a new proposal, not to imply you thought so. If you have a
need for such a library please start working
2009/1/9 John A. De Goes j...@n-brain.net:
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
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
Manlio Perillo manlio_peri...@libero.it wrote:
Unfortunately Haskell is not yet ready for this task.
Could you -- or someone else -- please elaborate on this?
I've heard it once in the context of a webbrowser, the reason given was
that ghc doesn't deallocate memory, that is, the gc heap only
Achim Schneider ha scritto:
Manlio Perillo manlio_peri...@libero.it wrote:
Unfortunately Haskell is not yet ready for this task.
Could you -- or someone else -- please elaborate on this?
Here is a list of things that I would like to see in GHC to start
developing a server application (in
Haskell's networking support is very rudimentary. Erlang's is quite
sophisticated. For network intensive applications, especially those
requiring messaging, fault-tolerance, distribution, and so forth,
there's no doubt that Erlang is a more productive choice.
Not because of the language,
On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes j...@n-brain.net wrote:
Haskell's networking support is very rudimentary. Erlang's is quite
sophisticated. For network intensive applications, especially those
requiring messaging, fault-tolerance, distribution, and so forth, there's no
doubt
Take, for example, RabbitMQ. There's nothing even remotely close in
Haskell-land.
RabbitMQ is written in 100% Erlang. It's built on Open Telecom
Platform, which again is without equal in Haskell.
There are a lot of theoretical reasons why Haskell would be a good
choice to build
Take, for example, RabbitMQ. There's nothing even remotely close in
Haskell-land.
That would be useful for systems that require an enterprise
messaging system, I agree, but I don't see how that would
be terribly important for a web server or most other networking
services I might want to
The number of applications requiring the implementation of a custom
web server is an insignificant fraction of the number of applications
requiring a messaging system. I don't think anyone would dispute
Haskell's ability to do low-level, raw networking, of the type that
few people
wchogg:
On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes j...@n-brain.net wrote:
Haskell's networking support is very rudimentary. Erlang's is quite
sophisticated. For network intensive applications, especially those
requiring messaging, fault-tolerance, distribution, and so forth, there's
There's a JavaScript binding to Java, and there's a Java binding to
Erlang, so nothing's stopping you from using JavaScript nodes in a
distributed fashion -- if you have a weird obsession with proving that
JavaScript is well-suited for every task.
But really, what's the point? FFI code
On Thu, Jan 8, 2009 at 12:06 PM, Don Stewart d...@galois.com wrote:
wchogg:
On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes j...@n-brain.net wrote:
Haskell's networking support is very rudimentary. Erlang's is quite
sophisticated. For network intensive applications, especially those
On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:
You replied to someone discussing using Haskell at a CDN to implement
things like web servers by saying that Haskell wasn't suitable for
the task.
That is incorrect. I replied to Achim's message asking for elaboration
on Haskell's
On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes j...@n-brain.net wrote:
On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:
You replied to someone discussing using Haskell at a CDN to implement
things like web servers by saying that Haskell wasn't suitable for
the task.
That is incorrect. I
On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
The number of applications requiring the implementation of a custom web
server is an insignificant fraction of the number of applications
requiring a messaging system. I don't think anyone would dispute
Haskell's ability to
On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:
You replied to someone discussing using Haskell at a CDN to implement
things like web servers by saying that Haskell wasn't suitable for
the task.
That is incorrect. I replied to Achim's message asking for elaboration on
Haskell's unsuitability.
John Goerzen ha scritto:
On Thu, Jan 08, 2009 at 10:36:32AM -0700, John A. De Goes wrote:
[...]
On the other hand, I see nothing in Haskell that would prevent its use
for any of your purposes. There are numerous high-level web
infrastructures already. Perhaps they are more or less suited to
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
Excerpts from John A. De Goes's message of Thu Jan 08 12:14:18 -0600 2009:
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.
This is a completely unfair
On Thu, Jan 8, 2009 at 10:06 AM, Don Stewart d...@galois.com wrote:
Note that there even exists an FFI binding to Erlang for Haskell, so
that Haskell nodes can seamlessly interact with other nodes speaking
Erlang's protocol format.
Actually, the erlang package doesn't use the FFI: it speaks
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
Just for
On Thu, Jan 8, 2009 at 1:07 PM, Manlio Perillo manlio_peri...@libero.itwrote:
Another example is the multipart parser:
-- | Read a multi-part message from a 'Handle'.
-- Fails on parse errors.
hGetMultipartBody :: String -- ^ Boundary
- Handle
- IO
That's great to hear Bryan. I look forward to all of your projects you just
mentioned, and work from others like you said, so one day soon we can built
really high-performance web servers in elegant Haskell code.
I also like Reactive (or FRP in general) as a declarative alternative to
message
46 matches
Mail list logo
