I'm a bit curious. My immediate reaction was to ask what you use instead of Spring (none?), Hibernate (datomic?) and what did you use to provide the plumbing for web apps (assuming you needed it and didn't just write it all from scratch).
My second thought was then what is the difference between a framework like Spring and a stack like the one I am assuming you used if it were documented and became a de facto framework? On Sunday, 13 January 2013 15:28:38 UTC, Luc wrote: > > +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 clo...@googlegroups.com<javascript:> > > Note that posts from new members are moderated - please be patient with > your first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > -- > Softaddicts<lprefo...@softaddicts.ca <javascript:>> 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
