[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