Two related things I've been studying in more depth lately: Dataflow programming and behavior trees(the game AI concept).<p><a href="http://en.wikipedia.org/wiki/Dataflow_programming" rel="nofollow">http://en.wikipedia.org/wiki/Dataflow_programming</a><p><a href="http://www.altdevblogaday.com/2011/02/24/introduction-to-behavior-trees/" rel="nofollow">http://www.altdevblogaday.com/2011/02/24/introduction-to-beh...</a><p>The first comes up anytime you want to make a signal processing chain more modular and composable(graphics and audio are the classic applications) and many of its concepts share space with FP theory. Graph demonstrates a implementation built around certain needs of web apps. Note that it seems like implementations vary a lot with the data types - audio processing, for example, may allow for cyclical feedback loops, and mainly distinguishes between two types of data - multi-channel PCM data(which may be split and combined between nodes) and parameter changes over time.<p>The second describes a form of concurrent finite states with good compositional properties - parent-child relationships that result in concurrency expressions passed back to parents(success, failure, in progress). Coroutines are comparable in power, but put emphasis on direct control of the concurrency, while BTs use modules of state + logic with pre-designed yielding points. (I think other finite state constructs have applications, too, BTs just happen to be my focus right now)<p>I currently believe that highly-concurrent applications can be abstractly architected as a combination of dataflow, behavior trees, and asynchronous events - each one of those covers a very distinct set of concepts surrounding concurrency problems, and they present natural boundary points with each other.
When reading the background on Graph from October (<a href="http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph-at-strange-loop.html" rel="nofollow">http://blog.getprismatic.com/blog/2012/10/1/prismatics-graph...</a>), I came across this: <i>Of course, this idea is not new; for example, it is the basis of graph computation frameworks like Pregel, Dryad, and Storm, and existing libraries for system composition such as react.</i><p>I wanted to point out that the programming model behind Dryad and Storm represent computations <i>as</i> graphs, but that the programming model behind Pregel is for computations <i>on</i> graphs. It's a subtle difference in words, but an enormous difference in what you actually do.
I'm one of the authors of Graph, and I'll be here to answer questions and read comments. Please let us know what you think, and help us make plumbing and Graph better. Thanks!
Here's a cool presentation on Graph that I watched a couple of days back.<p><a href="http://www.infoq.com/presentations/Graph-Clojure-Prismatic" rel="nofollow">http://www.infoq.com/presentations/Graph-Clojure-Prismatic</a>
It doesn't take much of a stretch to see Graph integrated with something like Nathan Marz's Storm (also written in Clojure) to provide the distribution and deployment aspect. Have you guys given that any consideration?
This looks very interesting.<p>It seems to be similar to something I've been thinking about and trying to build lately, so I'm definitely going to check this out.
I think this could be used to solve similar problems for event-driven programming. For instance, in Aleph/Lamina (async clojure library), pipelines work great when only one value is returned. But if you want to wait for two remote calls to return in parallel, and feed both results into the next function, the syntax can a bit painful. Here, you could supply something like async-compile which would work similarly to parallel-compile but use pipelines and merge-results under the covers.
This initially looks like an IOC Container (StructureMap, etc) with automatic dependency resolution, except you can control the compilation of the internal graph. Is that accurate?
Brilliant! Been following Prismatic/Bradford for a while now and thought you would not share your 'Graph' library.<p>If one has not stumbled upon specific use cases like disparate data sources, custom/widely varying transformation logic between these data sources and more then it might be difficult to appreciate your contribution. Thanks for this..even if not right away I hope to utilize it for our startup!
This is quite amazing, and frankly quite an eyeopener in the way large clojure projects can be organized. Just curious though: does Graph handle cycles?