Functional Languages Under .NET/CLR

Numen writes "With all the talk of .NET being thrown about there is a common factor occuring through many discussions, namely the claim that .NET will be unable to address functional and logic languages such as Prolog and LISP. To this end I would like to drawn peoples' attention to two resources, that shown how this may well be a non-issue, and to ask, does this change anybodies mind? "

Comments

Re:GNOME and .NET change of heart

[Masem]

I think the idea of .NET is good too, but realistically, we already saw it for Java.

I wonder where we would be if Microsoft had enbraced (but not extended) Java, such that both Sun and MS had meanful discussions on how to expand it and yet keep the promise of "Write Once, Run Everywhere" (ie, no MS-specific extensions, and so forth). The idea that any vendor could release code that would run on 100% of the computers out there, not just 95%, would be a godsend.

While .NET, and efforts by Miguel and Ximian to create Mono, and probably similar efforts inhouse at Apple, appear to offer the same promise, I still expect that we'll see a lot of Windows-specific hooks that would prevent a good chunk of code of being cross compatible. Not that one can't write fully compatiable .NET code that runs everywhere, but I would not be surprised if MS offered programming goodies (cool widgets, eyecandy features, etc) that would be easily be limited to Winboxen and leave other implimentations of the virtual machine out in the cold.

it really doesn't matter

[markj02]

You can compile both strict and lazy functional languages to CLR and JVM (there really isn't much of a difference between the two; even TRO can be dealt with reasonably well in the JVM). But don't expect miracles: the resulting code and performance will be usable but fairly mediocre.

Why? One major advantage of functional programming languages for optimization is that the compiler knows that almost nothing can change behind its back: variables can't get updated, data structures can't get changed, etc. With VLIW architectures like Itanium and hyperthreading, functional programming languages can potentially do much better relative to traditional languages than on older processors. But in order to so so, their compilers need a degree of control over code generation that simply isn't available if you go through CLR or JVM.

Furthermore, the entire runtime of a functional language is optimized for the kinds of allocation patterns that come along with functional programming, while CLR and JVM are optimized for OOP. For lazy functional languages, there are some additional issues when it comes to expressing lazy evaluation efficiently.

Altogether, though, I think it really doesn't matter. CLR and JVM are good and fairly flexible platforms, but platform evolution won't stop here. If anything, Sun is a bit more honest in this regard, making no bones about the fact that JVM is primarily a Java platform, even though there are dozens of other language frontends available for it; CLR claims universality, but really isn't any better than JVM.

If you don't care that much about performance, you can use your functional language under CLR and JVM. If you want a high-performance functional programming language, you can use one of the dedicated native code compilers and runtimes that will continue to be available. CLR and JVM will not end the evolution of other runtimes.

Re:GNOME and .NET change of heart

[rabtech]

What do you mean about "windows-only" hooks???

I am constantly amazed at the complete LACK of understanding about what .NET is. Let me set the record straight: the functionality... the "API"... of .NET is contained in the core class libraries. Those are PUBLICLY AVAILABLE INTERFACES. There is nowhere to "HIDE" windows-only hooks. If you can have your MONO class library take CallX with four arguments of int just like the MS Windows version of the class, then you have CROSS PLATFORM capability. If Microsoft changes the class interface, then you change your corresponding class interface.

Honestly! It's all Object Oriented; there is NOWHERE to hide anything from anyone! Implementation is another issue, but by virtue of the platform itself all the interfaces have to be public and accessible, which means they can be easily emulated. That's what mono is trying to do with WindowsForms; its the GUI component that Microsoft said was going to be Windows-only, except they are already working on emulating the public interfaces (though the implementation would be calling gtk/x)

Please... THINK about this stuff before you post it. Its no like Sun can go and hide some new solaris-only hooks in the JVM that suddenly make it incompatible with other platforms! In order to have developers use the new hooks, they have to make them public, and then anyone could create a compatible class for their platform of choice.