> For instance, a little while ago I was corresponding with someone who > had released a patch to Clojure. (This was Alyssa Kwan, in case you > want to look up the thread.) Her patch made refs persistent to > disk----something that seemed very much in the spirit of Clojure. > Dealing with disk persistence in a production-ready way may be its own > discipline, but in a language that wishes to "reduce ceremony", there > is no reason that you should have to worry about which database to use > when you merely want to write a program that remembers data when you > re-start it. The interface needed to do this is \almost there.... It > seemed an eminently useful thing, but it got posted to this list and > sank without a trace. Nobody from Core ever contacted her. (She > admitted it was a "hack", but isn't that how all patches start out?)
Several points worth calling out in the this short paragraph: (1) It is certainly a shame is somebody got frustrated and left the community, esp. if all that was needed was recognition of their input. The core team is doing better with this over time, but there is always room for improvement. (2) Improvements to Clojure do not, in fact, begin as hacks. Or even as patches. In general, they begin with a statement of a problem and some possible approaches to a solution. This is then followed by months of contemplation on and off at different times. 90% of carefully considered ideas are eventually rejected, or simply wither from lack of attention/urgency. (You can see some of these at [1], [2], [3], [4], and [5], below). For random patches, the failure rate is probably more like 99.5%. (3) The specific patch [6] you are discussing fails a bunch of different sniff tests: * creator acknowledges it is a hack * IP and licensing issues have not been resolved * new dependency underneath Clojure? hard coded to one db? * open composability issues (what happens to e.g. closed-overs?) * the patch is compound. There are a number of separate subfeatures hiding in the proposal, each also incomplete (e.g. a generic serialization mechanism) * "ACID most of the time" is not, IMO, in the spirit of Clojure * how is this better/worse than using a database? (4) That's just the sniff tests. It has already taken me about an hour to follow the thread and write this response, and I would categorize this idea as being in the "pre-design" phase of its lifecycle. It could easily take several more hours just to document the rough edges of this idea, which is tantamount to starting the design process. Once started, how long do you think it would/should take to design and implement a generic solution bridging Clojure's in-memory reference semantics with disk? It is absolutely true that as Clojure grows, more attention needs be paid to ease-of-use and ease-of-getting-started. Suggestions here are welcome! I think there are a number of issues around user experience that are almost entirely orthogonal to deep challenges such as disk-persistent references. As such, they are amenable to suggestions and improvements that do not require language changes or the same level of vetting that language changes imply. Leiningen [7] is a great example of this. Most of the core team's time is, and will continue to be, focused on solving hard problems. Rich will be presenting a great example of this at the NYC Clojure group on July 20 [8]. Cheers, Stu Stuart Halloway Clojure/core http://clojure.com [1] http://dev.clojure.org/display/design/Error+Handling [2] http://dev.clojure.org/pages/viewpage.action?pageId=950382 [3] http://dev.clojure.org/display/design/Resource+Scopes [4] http://dev.clojure.org/display/design/Asynchronous+Events [5] http://dev.clojure.org/display/design/Improve+Binding [6] https://groups.google.com/group/clojure/browse_thread/thread/561230749be02f28/655507b9773aa8be?lnk=gst&q=alyssa+kwan#655507b9773aa8be [7] https://github.com/technomancy/leiningen [8] http://www.meetup.com/Clojure-NYC/events/16166953/ -- 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
