+1, excellent summary of the key points. We got rid of Spring, Hibernate et cie for the same reasons. They were somewhat needed in Java but in Clojure we found that they were cumbersome to use and brought little value.
We realized along the way that some generated Java code (Hibernate is a good example) was buggy and needed to be maintained by hand. If even the generated code to glue things together is buggy, were is the gain ? You end up having to maintain it... We cut our backend code by a magnitude of more than 15 times by switching to 100% Clojure and getting rid of the frameworks. Now down to 15000 sloc and less dependencies to track... Luc P. > 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 -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- 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
