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?
"
Since many probably won't read past the first page, look at this link which describes in detail Mercury on the .NET framework. It's not bad.
Another good example, as covered in Dr. Dobbs last issue, is Mondrian. You can read a paper about it here(it's a PDF). You can download the compiler and view documentation at the mondria-script web-site.
.NET Framework.
Here's a blurb from Dr. Dobbs:
Mondrian is a modern, purely functional language specifically designed to leverage the possibilities of the
/* CDM */
The problem hasn't been that you can't implement some functional languages with CLR and ILR. The problem is that to implement a particular functional language (scheme and common lisp spring to mind) you've had to drop some functionality (in fact, do a partial implementation). Will this be addressed? Who knows? I note that the first passes at Python.NET and Perl.NET ran into the same sorts of problems and ended up with a comprimise of integrating with the .NET stuff but not an implementation under .NET.
For example, scheme is hard to compile towards the JVM or standard C because both lack proper tail call implementation (poping the parameters in the stack before calling a function in tail position).
You can of course circumvent this because as you say the target language is Turing complete, but you lose a lot on performance if the target isn't tailored to this particular use.
Relinquish
I can't speak to application development on .NET, but I can say for web apps that ASP.NET is very fast, particularly in comparison to "interpreted" approaches like ASP 3. The improvements in organization are fantastic as well. Nearly everything we've had to implement an embarrassing hack for on ASP has been replaced by a clean, well-thought out bit of code.
That said, initial compiles of ASP.NET pages are sorta slow, about 5-10 seconds per page on the first run-through, but after that the only bottlenecks seems to be at the DB.
As long as the language is Turing-complete, it should be possible; the question is in the level of difficulty
No physically implementable computer system is Turing-complete, as a Turing machine has an unbounded storage tape. Even C on a 64-bit architecture isn't, as it limits you to only a few exabytes of memory.
Will I retire or break 10K?
> As far as I understand the issue is a performance one.
.NET) are designed primarily for object oriented langages having long(er) lived objects with identity and storage.
.NET.
Yes, the problems seem similar to the attempts to compile functional languages (e.g. Haskell or ML) to the JVM.
Functional languages have a lot of very short lived objects (functions that are evaluated) without identity and local storage.
The JVM (and
It's this mismatch that makes it hard to use functional languages *efficiently* with
Anywat, I really love to see the people at MS addressing this problem. But after all, GHC, *the* Haskell compiler is being developed at MS research.
I took a look around and found this link to a guy called Don Syme at Microsoft Research who appears to be working on just this.
There's also the Mondrian project, which implements Haskell.
I recall an interesting commentary on this very topic by a Lisp Developer at Franz:
& th=b55cb0947065a389&seekm=48zh6nn1q.fsf%40beta.fra nz.com#link2
.NET platform? Seems to me
.NET is a wide-open side-door for Lisp to enter into IS
.NET is a framework in which
.NET's.
.NET will be /
See http://groups.google.com/groups?hl=en&frame=right
Obviously, the vendor may have reconsidered their point of view. (I have no association with this company)
Excerpt:
"
rcena@epcor.ca (Resty Cena) writes:
> Is anybody working on a Lisp port to the
> that Microsoft
> shops.
We at Franz looked at it, and rejected it. The major reasons for
us deciding not to proceed were
1. It would slow our lisp down tremendously. I don't rememeber the
exact estimates, but I would guess and wouldn't be surprised if
the slowdown would have been on the order of 10x.
2. More than a hardware emulation, where the "hardware" provides
primitive functionality and we language vendors are able to use
this functionality however we see fit,
software is constrained to conform. Thus, we would have to change
our calling sequence, object, typing, and gc architectures to
conform to
3. The result would be MS specific, and not portable to other systems.
This point is weak, because it is conceivable that
is being ported to other operating systems, but at the time we
looked at it, it had no buy-in from any other operating-system
vendors.
Anything one could do in native assembler, one could do in IL or JBC.
Not if the language doesn't support constant-space tail calls, which are the primary method of iteration in the Scheme programming language, and which can be implemented with a jmp (or whatever it's called) in any silicon CPU's assembly language. I've read that Java bytecode doesn't support it, but Microsoft added a tailcall instruction to MSIL at the request of compiler developers.
The Java platform's VM and the CLR both require code to be type-safe. How does this mesh with the dynamic typing (in .NET framework terms, everything inherits from System.Object and all variables are of type System.Object) that some functional languages use?
Will I retire or break 10K?
Anything one could do in native assembler, one could do in IL or JBC.
Incorrect. Java byte code doesn't allow many things that you can do in assembler, for example read from a memory address, call a function in memory (basicly anything to do with memory pointers). These restrictions make it hard to generate effecient byte code for languages like C and Lisp.
Part of Java's slowness in initializing is that it does extensive security oriented bytecode verification of every class loaded. If .NET doesn't do that, it will be faster, but arguably not as secure against people rearranging the CLR bytecodes in ways that a compiler conforming to the security spec wouldn't. BTW: You can disable this as a command line option to your JVM and speed things up if you trust your .class files, but the default is to be secure.
There are more applications than you may
think.
http://www.franz.com/success/
Here, I included a few of them....
Pro/ENGINEER
Ascent Technology, Inc.
Application: ARIS
PricewaterhouseCoopers
Application: Comet and Planet
NASA
Application: Mars Pathfinder Mission's Planning System
Space Telescope Institute
Application: Spike: Hubble Telescope Scheduling System
Square USA Inc.
Application: Phantom
Here is an interesting article to you who think your .NET http://www.javalobby.org/clr.html
language will get the same level of support under
Here is a link to an introduction to Moscow SML implementation, which has alot of good beginner info. And here is a link to SML .NET info, which is what you'll need to use to code SML apps for windows.
I did some some simple tests on this the other day out of pure curiosity. I don't expect the numbers to tell the whole picture by any means but it is enough for one to want to investigate further. I simply created a small console based app that checks to see if a number is a prime or not for 80000 numbers. I wrote the code in java, C# and C. Anyway, here are the results I found:
Java (IBM 1.3) 4496 ms
C 4716 ms
C# 8582 ms
Could it be? Are there some positive posts regarding a Microsoft technology on Slashdot?
.NET has to offer, but from a performance and price standpoint it certainly has a lot to offer. If Microsoft can tighten up their security and keep the price and performance where they are ... they look to have a very formidable product.
I've just started to scratch the surface of what
If that's your worry, then it is justified. There was an interview on MSDN (The .NET show) with the program manager of the CLR group (I don't remember his name) and he said the one thing that you couldn't do in the CLR was continuations. He especially lamented this because Scheme was his favorite language.
A friend of mine worked at one of these consulting companies, and their salaries were actually pretty decent. Of course, an anecdote doesn't prove anything, but suff"ice it to say, I am sceptical. However, I think the H1B visas should require a minimum salary.
This is going to show my redneck heritage, but I believe this - we can't afford to have a bunch of non-citizens in the USA stealing jobs from citizens by undercutting us in every way.
Well that's too bad, because the alternative is to have a bunch of non-citizens out of the USA stealing jobs from citizens by "undercutting" you.
What we have with the H1Bs is the recipe to economic collapse, rapid inflation, etc.
There's little in the way of evidence to support this claim. I would argue that on the contrary, isolationist policies are a sure recipe to doom. The problem is that there is change due to the unsustainable situation where people in India have much lower salaries than their American counterparts. Because of this, it's in the interests of companies to prefer the Indians, and fire the Americans since they're cheaper. A lot of people are getting burned by the transition (this always happens when economies undergo any type of transition) The key is to put the brakes on the transition so that no-one gets burned more than necessary.
Just look at the early 20th century immigration boom. That eventually led to the great depression, which led to WWII.
Post hoc ergo propter hoc. Lots of things led to the great depression (ponzi schemes, a poorly regulated stock exchange, and an unsustainable boom), and lots of things led to WWII (namely, Germanys hardship had a lot to do with the "victors justice" at the end of WWI