discussion -- what's next

[dmiller2718]

Now that ClojureCLR 1.10 is out, time to think about next steps in the development of ClojureCLR.

It took way longer than normal to get 1.10 out the door, for all kinds of reasons.  Not least being the need to move to the world of .Net Core and not .Net 5.0, the resulting reworking of the build process and some documentation cleanrup, and a long digression looking for a solution to the loss of AOT-compilation in the newer platforms due to AssemblyBuilder.Save not existing.  Etc.  Oh, yeah, 2020 itself.

Having this finally out the door, I finally have time to think about next steps, about where to focus energy.

I've really only had time to focus on ClojureCLR itself, along with a few key libraries.  Tooling and other support has not had much attention.    I still need to focus on the base platform, but I do plan to pay attention to these other aspects going forward.

What I could use now is feedback on what you want/need. 

I have several things in mind as projects over the next year.

(1) rewrite the ClojureCLR compiler -- this could be as 'simple' as converting to Mono.Cecil for IL code gen, or a more complete rewrite of the compiler code, or a complete rewrite of the whole thing.  I have lots of reasons for this.  (Talked about here -- http://vijaykiran.com/2019/04/defn-48-david-miller/ -- if you have a lot of time to waste.)

(2) build the equivalent of deps-and-cli : See https://clojure.org/guides/deps_and_cli .  This will involve some non-triivial thought about how code is delivered, how the differences in the two ecosystems come into play.  I would through into this effort

(3) replacing lein-clr -- I still use it to manage the libraries I need to make ClojureCLR run, but it breaks my heart every time I move to a new PC and have to download the JVM and Clojure just to run a test on a library.   Lots of problems to solve here.

(4) editor support -- the tools are there, such as plug-ins for Clojure editing in VS Code, say.  Make that work for ClojureCLR, and tie it into the work in items (2) and (3).

(5) more libary ports -- or update the ones that have languished.  (I'm currently working on finishing NREPL.  it's a pain.)

(6) Documentation? Others?

What would help you the most?

-David

[Lawrence Jones]

I spend most of my time on Windows PC's.

During the past year, I've tried to build Windows executables for a couple of personal projects. The major problem I've encountered has been building projects. I've been able to work around editor issues, and was able to successfully build an executable that depended on other projects using an older GitHub project called camp; however, it was incredibly difficult and required upgrading camp (and discovering that NuGet has apparently changed in such a way that this was a bit difficult). 

Based on this work, I would "upvote" deps-and-cli and then, if necessary, a lein-clj replacement.

Thanks for all your work. It is incredibly helpful, useful, and possibly, thankless, but we all appreciate it.

[dmiller2718]

Not sure what form a lein-clr replacement would take.  Suggestions welcome.  But I suspect a deps-and-cli play would be a quicker and more fruitful payoff.

I've relied on lein-clr for a long time, but I would prefer not to.

The work is not quite thankless. :)

What I'm missing is feedback on what doesn't work, what the pain points are, etc.  

[Lawrence Jones]

Let me share some of my "adventures" this past year. It may not give you concrete ideas, but perhaps it will trigger others.

One small tool I use everyday is an application to read from a Markdown file containing my activities and to summarize how I spend my time. (Perhaps not the best time card tool, but it meets my needs and allows me to "play" with different implementations.)

At the beginning of the year, I had implemented this tool using ClojureScript running on `node`. It worked, and I learned, but then I also wanted to try out a Clojure implementation. This implementation did not require many code changes, but involved different tooling and libraries because it ran on the JVM. And the start up time seemed much longer than even my Ruby and Python implementations. So I wanted to try using ClojureCLR. 

A long, long time ago, I ran ClojureCLR using a plugin or Visual Studio; however, this was no longer available (and my preferred tools are the JetBrains tools). 

I eventually found `lein-clr`. This was not such a terrible tool, but required, as you pointed out, running Java to perform tasks on Windows, and, if I remember correctly, it was not at all obvious how to build a stand-alone executable. Additionally, I could not access anything from the NuGet ecosystem. Finally, because the tool has not been updated since 2015, I had to discover some "adjustments" to make everything work.

I continued searching and eventually found a GitHub project called `camp` (https://github.com/cbilson/Camp). This project, even though it was old (again, last changed in 2015), appeared to have the goals and implementation that "fit" into the Windows development ecosystem. Unfortunately, its age "bit me" with discovering "adjustments" to make it work with the latest (1.8.x) release of ClojureCLR. Worst of all, and I will grant that I am not really a NuGet expert (just working from Visual Studio and Rider spoils one terribly), I discovered that some change occurred accessing NuGet so that I was unable to access the latest NuGet libraries and so was "stuck" with "pure Clojure." Finally, I recently had space problems with my older laptop. To address these issues, I removed all binary files from my "personal projects" directory. This action freed space on my disk, but I "lost" all my knowledge of how to recreate an executable using Camp. I am sure I can get it back, but this will require probably finding another free weekend (Ha!).

I contrast this experience with recent experience with Elixir. Although overkill, I again used this task summary project as the vehicle to learn Elixir. As you can imagine, creating an executable pretty much just worked. (I recall the need to discover one "adjustment" to build an executable that differed from the "Programming Elixir >= 1.6" book.) Granted, Elixir has all packages in hex.pm; that is, a single ecosystem, but one aspect of development that the Elixir community has gotten right is creating an ecosystem to do the tasks that developers need to do.

My hope would be that, just like I can conditionally compile code targeting ClojureScript and Clojure, I would be able to use the `deps-and-cli` tooling to both leverage the newer Clojure documentation, but also to access the rich ecosystem available from NuGet (and perhaps Packet) to compile native executables using "native" (NuGet) packages to access Windows libraries targeting .NET.

Hope this provides some specifics both of the pain (probably even more well-known to you) and the vision.

Thanks, again, for all your hard work.

P.S. Probably a well-worn question, but how can I help?