Great points. Also take RoR as an example: ruby, dynamic as it may be, still relies on the notion of a class as code owner which means that the class is the namespacing unit for all code that wants to participate in operating on a specific data structure, such as a hash or array.
After 20-30 years of intensive experience with the concept of encapsulation, the final verdict is that it was a great idea for in-house, monolithic projects of the 80's, but is an annoying impediment in the modern world of composable open-source. This difference is akin to the difference between Unix's concept of small tools operating on the common data format as opposed to plugins contributed to all-encompassing environments, a typical scenario on Windows. On Sunday, January 13, 2013 2:51:59 AM UTC+1, Malcolm Sparks wrote: > > The Clojure tradition of mixing-and-matching small libraries rather than > relying on large frameworks like Spring did not emerge by accident. The > Java language itself causes library authors to create their own types > thereby creating an impedance mismatch with other libraries. Spring (and > similar frameworks) have evolved to address these issues, using clever > design patterns such as interface adaptation. In contrast, Clojure > libraries simply use common data structures (maps, sequences, sets) and > Clojure itself has all the functions to convert between them where > necessary. The result is that *Clojure libraries integrate with each > other relatively seamlessly without the need for frameworks like Spring*. > In other words, the very existence of Spring and other 'compendium' > frameworks in the Java world is evidence that a lot of work is required to > get Java libraries to work together. The absence of equivalents in the > Clojure world is something that we should be very happy about. When you > choose a compendium framework, you have to work with whatever libraries > have been chosen for you by the framework provider, and hope that the doors > you want to walk through are unlocked prior to your arrival. All too often > they are not. > > I've long felt that large platforms like Spring, Eclipse and even the JDK > itself are a trade-off between the benefits of ease-of-use with the > *sacrifice > of future innovation* - platforms give incumbent libraries a *premature > monopoly* on a functional area, thereby stifling competition from a > potential worthy successor library. What I like about the Clojure > eco-system is that, to a large extent, no such monopolies have emerged, > there is a truer meritocracy because it is possible for libraries to emerge > that provide a better or alternative approach to existing ones - so Ring, > Aleph, Hiccup, Enlive, Compojure, Moustache and Liberator (to name but a > few) can all peacefully co-exist. Innovative new libraries crop up all the > time - so quickly it's almost hard to keep up! In which case, we shouldn't > confuse frameworks with simple collections of libraries that some curator > has verified work together. This is akin to the function that GNU/Linux > distributions perform and there is definite value, especially for > beginners, in the community shaping these collections. > -- 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
