Tuesday, November 22, 2011

ClojureCLR: exodus?

[Edited slightly on 2011-12-15 to rectify tone.]


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.

Thursday, November 3, 2011

ClojureCLR: genesis

In the BOF for ClojureCLR at the recent Clojure/conj 2011, there seemed to be some interest in the genesis of ClojureCLR.   For the record, here's the story. 

Rich Hickey's original Clojure implementation effort targeted both the JVM and the CLR.  Rich said that he "got tired of doing everything twice", and  eventually dropped the CLR effort to focus on the JVM.

In the fall of 2008, I had several itches I wanted to scratch:  I wanted to code a decent-sized project (tired of just programming examples for my lectures);  I wanted to do some Lisp, something I had not done for over 15 years;  I was interested in spending more time in the dynamic language world; I wanted to learn more about current practice in functional programming; and, with the advent of things like JRuby and IronPython, I wanted to understand how dynamic languages were being implemented on top of things like the JVM and CLR.

While poking around, I ran into Clojure and then the Dynamic Language Runtime (DLR) for .Net.  So I decided to look into the feasibility of implementing Clojure on the CLR platform using the DLR -- pretty much scratching all itches at once. That was in October to November, 2008.

I had a basic proof-of-concept implementation--basic data structures, reader, evaluation based on compilation into DLR ExpressionTrees and then into IL--by the beginning of 2009.  On January 12, 2009, I sent an e-mail to Rich Hickey with a picture of the famous ants simulation running on the CLR with a WinForms GUI.  Slow as molasses, but it ran.  More than 90% of core.clj loaded at that point.

Introducing myself to Rich, I stated:
 I feel no need for this code to see the light of day.  However, if the code reaches the point of usefulness – 98% feature-complete and performance no worse than 2X of the Java implementation, say—and if no better implementations on top of .NET have surfaced, and if you are  interested, then I'd be happy to turn it over.
I asked Rich if he would mind an occasional query as I moved forward.

Rich responded, in part:
What is important to me is that any effort I apply ends up in the Clojure project. Towards that end, I would ask you to consider making your efforts a contribution to Clojure under the contributor agreement. Then, your .Net port could live in clojure-contrib alongside ClojureScript (a port of Clojure to JavaScript). The long-term objective would be a set ot core .clj files that supported all ports without changes, all platform specifics isolated in the support libraries.
I understand that you feel your work is still in the early stages, but would encourage this contribution sooner rather than later:
  • The community can get behind a single, supported effort.
  • I can understand the issues you are facing and incorporate that in my decision making process.
  • You can incorporate my feedback earlier in your process
  • You can get help. 
...
The open source community is pretty tolerant and understands work-in-progress, so being nearly complete is not a pre-requisite. Nor should you be concerned about losing control over the direction of the implementation - I understand the satisfaction of authorship, and the drawbacks of teams. clojure-contrib is a small group and each principal author retains stewardship over their library. 
In short, I'm very interested in what you've done and interested in supporting it under the aegis of the Clojure project.
A little more work, gettting the CA in, etc. and ClojureCLR went public in February, 2009, as part of clojure-contrib.  It was moved to its current home in Rich's account on github in June, 2009.

And that's how it started.