See my earlier post on the genesis of ClojureCLR.
After genesis comes exodus, if memory serves. "Exodus" being a "going out", I hope that is appropriate as the next step for ClojureCLR. (Not the forty years in the desert part.)
Where ClojureCLR stands today
Today, ClojureCLR is a mostly feature-complete implementation of Clojure. It closely tracks developments in the JVM implementation. Version 1.3.0 was released about a week after the mainline version. It is up to date on the current alpha release of 1.4.0. It passes all (relevant) tests in the test suite, except for one (failing due to an extra space before a newline in a test of a pprint format that I don't even understand).
Today, ClojureCLR is essentially unused.
I conducted a survey on ClojureCLR recently. The results are summarized over on the ClojureCLR blog. That survey identified just a few individuals presently using it. A majority of respondents had never even touched it. (I thank them for taking the time to give feedback about why.) At the 2011 Clojure/conj, a BOF on ClojureCLR was attended by about six people, only one of whom had actually tried it.
If ClojureCLR were to be judged on the basis of usage, it would have to be judged a failure.
There are other criteria that yield less harsh verdicts. The viability of Clojure on a platform other than the JVM has been proved. (ClojureScript also answers this.) Some of the problems arising from the differences between the JVM and the CLR have been dealt with. ClojureCLR itself is stable and sound. On a personal level, I achieved a number of the goals I established for myself (not including writing Lisp code; this project is mostly C#.)
The survey identified viability of the project as the biggest obstacle to use. Confusion about the status of the project in the Clojure ecosystem was noted.
I've been told that ClojureCLR has the best wishes of Clojure/core, but at this time they do not have the resources or inclination to support it more fully. I don't see this situation changing anytime soon, unless a significant consulting opportunity appears. Promoting Clojure on the JVM is the highest priority.
I imagine that real engagement with ClojureCLR will come only with protocols-from-the-bottom-up Clojure-in-Clojure, the oft-stated dream of Rich. That is the right approach to platform ports of Clojure. The current work, a testament to keyboarding endurance, will eventually be tossed. It will have served its purpose when the lessons learned are applied in a C-in-C port.
For now, it is best to describe this project as "community-supported".
What I'm going to do
Eat dog food.
I made a fundamental error from the start of this project: I did not eat my own dog food. Building ClojureCLR was my only active project. I did not use it because I had no project requiring it. (And no time left over.) I had hoped others would use it and give guidance on what needed improvement. That happened a little, but not enough, and I often did not act quickly on what there was. I'm sure the rough edges that persisted were enough to turn many away.
It used to be that I only needed to keep with Rich. Then it was Rich+core. To go forward, it appears I need to duplicate the efforts of the entire village of people that are creating the Clojure(JVM) ecosystem. I can only hope that with a clear roadmap, others might be finally be inspired to pitch in. Else, it's going to be a long haul working through the desiderata identified in the survey.
It is wonderful to see the excitement grow around Clojure and to see the excellent work around it being created by so many smart people. I"m looking forward to what the future holds for Clojure and ClojureCLR.
There are other criteria that yield less harsh verdicts. The viability of Clojure on a platform other than the JVM has been proved. (ClojureScript also answers this.) Some of the problems arising from the differences between the JVM and the CLR have been dealt with. ClojureCLR itself is stable and sound. On a personal level, I achieved a number of the goals I established for myself (not including writing Lisp code; this project is mostly C#.)
The survey identified viability of the project as the biggest obstacle to use. Confusion about the status of the project in the Clojure ecosystem was noted.
I've been told that ClojureCLR has the best wishes of Clojure/core, but at this time they do not have the resources or inclination to support it more fully. I don't see this situation changing anytime soon, unless a significant consulting opportunity appears. Promoting Clojure on the JVM is the highest priority.
I imagine that real engagement with ClojureCLR will come only with protocols-from-the-bottom-up Clojure-in-Clojure, the oft-stated dream of Rich. That is the right approach to platform ports of Clojure. The current work, a testament to keyboarding endurance, will eventually be tossed. It will have served its purpose when the lessons learned are applied in a C-in-C port.
For now, it is best to describe this project as "community-supported".
What I'm going to do
Eat dog food.
I made a fundamental error from the start of this project: I did not eat my own dog food. Building ClojureCLR was my only active project. I did not use it because I had no project requiring it. (And no time left over.) I had hoped others would use it and give guidance on what needed improvement. That happened a little, but not enough, and I often did not act quickly on what there was. I'm sure the rough edges that persisted were enough to turn many away.
It used to be that I only needed to keep with Rich. Then it was Rich+core. To go forward, it appears I need to duplicate the efforts of the entire village of people that are creating the Clojure(JVM) ecosystem. I can only hope that with a clear roadmap, others might be finally be inspired to pitch in. Else, it's going to be a long haul working through the desiderata identified in the survey.
It is wonderful to see the excitement grow around Clojure and to see the excellent work around it being created by so many smart people. I"m looking forward to what the future holds for Clojure and ClojureCLR.
No comments:
Post a Comment