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. On Friday, 11 January 2013 16:52:05 UTC, Paul Umbers wrote: > > I've been experimenting with Clojure web services recently, and posting > the work on GitHub <https://github.com/3rddog/doitnow> and my > blog<http://internistic.blogspot.ca/search/label/clojure> > . > > When putting this test app together, it occurred to me that most other > languages have a full-stack API available which makes life easier when it > comes to making decisions about which libraries/APIs/frameworks to use. It > also reduces the possibility of "impedance mismatch" between the libraries. > For Java, you can use Spring (or any one of a dozen or more other popular > frameworks), for Scala there's Typesafe, and so on. Clojure has Compojure, > Ring, several logging, validation and database libraries, and they can be > used together but they don't constitute a coordinated full stack - and that > creates issues. > > For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 and > not the latest version of Ring (1.1.6) which has significantly better util > functions available - but I can't use them until Compojure catches up. By > the time you add logging, validation, data access, etc the odds of a > mismatch between these libraries goes up dramatically. > > This is a concern, because these mismatches must be worked around in *my*code > and are likely to break as the libraries are upgraded in future > versions. So, I'm having to spend my time maintaining what are essentially > "patches" for third-party libraries just so that they work together. > > Now, it may not be the best decision to try to put together a true > full-stack framework from scratch, but is it worth choosing a bunch of > existing frameworks and coordinating their releases - in much the same way > as Eclipse coordinates plugin releases for major releases - so that putting > together a full-stack app becomes easier? > > Projects taking part in the "meta-project" will work together to harmonize > their functionality & APIs, and coordinate their development cycles & > releases so that the meta-framework remains consistent and easily usable. > > Is this another barrier to adoption the Clojure community can remove? Is > this even a barrier? Am I missing something? > > Thoughts? > > [Also posted to http://www.reddit.com/r/Clojure] > -- 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
