"Availability of ClojureCLR-specific documentation" was fourth on the list of frustrations. "Interop support" was sixth. Under desirability, "Sample framework interop code" was #2 and "Wrappers for MS libraries/frameworks" was # 5.
Related comments include:
- In general the lack of examples of typical uses, something which is pretty well covered in the JVM based Clo[j]ure, things like jetty/ring, jdbc, and GUI (which tends to be a lot more important in the windows world).
- Support for .net generics is extremely important! Lack of [this and another] features were the show stoppers for me.
- Writing my libs in Clojure.CLR and using them in ASP.NET apps.
- anything that makes interop between ClojureCLR and existing CLR languages easier/seamless has my vote.
- interop with C#
| Linq | 26 | 59% |
| ASP.NET / MVC | 20 | 45% |
| Reactive Framework | 15 | 34% |
| WPF | 13 | 30% |
| Windows Runtime (Win8) | 10 | 23% |
| WinForms | 9 | 20% |
| XNA (incl. XBox) | 9 | 20% |
| Silverlight | 7 | 16% |
| WCF | 7 | 16% |
| Azure | 7 | 16% |
| Entity Framework | 5 | 11% |
| Robotics Studio | 5 | 11% |
| Sharepoint | 3 | 7% |
Linq's #1 status surprised me. I think of Linq as providing a functional approach to accessing sequential data, and Clojure is ... that. However, my use of Linq to date is minimal--implementing ClojureCLR does not stretch that muscle. Perhaps people want to write Linq extensions in Clojure for use in C#? Perhaps some could comment on this.
Question for you: What form of Linq interop is desired?
The next several entries--ASP.NET/MVC, Rx, WPF--did not surprise me. Reading it just now, I realized that I left out the TPL (Task Parallel Library). I wonder where that would have ranked.
I tossed in Windows Runtime (WinRT from Win8) for fun. Its high rank was a surprise.
Question for you: How are you planning to use ClojureCLR with WinRT?Steps suggested by the data:
Action item: Provide better documentation and examples for interop at the class/method level, particularly for things not in the Java world, such as true generic classes and methods, by-ref parameters, etc.
Action item: Provide tutorial examples of interop with key MS frameworks: Linq, ASP.NET/MVC, Reactive Framework, WPF, TPL.The situation regarding wrappers for MS libraries and frameworks is less clear to me. You can't 'wrap' ASP.NET. Calling out to ClojureCLR code from ASP.NET seems more likely. Interop from C# back to ClojureCLR is the real problem here (probably). I can imagine wrappers for smaller things such as Rx, TPL, etc.
Action item: Provide tutorial examples of C# calling back into ClojureCLR.
Action item: Identify smaller libraries that would benefit from wrappers and implement same.
I was also puzzled by Linq... I was just about to write how this should be ignored...but then I realized one area where Linq integration would be handy. Consider working with Entity Framework (or any other IQueryable Provider):
ReplyDeletectx.tPeople.Where(x => x.Name == "John")
one would think that we could do this in Clojure:
(.Where (.get_tPeople ctx) #(= % "John")))
But this won't work...because the lambda will compile down to a IFn. And Where in the IQueryable sense expects a Linq.Expressions tree.
So in essence, what we should investigate, is a Clojure form to Linq.Expressions compiler. That expression would then be handed off to Entity Framework and then passed to the SQL server. We might look at F# to see how they handle this...
The first pass of the ClojureCLR compiler creates an ExpressionTree, but v2.0 while Linq is v1.0. I'm not sure in 4.0 what the difference is. Worth investigating.
ReplyDeleteAnother path is to make greater use of the type reflection machinery for generic types found in DLR. IPy and IronRuby use it to make interaction with the fancier extensions methods easier. I've not done it up to now because to use those methods appears to require implementation of some of the DLR hosting mechansisms, something I've avoided looking at so far.