IronScheme is mentioned on Wikipedia as a successor to a failed project called IronLisp, bringing Lisp to CLR and .NET, the way Clojure does for the JVM. Does anyone have experience with this language? It looks fairly complete (99%) but I'm not sure how to judge whether it's worth my time to fiddle with getting it set up or not. By stable or complete, I mean using it for actual projects rather than just fiddling with tools and Project Euler style problems.
I am the author of IronScheme. I am not really sure how to answer your question, but will try :)
IronScheme firstly tries to implement Scheme (R6RS specifically), with the secondary objective being CLR interoperability.
Compared to Clojure (focusing on the their bad points), IronScheme won't:
- give you CLR runtime exceptions; IronScheme uses Scheme's exception handling
- give you 'infinite' stacktraces; IronScheme is properly tail recursive
- be hard to setup; just extract to directory and go
- take long to start up; IronScheme (when ngen'd) only takes 0.1 seconds to start the REPL
- be ambiguous; IronScheme implements a standardized specification
Unfortunately where Clojure wins is:
- Frameworks and libraries
- User community
This is worrying for IronScheme, as the last 3 mentioned is very much a chicken-egg scenario. Personally, I tend to only create libraries when I need them, and with a very tiny user community, there is not much contribution from users besides bug reports. I would love a bigger user community.
As for support, I normally help users as fast I can. This evidence can be seen from my response times on the IronScheme discussion boards. Also, bugs are normally fixed as soon as they have been identified.
As for stability, the codebase is pretty mature, and currently only bug fixes and optimizations are the only code additions.
As for usability, if you are familiar with the .NET framework, you can do pretty much anything with IronScheme as you can with any other .NET language; it may be harder or easier depending on how much you are willing to abstract into more Scheme-like idioms. Things are very easy to write in IronScheme; for example my entire MVC framework is barely 400 lines of Scheme code, thanks to tapping into ASP.NET (I certainly do not like re-inventing the wheel).
Feel free to ask for clarifications if the answer is not enough. Demian does make good points in terms of maintainability too.
Note: I don't have experience with IronScheme, so take my thoughts with a grain of salt (although it's directed more at using bleeding edge technology).
While I'll toy with new technology with trivial problems (personal tools, Project Euler, etc), I'm very wary of employing said technology in full blown projects. Why?
- Community support: Who will you get assistance from when you hit a wall?
- Unforeseen issues: If the technology hasn't been thoroughly battle tested, do I really want to dig into the library code to try and figure out a solution to a problem that may not have been encountered? If I wanted to be a part of the commit team, then perhaps, but 99% of the time I just want to get my project done and not have to worry about the plumbing.
- Team commitment: What happens if whoever's heading up the project pulls the plug? My projects are then orphaned, unless I want to take over the project, to which I have the same issues as the previous point.
So, while learning new tech is always a good thing (the worst thing that can happen is that you learn how someone else would implement something - which is good), it can really bit you in the arse if you adopt it early for full projects.