Languages with a native CLR compiler
Bridges between the CLR and other language runtime systems
Whatever happened to Jscript.Net mentioned in http://msdn.microsoft.com/library/default.asp?URL=/library/en-us/dnclinic/html/scripting07142000.asp ? Did it die and become AspDotNet? --dl
Asp (both the old incarnations, and the current AspDotNet) is and always has been a framework usable by many languages, not a language itself. The JayScriptDotNet? compiler is still a standard part of the DotNet SDK, afaik, although i don't know how much use it gets... (i always got the impression that jscript, (in the context of ASP, anyway), appealed mostly to people who just didn't get along with vbscript, for whatever reason, and i suspect most of those people will have happily made the jump to C#...) --mr
The "Scheme" system mentioned above doesn't handle full call/cc and neither full tail call optimization. It's doubtful if that can be called Scheme; at most, is is something with syntactic resemblance to Scheme. (Scheme#, or whatever.)
About the large choice of languages, is there anyone in the .NET world who is doing (or plans to do soon) actual paid commercial development for .NET in any language other than C#, C++ or VB? This isn't a veiled knock, I'd really like to know if there's a chance of using .NET to break the sorta-OO-but-really-procedural language strangle hold on mainstream commercial development. -- KeithBraithwaite
VisualJaySharpDotNet may be popular as a way for Java developers to develop for .NET. (But only time will tell.) I agree that it is unlikely that languages other than C# and VB will be widely used. But, one semi-cool feature of .NET is that it provides classes for generating .NET code from syntax trees, so if there is some language you want to implement for .NET, you really just need to develop a compiler front-end. -- KrisJohnson
What I find interesting about the wide variety of languages targeting the .net framework is the possibility that the language itself could become an element in the refactoring of code. If at least a few of these actually show up and actually work, it wouldn't be necessary to build an entire application in a single language. The language whose syntax and compiler worked best for a particular problem could be used for that problem. Command objects for text parsing could be written in one of the several languages that supply elegant syntax for that task. A different and more appropriate language could be used for financial or statistical calculations. Will it happen? Possible. At least it gives some "interesting" special purpose languages a new chance to be noticed.
This can already be done to a certain extent with Microsoft's languages. CeeSharp, VbDotNet, and Java aren't very different in terms of expressiveness, but mixing in JscriptDotNet allows use of its RegularExpression syntax, associative arrays, late binding, and prototype-based features. One could consider AspDotNet to be a special-purpose language for developing web pages.
That's a good point. JscriptDotNet is probably the most unique of the languages currently available for the platform. RegularExpressions are actually available from any DotNet language via the framework's base Regex class library, but the implementation of the library in JScript allows for simpler and more fluid access to the library. (JScript also uses a slightly different syntax for its regular expressions.) But the late-binding features and other loose, and somewhat wild constructs, of JScript (like its "expando" objects) are difficult to match. Some would say that's a fortunate thing since one pays for such freedom with bloated and highly inefficient compiled code, but there are times when that doesn't matter. JscriptDotNet even comes close to matching the freedom and agility of Stem variables in the RexxLanguage. Almost.
What about MicrosoftXen? Is it likely to be commercialised while the current batch of programmers are still employed?
well, it's not being commecialised just yet, but you can download a preview of it's mutant offspring [CeeOmega] (Xen/X# combined with PolyphonicCeeSharp), and there have been suggestions some of the ideas from it may be rolled into the mainline C# language at some point (probably version 3, which will probably appear some time around 2008, assuming it takes them the same time from 2.0->3.0 as it has from 1.0->2.0)