18

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.

lennon310
  • 3,132
  • 6
  • 16
  • 33

2 Answers2

26

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:

  • Documentation
  • 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.

Regards

leppie

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
leppie
  • 716
  • 4
  • 7
  • 1
    How does IronScheme + Net compare to, say, Racket, wrt frameworks and libraries? – Joe Internet Sep 11 '11 at 13:24
  • I didn't realize that there was an MVC framework available. Is that part of the IronScheme download? – Robert Harvey Sep 11 '11 at 15:38
  • 1
    @Robert Harvey: Yes, some sample code is in the websample directory. Currently also running on http://ironscheme.net/doc and http://eval.ironscheme.net – leppie Sep 11 '11 at 18:31
  • @Joe Internet: No frameworks really, but IronScheme includes a lot of SRFI's. Most of the libraries I have written is for CLR interop. – leppie Sep 11 '11 at 18:35
2

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.

Demian Brecht
  • 17,555
  • 1
  • 47
  • 81
  • 3
    Although you have a point, I wonder how you expect new technologies to become battle tested, if your advice is not to rely on them in battle? ;) – back2dos Sep 11 '11 at 10:17
  • 1
    You're right, it is somewhat a catch 22 situation. I'm simply speaking from my own experience and preference. I'd rather concentrate on getting things completed rather than potentially dealing with plumbing or discontinued libraries. Obviously *someone* has to do it.. I'd just rather not do it on my projects :) – Demian Brecht Sep 12 '11 at 00:43