puzzler, I guess I haven't said this, but I think it's worth saying that I have nothing against Specter. Godspeed to people who want to use it. And I don't think it should be judged against some other facility in another language; human progress would cease if for every Y, Y has to be a better X than X. Lenses, though, are one way that humans have tried to cope with accessing and updating nested data structures, and they're worth thinking about. Rich's hammock driven development talk influenced me powerfully because his espoused methodology ran so counter to my code-first-think-later instincts, and so I have the zeal of the converted with respect to the "do some research" step of HDD.
What you point out—the power and expressiveness of Specter—some people might consider kitchen-sink-y. My interest is in uncovering ways of dealing with the 90% of situations where something like Specter might be used and making them as ridiculously simple and Clojure-y as possible. That 90% of usage maps to, in my experience, maybe 25% of the feature set of Specter. (YMMV, of course.) I want to facilitate the writing of code that a typical Clojure developer will intuitively understand. Edwin On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote: > > Just finished reading through Racket's lens library to compare. Specter > can do everything that Racket's lens library can do, but the converse is > not true. Specter's navigators can do more than lenses. > > The lens-like navigators are the most obviously useful parts of Specter, > and maybe for some people that's all they need and they would prefer to > hide the other functionality. If so, it looks to me like it would be > trivial to build a lens library like Racket's out of Specter, and it would > almost certainly be higher performance than the "obvious" implementation of > lenses. > > But I don't agree at all with the claim that Specter is some sort of > offbeat, ill-researched version of lenses. It is something more advanced. > If Nathan had constrained his thinking to these other approaches, Specter > wouldn't have such richness of functionality and pragmatic performance > considerations. > > > On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom <brandon...@gmail.com > <javascript:>> wrote: > >> Responsible adults sometimes needs to access and modify deeply nested >>> data structures >> >> >> So far, my experience has been that it is almost always better to build a >> pair of flattening and unflattening transforms on the data. Especially >> since you frequently want only one flattening, but potentially many >> un-flattenings. The "unflattened" form (aka "documents") is usually an >> end-point where data goes to die; assuming it isn't immediately displayed >> on the screen. >> >> However, having said that, path-dependent / context-sensitive query is a >> very rich and interesting space that does have meaningful utility, >> especially in the context of graph-like datasets. This is especially true >> when combined with some kind of algebra for unioning/intersecting/etc. I'm >> also interested in this sort of thing for programmable user-interface use >> cases: Think text editors with multiple-cursors. >> >> I think experimentation is in order >>> >> >> Agreed. Here's some starting points for pre-hammock reading/viewing >> materials: >> >> *Tree Traversal * >> >> - XPath: https://www.w3.org/TR/xpath/ >> - CSS: https://www.w3.org/TR/css3-selectors/ >> >> *Richer Tree Querying* >> >> - XQuery: https://www.w3.org/TR/xquery/ >> - jQuery: https://api.jquery.com >> >> *Second-Class "Generalized References" (nee "L-values")* >> >> - Common Lisp: >> http://www.lispworks.com/documentation/lw50/CLHS/Body/05_a.htm >> - C/C++: >> >> http://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c >> >> *Lenses in Other Languages* >> >> - Haskell: >> >> https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation >> >> (great overview of key concepts!) >> - Racket: https://docs.racket-lang.org/lens/index.html >> >> *Graph Querying* >> >> - Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/ >> - TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
