Very interesting, needs more examples though. It seems like this fits a similar purpose to Nathan Marz' Storm framework. Could you do a bit of a compare/contrast thing between Graph and Storm?
Prismatic's "Graph" at Strange Loop
11–20 of 47 posts
Re: Prismatic's "Graph" at Strange Loop
#12Nit, defnk? what about def-kw-func or something? not wholly readable as defnk.
Re: Prismatic's "Graph" at Strange Loop
#13Very interesting, needs more examples though. It seems like this fits a similar purpose to Nathan Marz' Storm framework. Could you do a bit of a compare/contrast thing between Graph and Storm?
The main similarity between this and Nathan Marz's Storm framework is that they both rely on a declarative expression of the structure of the computation graph.
However, beyond that there are many key differences. Storm is a graph computation framework, which compiles your specification into a distributed real-time computation pipeline. In contrast, Graph is just a library for expressing composition structure, but says nothing about execution strategy.
In principle (with a lot more code and some more annotations), one could compile Graphs into distributed real-time topologies like Storm. For now we've been using Graph in-process for real-time processing. But because Graph is so simple and close to the language, it's very easy to apply to new situations and build new abstractions on top of. For example, we also find Graph useful for expressing the composition structure of our production services, which are built up from many components.
Re: Prismatic's "Graph" at Strange Loop
#14If I understand the nature of this system, it's essentially a higher-order function composition tool. Correct? Nit, defnk? what about def-kw-func or something? not wholly readable as defnk.
Point taken about the names, thanks for the feedback. Since Clojure already uses defn and fn, defnk and fnk seemed natural. But maybe defn-keyword and fn-keyword would be better.
Re: Prismatic's "Graph" at Strange Loop
#15Nice. Assuming that the computation of each node is memoized, can we 'dirty' a single node, so that during the next computation only the needed parts of the graph are recomputed? This would make multiple computation of models where only a few parameters are changing much more efficient. Also, has this at all been inspired by SecDB's powerful graph oriented features?
I haven't heard of SecDB, but I'll definitely check it out -- thanks!
Re: Prismatic's "Graph" at Strange Loop
#16Re: Prismatic's "Graph" at Strange Loop
#17This sounds very useful. I'm having trouble understanding the nature of the system, though, because I don't really understand lisp / clojure. Is this a pattern that could be applied in any language with first class functions, or does it require a lisp to be practical?
Sure! This particular way of expressing declarative structure may be specific to Clojure, but the basic ideas should be useful in any (especially dynamic) language with first-class functions. The first idea is to take a complex system and express the set of components and their relationships declaratively, rather than procedurally. This is an old idea, and makes it possible to reason about the system, mock out compon…
Re: Prismatic's "Graph" at Strange Loop
#18Re: Prismatic's "Graph" at Strange Loop
#19Re: Prismatic's "Graph" at Strange Loop
#20I love reading prismatic's blog. You have some really smart people there. However, it seems like you're trying to solve everything from a purist view and I think your product is suffering as a result. I have made the same suggestion consistently that would make me use it more without any reply. Basically, I've stopped using the product as the UX does not match the reason I would want to use the product.