Brian has posted a pretty exhaustive list of .NET compilers for various languages.
Thanks! The thing I find most fascinating about this list is that you can write something in one language and call it from another. At first this might not seem that useful, but consider Andrew's case.
I have to say, translating a simple routine (below) into C#'s form of regular expressions is REALLY freaking painful. I have to say, when it comes to pure text manipulation, I've yet to find a language that does it as efficiently as PERL. What would be a nice feature in C# (sick...yes, truly sick) is if you could "perl-manage" code when needed. Meaning if I could just write a regex routine like this one, life would be good.
The point being, that's exactly what you can do - assuming of course that the RegEx itself is supported (I'm not terribly familiar with the hard-core RegEx capabilities of .NET vs. Perl, I usually just stick the basics!). I promised Andrew a few months back that I was going to show him that this could be done, but, of course, I still haven't gotten around to it - I will, someday...
The point being, though, that each of these languages just becomes syntactic sugar over MSIL. As Sam so eloquently pointed out in the past, the runtime (and the MSIL that runs on it) is really what's important. So you can just wrap up that routine in a .NET assembly written in Perl and call it from C#. At the end of the day, it's all just MSIL calling other MSIL.
That's pretty neat. It can really be a big bonus in the "developer productivity" department. Write code in the language that it is easiest to express the logic that you want to convey, and let the compiler do the rest of the work.
Not to mention it effectively renders the language debate moot from a capability perspective.
Brian, on a side note, I found it quite curious that you lumped Java/Javascript together. Any particular reason for that? I hope everyone realizes that these are in fact completely different things? :)