On Sat, Feb 2, 2013 at 12:28 AM, john <john.vie...@gmail.com> 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.
