[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
dons at galois.com
Sat Jan 10 13:37:40 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
> >>a clean way of handling hundreds of unique message types.
> >>Then it would be possible to hook it up to any AMQP broker (most
> >>RabbitMQ). There are logical steps beyond the above (an embedded
> >>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
> >>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.
More information about the Haskell-Cafe