Re: suggestion for clojure development

[Tal Liron]

On 10/01/2011 11:49 PM, Sean Corfield wrote: I'm curious, what parts of contrib are you relying on that haven't found active maintainers? Perhaps we can figure out how to address that, to reduce your pain? It's not that they weren't maintained. Well, I actually don't know which was maintained and which wasn't, I'm mostly relying on the information on the mailing list, and also on your handy page, which mentions partial migration of some contribs: http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go The issue for me (in the past) was quality, not whether they were maintained or not. And the issue for me now is concern about what will happen to all these contribs in the future if a core language feature changes, such as the dynamic Var issue in 1.3. If these contribs are not being built and shipped as part of Clojure, it seems risky to rely on them. Some might get upgraded, others might languish. What's lacking is any kind of statement of commitment. Instead, if I understand it correctly, we see the core Clojure project moving back from a commitment model to a more community-management model. You know, it doesn't have to be that contribs would be shipped with Clojure core. There could be an essential "standard library", a selection of important contribs that is maintained as a sister project to Clojure. So, I'm not necessarily arguing for a move back to the monolith that existed up to Clojure 1.2, but for a standard lib *distribution* with a test suite and a Clojure stamp of approval. That way, when a new version of Clojure comes out, I can take a look and see if standard lib is up to date with all the libraries I use, and maybe point-check the other libs that are not in the standard. As it stands right now, I have to point check every single library -- as well as its trail of dependencies -- in order to evaluate the cost of migration. It's worth taking a look at the how migration has happens in the Python world. Python 3.0 indeed represented a major break, but then there's "from __future__ import" that has existed for a while in the 2.0 branch (*which is still being actively being maintained even though 3.0 has been around for a while*) allowing for old 2.X code to slowly migrate to 3.0 futures. For example, the new dynamic Var breakage in Clojure could have been solved with an optional switch per namespace, requiring explicit enabling for now, and thus allowing legacy code (for example, from contribs!) to continue working for a few more versions in deprecated mode instead of being just borked. (Note: I'm realizing now that I'm sounding whiny about the quality issue. I will try to find time to go back to some of my old code, gather the workarounds I found for bugs -- a few in the JSON and in SQL-now-called-JDBC contribs -- and find a way to turn them into patches. Part of the problem is that my work is not always in an open source environment, so getting approval to extract these things ends up more time-consuming than the dev work.) -- 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