On Jun 17, 2012, at 9:46 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Sun, Jun 17, 2012 at 8:06 PM, Kurt Harriger <kurtharri...@gmail.com> wrote: >> 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? > > You've misunderstood the intent behind the quote. By using a generic > data structure, you have more functions available to you - and you > don't have to duplicate each function for each different data type (10 > methods that operate on 10 data structures is 100 methods but really > only 10 different ones). By using a generic map, all functions that > work on maps are available to you. By choosing a specific data > structure for your "object", you are forced to write a new version of > every function you might need. Your one line getters might be trivial > enough (one for every property) but now you can't use your object with > any function that takes an associative data structure and you have to > write adapter functions for each of those functions too. > >> 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.. > > This is an API change, just like changing a Java interface. In OO-land > folks get very blasé about changing data structures because they > obsessively wrap everything up and they seem to ignore all the extra > code they have to write to do anything with these objects. By > designing an API based on a data structure, there's a lot less code > needed to interact with it. If you change the API, yes, client code > needs to change, just like in Java. If your object's API changes so > that area is not precomputed and becomes a deferred computation, that > is still a change to the contract (because the performance of > accessing area changes - and calling getArea() repeatedly now becomes > expensive rather than a trivial operation). If you're designing a > data-based API, you need to consider what to provide and what the > characteristics of each part of the data structure are, just as you > need to with a Java interface. What's missing in Java interfaces are > any consideration about performance and what the abstraction really > means. A fair point, getters dont really solve the problem they just change it. The problem i had was generating large complex data structures as input to other functions made me realise the representation was not ideal, changing it however was much more work than I expected. I find that what i am doing is creating a new namespace, copying the code, change it then go about replacing the old namespace with the new and this isnt working well for me.... I need seams for refactoring otherwise small changes take forever. I wish i could say that my code improves each time i rewrite it but as the complexity increases the more things change and the worse everything else gets. In oo i know how to handle this complexity, in clojure the refactoring patterns are less clear to me. > >> Its possible something just hasn't quite clicked yet > > Quite possible. If you have a long history of OO thinking, FP can be > really hard to get into. I find it much easier to teach FP to folks > who've had little or no OO experience. Getting OO folks away from > thinking about state as something inside an object that they can just > poke at can take a while :) > >> Many libraries have been deprecated, replaced and rewritten due to >> breaking changes to clojure core or other libraries and that worries me a > > To be fair, the shift in contrib from 1.2 to 1.3 was more about > getting rid of unmaintained code and ad hoc experiments and focusing > instead on well-maintained libraries that are useful to real world > developers. Several of the authors of the abandoned parts of > monolithic contrib will be very quick to tell you not to use their old > code because it was half-baked or otherwise flawed... > >> I can't sit on the side lines entirely cause I just wrote a reasonably >> complex clojure program that I need to maintain still :) > > And I have thousands of lines of Clojure in production too, and a > database with millions of users - and thousands more signing up every > day. We started on Clojure 1.2 but switched to 1.3 early on and went > to production with Alpha 7 (or 8) and now we're on Clojure 1.4 (and > testing on nightly builds of 1.5, just to be sure we're future proof). > Where we needed libraries from 1.2 that were not 1.3 compatible, we > made them compatible and worked with the library maintainers as much > as we could. clojure.contrib.sql moved to clojure.java.jdbc and is > actively maintained because of that. > -- > 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 -- 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
