Hi -- author of Prismatic's Graph here. (just released last week: https://github.com/prismatic/plumbing)
This looks like a very cool library -- thanks for the release! You're right that our fnk and defnk take keyword rather than positional arguments, and in that sense are 'idiosyncratic'. But the really nice thing about this, IMO, is that nodes and graphs are nicely parallel. Both fnks and graphs have the same keyword calling convention, and support the same metadata about input and output structure. This makes it a breeze to support hierarchical graphs, which we use extensively -- a node can be a fnk, or another graph (uncompiled), or that same graph pre-compiled to a fnk. Surface differences aside, it would be really great if we could converge on a common protocol and structure for graph/node input and output metadata, since that could allow people to write code that worked with both libraries, rather than forcing people to choose and end up with separate silos. I'd love to discuss this (and hear your comments on our implementation) here or off-list. Cheers, Jason On Saturday, February 2, 2013 9:38:03 AM UTC-8, Ben wrote: > > On Sat, Feb 2, 2013 at 12:28 AM, john <john....@gmail.com <javascript:>> > wrote: > > I would be very interested to learn which kind of practical problems > these > > engines can solve? > > Any real-world examples would help me understand the benefit of this > > approach. > > We're using it for (nearly) all of our analytics stuff now, and all > new analytics code being written; rewritten old analytics code is now > shorter, faster, and clearer. > > If you are, say, selling things, and there are some attributes you > want to compute regarding items sold (say, total price, average price, > average # of items per sale, and also all that information per type of > item sold), you can declare those fields in one place. You can then > also easily declare sets of interest, say, sales made in the last day, > last week, last month, last year; sales made where at least one of the > items was over a particular price point; sales made where where the > shipping option was X, and then perform various set operations on > them, so that when you end up computing the measures you want, you get > them not only for all the input, but you also get, at a go, the > average price of sales of items in the "electronics" category where > the sale was made in the last week and at least one item in the sale > was over a particular price point or the shipping option was not X. > Etc. > > This is admittedly a hypothetical real-world example, since we do not > sell or ship things, but it's a realer-world example than just summing > the values of :x keys in maps, which could easily be done with vanilla > reduce and map. Where this shines is when you want to get *multiple* > summary values out of your data across a variety of partitions of it. > > The graph function--related stuff is admittedly similar to (and > inspired by) the Prismatic library, which wasn't released when I > started adding the functionality to babbage, but I prefer it, in part > because functions defined with defgraphfn can be called just as > ordinary clojure functions with no knowledge of their extra metadata, > whereas functions defined with defnk/fnk have an idiosyncratic calling > convention, AFAICT. The motivation in my case was that code for some > of the analytics stuff being rewritten could have shared data between > different computed analytics, but it wasn't obvious what the > dependency relations were and reorganizing things to use a gigantic > let, for instance, would have been a colossal PITA (in addition to > being very brittle). It's much simpler to have a bunch of functions > defined with defgraphfn that declare what they need to do their own > work and what they provide themselves, supply a few initial values, > and let run-graph figure out what has to be run before what. > > -- > Ben Wolfson > "Human kind has used its intelligence to vary the flavour of drinks, > which may be sweet, aromatic, fermented or spirit-based. ... Family > and social life also offer numerous other occasions to consume drinks > for pleasure." [Larousse, "Drink" entry] > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
