« Things I did not know, number 8073 | Main | I am kindling. Hear me roar »
April 12, 2009
Building Clojure for the CLR
David Miller has announced a port of Clojure, the Lisp dialect for the JVM that’s getting a lot of buzz, to the .NET CLR. Sources are up at the clojure-contrib site.
It’s pretty easy to get it building and running but if you’re using a recent version of the DLR (I was on 21259) then you’ll probably need to make a couple of minor changes:
- ClojureCLR tries to new up ScriptCode in a few places. ScriptCode is now an abstract class, so this causes compiler errors. Changing ScriptCode to LegacyScriptCode seems to fix the problem. (It probably isn’t the right solution, but it’s enough to get things up and running.)
- If you try to use a .NET API call in the REPL, e.g. (Math/Pow 3 4), you get a runtime error of type ArgumentException complaining about a type error in the printToConsole method. To work around this, go into Generator.cs (in the Compiler folder), find the Generate(object, bool) method, locate the if (addPrint) body, and add the line finalExpr = Expression.Convert(finalExpr, typeof(object)); at the top of the body of the if-statement. Again, not sure if this is the right thing to do, but it gets the API calls working.
April 12, 2009 in Software | Permalink
TrackBack
TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d8341c5c9b53ef01157014afa8970b
Listed below are links to weblogs that reference Building Clojure for the CLR:
Comments
So, tell me Earthman, would you use one of these fine languages for a bit of real live software where in 5 years time you didn't want to have to rewrite or get it working with .NET version 666 once the buzz-badgers have moved on? (I do think DLR is a slightly unfortunate name as in Docklands Light Railway, i.e. something that was built with undercapacity and has therefore been under more or less permanent upgrade programmes ever since, and slows down and squeaks when it goes round corners, and something completely different had to be built to provide sufficient speed and capacity when a decent number of users came along etc. etc. - do I hear the albatross of leaden metaphor?)
Posted by: Harvey Pengwyn at Apr 12, 2009 11:04:41 PM
Not at this stage. If they ever reach the level of maturity and backing that the JVM implementations do, maybe, if I had a project that was actually going to realise their benefits. (E.g. I'd use F#, or a mature Scala.NET, over C# if I had a project that needed to do parsing.) But I find them interesting all the same.
In related news, I'm also interested in category theory, theoretical physics and the history and culture of classical Greece, even though I'm unlikely ever to use them on real life projects...
Posted by: Ivan at Apr 13, 2009 7:58:53 AM
I didn't mean to imply you shouldn't find them interesting, or shouldn't talk about them, I was interested in the question.
'A mature Scala.NET', aye, there's the rub.
As I may have said before, one of the greatest quotes of all time on some forum about Ruby on Rails was (in about February of whatever year it was)
OP: 'It looks interesting but I worry about the maintainability of things written in it'
Commenter: 'Oh, I've been using it since November and the maintainability's fine'.
Ah, bless.
I do wonder about the maintainability of Java stuff, ever year or so when I find myself reading something about Java, there seems to be a new GUI framework, new web framework, new project building framework etc. etc.
Posted by: Harvey Pengwyn at Apr 13, 2009 9:47:37 AM
The level of churn in our industry is a difficult issue. On the one hand, we know from experience that we are building for the ages (well, potentially for decades depending on the nature of what we're building), and therefore we want to be confident that whatever we're using will still be around for some time into the future. .NET and Java *will* one day go the way of COM and MFC. But on the other hand, it seems crazy to give up the increases in productivity, expressiveness and capability of the latest and greatest languages and frameworks.
Clearly there is a sweet spot (or at any rate a least sour spot) but where that will be depends on the project, the people involved, the nature and backing of the language/framework, etc. In 2002 adopting .NET was a calculated risk. Now the risk has largely evaporated leaving only the technical considerations. Ten years ago Ruby was a curio. Now it's a language and platform you can trust your Web site to, knowing that even as fashions move on (and RoR is already beginning to lose its lustre), the community and industry has become sufficiently dependent on it that you won't be stuck out on your own. Scala (on the JVM) is beginning to reach that point -- I hesitate to use Twitter as an example of anything permanent, but their move to Scala suggests that it is ready for the real world. Same with frameworks. Would you build a real app on Windows Presentation Foundation? Two years ago I probably wouldn't. Now I probably would (depending of course on circumstances). ASP.NET MVC? The company I work for has built several sites on that, even in its beta version, and I don't think we're alone, because it hit the sweet spot very early in its lifecycle (for a variety of reasons which this comment box is too small to contain). On the other hand, pity anyone who jumped keenly onto VB6 features like Web classes only to see them vanish like the neiges d'antan.
Distinguishing fashion and experimentation from useful, sustainable steps forward is, I fear, one of those skills we just have to acquire. And some fads and experiments can teach us something useful, or just randomly interesting, as they go by, even if one can't safely buy into the whole package.
Posted by: Ivan at Apr 13, 2009 10:26:35 AM
I don't think that MFC can 'go away', I think too much shrink-wrapped software is written in it, there are some big companies that Microsoft would't want to piss off or worse still drive into the arms of something cross-platform. I do think that Microsoft are subtly side-lining it, however.
I suspect we will be for a world of pain with the build system in VS 2010, though.
I claim foresight in having chosen Ruby as our software's scripting language before it became popular, though I find Ruby mailing lists / blogs / etc. rather scary. It all reminds me far more of fandom than anything remotely approaching engineering. But I am probably an old fart failing to grok the fullness. (Actually, I don't believe that I am).
To a large extent I think the changes in language / framework popularity reflects changes in the industry. I do think that companies like mine doing large vertical market shrink wrapped apps (millions of lines of code, hundreds of person years of development, some code over 20 years old) are being squeezed out, and the future is a few really big apps and lots of smallish ones. This is the 'car' model to some extent i.e. a few multi-billion dollar manufacturers and millions of Honest Joe's Auto Repair. Personally I think this is sad, but there you go.
Posted by: Harvey Pengwyn at Apr 13, 2009 8:46:50 PM
Oh, agreed, MFC is not "going away" any more than COM or Win32... or CICS or Cobol. But MFC's continued existence is assured by the mass of existing code, not by any continuing adoption or investment. If you had to choose a development technology today, MFC might be a safe choice in the sense that it's not "going away" -- the same would be true of C and Win32 -- but it would almost certainly be a bad choice *if you were choosing a language / platform / framework today* in that (a) it would cut you off from present and future Windows platform enhancements, (b) the tradeoffs that MFC was optimised for are no longer the most important ones (in particular manual memory management and low-level window management no longer look like good uses of developer time) and (c) the adoption risk of technologies which address (a) and (b), such as Java or .NET, is no longer any greater than the adoption risk of MFC.
This is not to pick on MFC. The same comments, mutatis mutandis, apply to COM, or Win32, or C, or Fortran. Nothing in our industry goes away, except VB6 Web classes and buffer overrun attacks. But things do diminish and go into the West: all I meant was that MFC and COM have sailed, and .NET and Java will follow in their time.
Posted by: Ivan at Apr 14, 2009 9:07:18 PM
Well, there is the question. If one were starting our fine software now what would one use?
Answer, in the manner of Heracleitus, a penguin cannot develop the same software twice. Would I want to write our computational geometry library in Java / .NET, or would one be adding Java / .NET to our foetid mix of C++ and Fortran 9x (or 0x or whatever we're on by now, I forget)?
Posted by: Harvey Pengwyn at Apr 14, 2009 10:54:37 PM
"I do wonder about the maintainability of Java stuff,"
Unfair. Java code I wrote in 1997 that still runs just fine in the latest JDK. Sun has introduced language features that were not 100% backwards compatible - it happened in JDK 1.4 and broke (if I recall correctly) 5 lines in their 4-million line standard libraries.
There was a brief period when many open-source java libraries depended on Xerces and Xalan, and versions of the Xs were not backwards compatible, so moving forward was hard. But now that Xerces and Xalan are part of the language standard libraries they too are remaining extremely backwards-compatible.
There are problems with Java. But in general being stuck with something that no longer compiles or works a few years down the track is not one of those problems.
Posted by: meno at Apr 18, 2009 9:48:46 PM
I don't think he's talking about whether "Java stuff" will "no longer [compile] or [work]" due to language or library changes. I think his point is more about how things pop up and die. Suppose someone had written a big UI using AWT? (Unlikely I admit *grin*.) I'm sure it would still compile and run, but they'd be pretty much on their own in terms of supporting and maintaining it. If someone bets on JavaFX today, how do they know they're not going to be left high and dry tomorrow? Are Ant users going to find themselves in a dead end as all the cool kids go to work on Maven? (At least that's my interpretation of the comment.)
You're right that to call Java out for this is unfair. All languages and platforms have this issue: e.g. Microsoft data access technologies seem to arrive at the rate of one every twenty minutes (the old ones still *work*, but good luck getting fixes, drivers, community or vendor support, etc. for them), and in the .NET world it's not yet clear which IoC/DI frameworks are going to be safe bets long term.
Posted by: Ivan at Apr 19, 2009 7:47:20 AM