[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
John A. De Goes
john at n-brain.net
Sat Jan 10 11:38:17 EST 2009
On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote:
> 2009/1/9 John A. De Goes <john at 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 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
More information about the Haskell-Cafe
mailing list