On Sat, Sep 10, 2011 at 9:46 AM, Jan Rychter <jrych...@gmail.com> wrote: > If you use Clojure to build an application that you subsequently > launch and maintain, it is pretty much a given that you use contrib. > Lots of it, in fact.
I think that depends on when you started building stuff with Clojure. I get the impression quite a bit of old contrib grew up to provide functionality not in Clojure's core and I see quite a few pieces of old contrib that are explicitly deprecated because functions moved to Clojure 1.2 (c.c.string, for example, mostly moved to clojure.string long before Clojure 1.3 got under way). I suspect that folks who started with Clojure long ago and are relying heavily on old contrib, are probably relying on those old deprecated namespaces and functions and have simply avoided updating their code to use the newer, supported namespaces. I think the break in contrib coming with 1.3 will be good for the Clojure ecosystem overall because it will force a lot of folks to clean up their code :) As noted in another one of my comments in this thread, World Singles started with Clojure 1.2 but switched to Clojure 1.3 early on and so we've essentially not been allowed to depend on that old, unsupported contrib code which I view as a big positive for us (as well as getting the performance boost of the updated numerics in Clojure 1.3). One of the things World Singles needed early on was clojure.contrib.sql so I pushed for that to be migrated and have ended up being the maintainer now. If you can't find an author to migrate and maintain an old contrib library, another option is for you to volunteer to do that work and then you have the added benefit of being able to enhance the library to better suit your needs (e.g., I added the ability to return generated keys from insert operations in clojure.java.jdbc). > importantly, I worry that I won't be able to take advantage of Clojure > 1.3 in any of my applications anytime soon. A definite possibility - but changing your code to not rely on outdated, unsupported libraries would have benefit to you in the long run, yes? > I think contrib modularization should either be carried all the way in > time for 1.3, or stopped altogether (meaning I could continue to use > the same old monolithic contrib code with Clojure 1.3). Sorry, that ship done sailed a while back. I don't know how much work it would be to make the modular contrib work on Clojure 1.3 (work stopped on contrib around 1.3.0 Alpha 4) and given the number of library authors who've stepped up to modernize and maintain new contrib versions of old library modules, I can't imagine who'd put in that work (to make old, unsupported code run on Clojure 1.3). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
