Nathan, I am deeply sorry for offending you. Truly. It was not my intent. My entire argument can be boiled down to Specter reminds me of the Common Lisp LOOP macro. Is that like saying "I don't like parentheses"? Maybe.
Again, I apologize. Edwin On Thursday, March 9, 2017 at 10:15:55 AM UTC-5, Nathan Marz wrote: > > Edwin, these personal comments about me are extremely inappropriate. Your > claim that I ignore the work of others is just plain wrong, and that you > would make such comments out of the blue is truly incomprehensible. > > You claim Specter is "deeply un-Clojure-y" without providing a single > example. This makes your argument boil down to "I don't like the way > Specter makes me feel", which is no different than the complaints > non-Lispers make about Lisp's parentheses. > > Specter's core is just a simple interface and a high-performance way of > composing implementations of that interface together. Everything else in > Specter (the navigators) is built on top of that interface. So if you only > want to use the "lens-like" functionality, you can literally ignore > everything else because it doesn't affect you in any way. Additionally, > supporting those other use cases does not make the basic use cases more > complex or verbose. > > I've found that Clojure programmers find Specter to be very intuitive. > What they have trouble grasping is the full scope with which Specter can be > applied, because thinking about data structures in terms of navigation is a > new mindset. This is exactly the blub paradox as famously written about by > Paul Graham back in the day. > > Finally, suggestions that more research and experimentation is needed in > this area must be paired with at least one example of how Specter is > deficient. Otherwise, it's an empty discussion. > > > On Thursday, March 9, 2017 at 9:00:37 AM UTC-5, Edwin Watkeys wrote: >> >> 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> >>> 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 >>>> 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 >>>> 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. >>>> 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.
