On Sunday, June 17, 2012 6:31:34 PM UTC-6, Sean Corfield wrote: > > On Sun, Jun 17, 2012 at 11:59 AM, Kurt Harriger <kurtharri...@gmail.com> > wrote: > > That is my point, representations SHOULD be considered implementation > > details, because representations change... if you treat them as > contracts > > your code will break everywhere, if you wrap them with abstractions your > > code will only need to change in one place... > > Have you watched Stu Halloway's talk about the design of Datomic? > Evident Code, at Scale: > http://www.infoq.com/presentations/Evident-Code-at-Scale > > You said earlier in this thread that Clojure is your first Lisp so > it's possible (likely?) you don't yet realize how different it is to > the languages you're used to. If you watch several of the > presentations by Stu Halloway and Rich Hickey and some of the other > Clojure/core folks, you should get an appreciation of why data-as-API > is reasonable in Clojure, in the same way that interface-as-API is > reasonable in Java. It's an immutable contract. It can be operated on > by all the standard Clojure functions but it's still a contract. It is > not necessarily the representation - it is the API you present to the > world. You can change the representation any way you want and if the > API does not change (in the same way that an interface wouldn't change > in Java), then you continue to present the same data structure to > client code, even if it is now a projection of the representation, > rather than the representation itself. >
I didn't get a chance to see it, before but watching it now and he says a couple interesting about abstractions right off at the beginning.... ideal number of abstractions 0. We abstract to much interfaces are too large.... etc... One of the sayings I hear reiterated is "it is better to have 100 methods that operate on one data structure than 10 methods that operate on 10 data structures." Yet how is this different from one large interface with a hundred methods? Now if you want to change a map so that :area which was previously an precomputed value to a deferred computation you now need to override ILookup, ISeq IMapEntry, perhaps others to ensure keyword lookups and destructuring works etc... so while some see clojure as removing unnecessary abstractions I see it as adding creating one bloated abstraction around a persistent map which is hard to change due to the number and complexity of the built-in abstractions then 1 function that is relevant to my problem domain. I have also found that clojure code lacks cohesion we hate objects so we are just going to throw everything into one large namespace and say we have none... In OO I might call this a god class? I don't know, I'm not sold yet... but I'll keep watching. I like the data as api idea in theory, as it encourages declarative programming and really thinking about the problem. I don't disagree that many java abstractions could be considered premature and could be added later if needed... but sometimes they really are needed. I discussed this before in regards to HTML that dependance on representation can limit the ability to quickly implement new features... In the beginning html probably didn't need any additional abstractions but as the usage and domain complexity increased it turned into a mess that requires apis to both read and write those data structures. I was very excited about using clojure a year ago and now that I've spent a few months with it I've been very frustrated... Its possible something just hasn't quite clicked yet, but I'm also beginning to notice issues in other apis. Many libraries have been deprecated, replaced and rewritten due to breaking changes to clojure core or other libraries and that worries me a bit.. but clojure is still maturing and no one gets the abstractions exactly right the first time so I'm kinda going back into a wait and see mode...but I can't sit on the side lines entirely cause I just wrote a reasonably complex clojure program that I need to maintain still :) > I have made several reasoned arguments for getter functions... If you > > disagree thats fine. > > Your arguments are reasoned for Java and its ilk because in those > languages, data structures are just representation details - and they > are mutable, so they can't possibly be an API. Your arguments are not > reasoned for Clojure because data structures cannot be modified by > client code - they _can_ be the API, and an API that can be used > directly by map / filter / reduce and all the sequence functions and > so on. > > Vincent said: > > > Well, but if interfaces change? That's the same as data representation > > change in clojure. > > This is the fundamental shift in thinking that immutable data-as-API > requires. It's how you get some of the real benefits from Clojure. > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > World Singles, LLC. -- http://worldsingles.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > -- 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
