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

john:

On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:

...

2009/1/9 John A. De Goes :

...

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.

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