Let's talk about another context here, we have been in prod since Jan. 2009. With a pre V1.0 version of Clojure and we used contrib in the state it was in these early days.
Staying away from contrib in production was never a concern to us. We just made the commitment to live with it and wait for it to evolve. Following upgrades was something we expected. We had to make a choice in 2008, laying down 60,000+ of java code or 10 times less in Clojure. We now have over 14,000 lines of Clojure code. We went through two upgrades, 1.0, 1.2 still carrying contrib as it matured. Upgrades never involved a significant effort. Most of this was carried on with the normal dev. flow. Once the new contrib split is in place and stabilized, we expect to spend at most 30 man days to upgrade to it and 1.3, testing included. I cannot state any louder the economy of time of using Clojure vs Java, even Ruby (which was considered before crossing Clojure's path). This encompasses writing new code, getting it prod and living to incremental changes (java 5, 6 and now 7 around the corner). The new modular contribs are tested against 1.2, 1.2.1 and 1.3. Once that bridge is crossed in our code, we do not expect more pain in the future than we are "experimenting" now. The notion of pain seems very relative after reading this thread. Given the pace at which other languages evolve, I can understand that the upgrade path seems abrupt but you have to compare apples with apples. Having a huge pile of non expressive code with very small incremental changes looks reassuring but it's not a way to leapfrog the competition. On the other hand, having ten times less code means you can live with a more steep upgrade path and do more in less time. Choose your hell/paradise accordingly :) Luc P. On Sat, 1 Oct 2011 20:10:47 -0700 (PDT) Tal Liron <tal.li...@gmail.com> wrote: > On Saturday, October 1, 2011 9:34:46 PM UTC-5, David Nolen wrote: > > > > To give some context: > > > > I appreciate the context, David, and I agree that the change needed > to happen. It's likely my fault for not being enough in the loop to > realize what the 1.3 change would mean for me. I expected some > breakage, but I think I was taken by surprise by how far-reaching it > was. > > The fact that such important changes needed to happen underscores my > point -- which I doubt anybody would disagree with -- about the > maturity of the project. I'm sorry if this offends the people who > have worked hard to get 1.3 to where it is -- I appreciate all the > effort, which is in the right direction. But, somebody has to be that > nagging voice of legacy, so I'll let it be me and Arthur. :) Almost > no thought at all was given to legacy: the most I saw was a few tips > on migrating in the changelog. (Again, could be my fault for not > looking hard enough.) > > I did realize pretty early on that the contribs were not all of prime > quality, but what other choice did I have? Fall back to standard JVM > API? I did do that in some occasions, but it's awkward. Patch the > contribs? I just didn't have the time (nor patience) to reinvent such > essential wheels. (I almost did submit a patch for contrib.json... > it's somewhere on my todo list from a year ago...) Again, the fact > that Clojure didn't and still doesn't have a good standard library > (beyond the rock-solid foundation of the JVM) with a full test suite > is a sign of the vast amount of work Clojure still has ahead in order > to become as widely adopted as it deserves. > > Stu's comment actually worries me in this respect: the fact that each > contrib has its own version may make it easier to evaluate them > separately, but it would appear to me as a defeatist goal for Clojure > moving forward. What I would want to see is a coherent standard > library that is centrally maintained. Not everything deserves to be > there, of course, but there are obvious candidates for essentials. > Contrarily, it seems that effort is being put into cleaning up the > core and jettisoning anything merely suspected of being superfluous. > So, what's going to happen to all that stuff outside? Will it be > maintained by "the community"? The same "community" that made the 1.2 > contrib? Or maybe Clojure 1.5 will bring some of them into the fold? > (I'm not being sarcastic; these are honest questions about the > possibilities and vision.) > > Being a hardcore JVMer, I am used to APIs in java.* and javax.* > namespaces as a sign of how close to the center and dependable they > are. Could something like that be feasible for the Clojure project? > > Someone on this thread mentioned that it's all as expected, and that > Clojure is just for a bunch of geeks, anyway, so breakage is no big > deal (I'm paraphrasing). I hope for a strong official position > against that: many of us believe Clojure should not be a niche > language. It's the first Lisp in decades with broad practical > potential and could pave the way for Clojure or other Lisps in more > specific niches. The stakes are high: if Clojure is widely adopted > and trusted, the quality of software everywhere and for everyone will > improve. > -- Luc P. ================ The rabid Muppet -- 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
