On 10/02/2012, at 3:02 AM, Ian Barber wrote: > > Build it! Demonstrate the power of felix :)
There are demos of SDL built with the chips and wires model. It works great, because channels decouple the components nicely: an interesting form of abstraction (distinct from functions and classes). There are two difficulties I find with this model. 1) Felix is statically typed, and the channels are objects, connecting things with them is hard work. 2) Getting the network to start is a bitch. In 0MQ, inproc and other endpoints use string names. This is easier than objects to make connections, because you can connect each socket in turn and when you have both 0MQ automagically makes the connection for you. The downside of this is that string names suck: they can be mis-spelled. Also 0MQ channels just transfer blobs, Felix ones are typed, and the typing also includes input,output or bidirectional, so they're a lot "safer". In 0MQ, startup may be easier because of the auto-connection thing. however it's sloppy, messages might be lost (depending on the socket types involved). And it can lock up because of this. The problem in 0MQ is that it is beyond the users control. Using sleeps() seems to be the best solution, but it is only a statistically likely solution. The real bottom line here is that to use the chips/wires model properly you need a DSSL (domain specific sublanguage). Most languages are too closely coupled to the subroutine model, too tied to applicative computation. Chips/wires needs a more category theoretic model: compositional, rather than applicative. With tags for endpoints (like 0MQ has) but in the language, and with declarative way to make the connections, not an executable one. The "process manager" I'm making to test 0MQ Guide examples is basically a "chips and wire" programming language in simplified form. Here we have processes using 0MQ sockets and 0MQ endpoints to link the processes. The "control language" is working with executables with endpoints rather than sockets, so its a bit higher level, but doing the same job. A kind of 0MQ shell. -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
