While I've looked at Specter several times, I have yet to use it in a project for many of the same reasons that Rangel mentioned. Either my data is shallow enough that clojure.core functions work just fine, or my data is complex enough that I need cross-entity joins, and arbitrary clojure logic. In short: I don't often need a path-based transformer, I need a query engine for Clojure data.
Timothy On Tue, Feb 14, 2017 at 2:37 PM, Rangel Spasov <raspa...@gmail.com> wrote: > Nathan - Specter has been an indispensable part of any > Clojure/ClojureScript that I've started in the recent 1+ years. From my > experience with it so far (and I'm definitely not using it to its full > potential) it has had one killer feature and that is modifying a nested 3+ > levels deep data structure that randomly contains vectors, maps, set, et > al. For that use case it is a KILLER library - it's outright amazing (and I > don't use that word lightly!). From that perspective, that would be two > thumbs up for including it in Clojure proper (if it was up to me). > > Here comes the BUT :). The more I've used Specter, the more I've come to > the opinion that the less you need Specter, the simpler your data structure > "architecture" (I generally dislike that word hence the quotes lol) tends > to be. In a bad case scenario, Specter might encourage someone to come up > with a very deeply nested data structure when a much shallower would do the > job. Now, I definitely know and generally agree with "100 functions on 1 > data structure is better than 10 functions on 10 data structures" > recommendation. But from my 4+ years experience with Clojure, over-nesting > your data structures tends to become a little bit like OOP inheritance > where you overspecialize the data and the details about your data. > Especially in the domain of UI programming/React/ReactNative but also for > general backend data-processing and transformation I've found it easier AND > simpler to rely more on data "composition" rather than data "inheritance". > In other words, keeping your data structures generally shallow, 2 or > maximum 3 levels deep. > > All that being said, there's many, many cases where the data you're > presented with is set in stone either by the problem domain or another > person before you (or your past self :) ). In those cases, Specter is > ESSENTIAL. Places where I use it to great effect are random/unknown data > structure processing for scraping/parsing HTML and processing various API > responses where the data shape and structure is not under your control. > > Thank you once again for developing this great library - I'm looking > forward to everyone's responses in this thread! > > > On Tuesday, February 14, 2017 at 1:02:55 PM UTC-8, Nathan Marz wrote: >> >> One of the most common questions I get about Specter is whether it will >> ever become part of Clojure core. I think it's an interesting proposal and >> would like to see what the community and core team thinks. >> >> The primary reason for contributing would be that Specter makes Clojure a >> stronger language. For a language that embraces simplicity, I've always >> viewed the complexity of dealing with nested data structures a glaring >> weakness of Clojure. The existing stuff in Clojure, like clojure.walk, >> zippers, update-in, etc., just doesn't cut it. This problem is very common, >> and Specter completely solves it with near-optimal performance. >> >> The main thing that makes me hesitate to suggest this is getting >> bottlenecked on Clojure's dev process. However, Specter is very well >> developed at this point so it doesn't need to move fast anymore. >> >> Please share your thoughts. >> > -- > 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/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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/d/optout.
