It will take me time to get to trying to understand how they work. But another alternate computing model that I found very interesting was Flow-Based Programming. Toontalk's model sounds somewhat similar, though with more complex interactions available.
I once dabbled in a bit of Flow-based programming to develop a visual 'pipe' program in Java, to the point where the basics worked including plug-ins, visual editing, etc. However, I believe others have superceded my work with actual released projects :-)
But I'm curiously interested in developing something similar in perl with some sort of GUI. The back-end really isn't that hard, and with typelessness of perl, data transfer's a lot easier to handle. The fun, of course, comes when it's time to set up all the intra-process pipes and threads. Ugh. :-)
But to come down to the point, there's several different ways to think of flow-based programming. The one that seems to be most popular is that as used with Macromedia's products, where you have a flow-chart, and user-interactions determine which way you go down it. In this case, this is much less like flow-based programming than procedural programming with events. On the other hand, something where data flow is unaided by the user save to initiate it, whether part of a gui or not, is more interesting to think about.
There's also Max
from Opcode Systems. I've played with it (a visual programming
tool that lets you do anything with midi and serial cables),
a friend was able to turn seismographic live from California
into body-shaking sonics at a Tokyo art museum. The interface
(which animates as it runs, and can be pulled and tweaked on
the fly) is very good for technical artists.