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

[Don Stewart]

john:
> 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.

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

-- Don