Slashdot Mirror
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?
"
What basis for thinking this would anybody have?
.NET would be harder to support than, say, TCP/IP or HTTP. I mean, Emacs was written in LISP; if they can do that, is .NET such a challenge?
As long as the language is Turing-complete, it should be possible; the question is in the level of difficulty, and I don't see why
Perhaps I've misunderstood the claim; in that case, perhaps it would've been useful for the poster to include a link detailing the rationale behind the claim that functional languages wouldn't work.
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.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
The SML.NET compiler hasn't yet been released by Microsoft Research but hopefully it will be soon. As I understand it, it is a complete implementation of Standard ML, with a few (small) extensions to hook into the .NET object model.
In my opinion, this could be one of the best opportunities functional programming has to gain mainstream acceptance, because of the ease with which it will be possible to link functional code with imperative code.
.NET is just another one of Microsoft's over-engineered solutions. It looks simple on the outside, but when you get down to it the complexity is overwhelming. It's really sad to see so many open source developers being lulled by Microsoft's latest technological tactic.
.NET well!
Who out there remembers DDE, OLE, MAPI or DocObjects? How about MFC (.NET 0.5...)? If you do, remember how well (not very!) these "technologies" worked outside of the boxes Microsoft created them for? Has anyone out there actually tried to work with, for example, Exchange server?
Microsoft fears clonability, and to prevent it they create complex APIs with lots of hidden underspecifications. Then they get developers on board by creating pretty, easy-to-use tools and hosting big developer conferences. And they make it feel cool through shrewd marketing. But at the end of the day, you find that you've spent 90% of your time trying to work around some deficiency. And it's not because Microsoft was especially dumb when implementing this stuff, its just that the stuff is needlessly complex to begin with!
We're doing fine as we are. Don't drink from the
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.
To take one example, in Lisp you can pass nameless functions quite easily. So you might have a library that has a function to create a new button. One of the arguments to the function is a function that the library will execute when the button is pressed. In Lisp this is a trivial thing, you just create a function and pass it as the argument. But if nameless functions are not supported by the virtual machine, then this operation becomes very problematic.
What if the nameless function is created dynamically by the program? How can the virtual machine compile this nameless function to native code before running the program? Unless the virtual machine knows how to compile Lisp code, it cannot. It may be that the Lisp library must be changed to accept some other form of argument for the callback for efficiency reasons. If most of the work you do is just calling libraries and putting things together, you just lost one of the biggest features of Lisp. You have to trade off efficiency and convenience. If you use a native Lisp virtual machine, you have both efficiency and convenience.
I'm actually excited about the .NET framework (well, the CLR) because it will mean I can use my favorite functional language, SML, to write Windows apps.
It's also from MSR: http://research.microsoft.com/Projects/SML.NET/
Why do we care? In a really old thread I rant about the virtues of modern functional languages (and indirectly, SML). I think it's still relevant, though most of the other languages associated with .NET (ie, C#) have some of the same basic benefits now (like safety and portability). Here:
http://slashdot.org/comments.pl?sid=6343&threshold =1&commentsort=0&mode=thread&cid=929697
If you want to learn SML, or learn why I think it is so cool, maybe you'd like my under-construction tutorial called SML for Hackers: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tom 7misc/docs/sml/ml-for-hackers.txt?rev=1.3&content- type=text/vnd.viewcvs-markup
The CLR is based on the concepts of classes and single-dispatch, calling methods that "belong" to a class. Lisp's CLOS is built on multiple dispatch, and can cleanly support prototype object systems. It's hard to retrofit these capabilities onto a class and single-dispatch system, but it's easy to go the other way. Emulating multiple dispatch without the ability to re-compile on the fly leads to slow code.
And, socially, many Lispers see Java, .NET, etc. as
shallow attempts to mimic what they've had for over
a decade: A portable, reflective, dynamic environment.
Java and many of the .NET languages leave out key
portions of Lisp. Lisp allows programmers to
control how the code is
read,
translated, and then
compiled without leaving
the language. You can build infix Lisp
in Lisp, with all the tools of Lisp at your
disposal. Or you can eschew many of
the tools in Lisp, all from Lisp.
Look at it this way: if .NET is all MS says it will be then they will be opening themselves up to more and more competition; they will be creating a freer market for code than exists today. Surely no one here is so stupid as to imagine that's what MS wants?
.NET will launch with as much support as the marketing department can get for it and then it will slowly morph.
Each year will see a new version with more API calls etc defined and, you know what? Just after that all the MS programs that have been written using the beta versions of those API's will come out, well in advance of even the poor dupes that fork out for MSDN.
Everyone apart from MS will be playing catch-up again.
How many fucking times do you have to be done over before you learn???
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
What do you mean about "windows-only" hooks???
.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.
I am constantly amazed at the complete LACK of understanding about what
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.
Natural != (nontoxic || beneficial)
I agree that users of non-OO/imperative languages will be forced to accept a lower common denominator if they employ .Net framework classes, but I predict that the benefits will outweigh the loses. Most exotic language features go unused for good and bad reasons, and as processor speed increases and memory cheapens, framework portability and coder productivity will outstrip the benefits of relying on the exotic features.
"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)."
I wonder where we would be if Microsoft had just ignored Java. Despite all the complaints about extending Java, I think MS's adoption of it made it much more widely accepted than it otherwise would have been. In that case Java would not be evidence in the antitrust suit, and the possibility of the court ordering MS to ship with Java would be even more remote than it is today.
I tried the same test:
.net 1.0)
is x prime ? x < 1000000
java 43,421 sec
c# 24,769 sec
(java 1.3.1,
(win2000, XP1800+)
class Prim
{
// c# static void Main (string [] args)
// java static void main (String [] args)
{
for (long a = 2; a < 1000000; a++)
{
// c# bool prim = true;
// java boolean prim = true;
// c# for (long b = (int)System.Math.Sqrt(a); b > 1; b--)
// java for (long b = (int)Math.sqrt(a); b > 1; b--)
if ((a % b) == 0) { prim = false; break; }
// c# if (prim) System.Console.WriteLine(a);
// java if (prim) System.out.println(a);
}
}
}