[zeromq-dev] ooc bindings for ØMQ
john.apps at hp.com
Fri Jun 18 09:43:27 CEST 2010
Hmm. Not sure if this has anything to do with multi-core, SOA or enterprises. Is it not more to do with the lack of courage to break new ground, try new things, leave the past behind - we have been doing it this way for 50 years, why change now?
A perhaps strange analogy is Erlang: it has been around for a long time, but only now is it beginning to take off. 0MQ has not been around for as long, but it serves a similar purpose in providing message-based computing. I highly recommend these two videos with Joe Armstrong as he makes the point much better than I:
http://mailer.infoq.com/link.php?M=6193031&N=1063&L=10064&F=H (Message passing concurrency in Erlang)
http://www.oredev.org/videos/erlang--the-language-and-its-applications (Erlang - the language and its applications)
Another, even stranger, analogy is that of Tandem and what Jim Gray wrote over 30 years ago about isolation, message passing, defensive programming, etc. It has taken that long for these ideas -whether in hardware or software or both is irrelevant- to become accepted and take off.
Many developers are stuck in their ways, universities do not seem to be teaching new thoughts, and so we continue to fight with shared data structures, threads, defensive programming, and so forth; and OO does not help much here either!
-- John.Apps at hp.com | +491718691813 | http://twitter.com/johnapps --
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Martin Sustrik
Sent: Friday, June 18, 2010 7:07
To: 0MQ development list
Subject: Re: [zeromq-dev] ooc bindings for ØMQ
Pieter Hintjens wrote:
> Yes, and it's amazing no-one already made it. The best explanation I
> can find for that is that the problems 0MQ solves (like where to do
> queueing, how to implement patterns, etc.) are really hard to solve
> properly and messaging designers invariably seem to need a broker to
> focus their thought processes. There have been p2p messaging libraries
> before but too complex (e.g. brokerless JMS). And most messaging
> products fight to add functionality, no-one ever fought to remove
Before, multicore and cloud (aka SOA) was available only in enterprise.
Enterprise in notoriously incapable of providing simple solutions.
Now that multicores and clouds are available to everyone, some kind of simple solution was bound to emerge.
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
More information about the zeromq-dev