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

What about speed?

[tal197]

Does anyone know how .NET does for speed?
ie, Java takes an absolute age to initialise which makes it unsuitable for desktop applications or utilities (although people still try... maybe in a few years' time...).

Does .NET introduce an even bigger overhead, or have they sorted it out?

Also, is there any overhead for languages that aleady use a VM (eg, python, perl) if they switch to .NET instead? Will the tailor-made version be more efficient because it's designed with the language in mind, or does the benefit of having all the optimisations done on a common system compensate for that?

I really like the idea of a common cross-platform runtime, but not if it makes my text editor take 5 seconds to load!

Re:What about speed?

[Rentar]

.NET has beend designed more for speed, than for platform independence (but it should, at least in theory, be platform independent nevertheless.) .NET is ment to be Compiled to native code, instead of beeing intepreted (like a JIT with Java does, although current HotSpot technology is a bit more complex than this), but it is not compiled every time it is run, but during install-time. So you should get almost no loss in startup-speed and execution speed.

Disclaimer: my position on .NET is similar to Miguels. I don't like what MS is doing, but like the .NET framework from a technical point of view.

Re:What about speed?

[NulDevice]

I've been playing with .NET apps - simple ASP.NET ones, so far - on my PIII 500 laptop. I can field a little of your question...

Okay, running IIS5, WIn2000, Visual STudio .NET and the app all at the same time - the first time an ASP.NET app runs it takes an absolute age - but it's compiling, much like a JSP-Servlet compile.

After that it's surprisingly zippy, considering how I'm abusing this poor laptop at the same time with a gazillion other apps. It's much faster, at any rate, than old-fashioned ASP.

There's some anecdotal evidence for you. I haven't hit it with VeloMeter or anything so I haven't seen how well it scales yet.

I'm thinking the real big primary advantage of .NET is with strong typing and a fairly rigorous object model, it's going to force a lot of hack VB programmers to get their sh!t together and start writing code that doens't look like the top-down crap I wrote in Apple Basic in 4th grade. Wow, maintainable code, what a concept.

Re:What about speed?

[egomaniac]

A JIT does not interpret Java. Ever. Under any circumstances.

JIT is short for Just In Time *Compiler*. A JIT compiles Java bytecode to native code prior to running it. It is in fact this compilation which lead to the slow startup time visible under Java 1.1 and 1.2 (without HotSpot), because the JIT could not interpret code. It had to compile *everything*, even if it was just initialization code which would only run once.

HotSpot, the next generation of VM technology which is integral to Java 1.3 and 1.4, features an interpreter which is used initially. This gives HotSpot very fast startup time, because it initially does no compilation. As HotSpot decides that a particular method needs to be compiled, it does so in a background thread while continuing to run the interpreter. When the compilation is finished, it swaps in the native version (the current version can do this even if it is in the middle of running the interpreted version). This gives HotSpot two big speedups: firstly, because it uses the interpreter initially, startup is faster, and secondly because it compiles fewer methods (IOW, only ones which actually benefit from compilation) it can spend more time optimizing each method.

HotSpot beats Visual C++ in most benchmarks. It is damned cool technology, and most people that claim Java is slow haven't played around with it in a long time. Java 1.4 is ripping fast.

IL, like Java Byte Code, is simply assembler

[xacto]

Let me ask you all a question: If any language that you currently use is compiled into native machine code (for x86, or PPC, etc.), then why wouldn't .NET or the JVM support it?

You have to remember that both IL and JBC (Java Byte Code) are essentially virtual CPUs that have some high-level features tacked on to simplify implementing certain kinds of langauges. However, they are still just basic assembly like langauges. Anything one could do in native assembler, one could do in IL or JBC. In fact, not trying to support one or the other, IL is probably a slightly better candidate here because Microsoft uses it to compile to native x86 assembler. Hence, there is support for direct memory manipulate (something the JBC doesn't have).

So, can someone implement Lisp using IL? Why not? They did it with C or assembler before. Can someone implement Smalltalk? David Simmons already has at http://www.smallscript.com.

I applaud Miguel for trying to bridge the gap between the Windows and *nix world in innovative ways. Good luck!

Re:IL, like Java Byte Code, is simply assembler

[JohnsonJohnson]

The problem is not whether a compiler/interpreter for any language can use teh VM as the targeted back end. The problem is whether Microsoft's claim of language interoperability is true. So far the answer seems to be no. One can use all of their favourite languages features on a .NET compiler/interpreter but they cannot export any interfaces that may rely on some of those features: dynamic typing, closures, unsigned types etc. So what happens is Microsoft ends up effectively promoting a single programming style: essentialy C# except the syntax can be modified to look like your favourite language. No self respecting LISP, Scheme, ML, Haskell, Prolog etc. programmer is going to deliberately write inefficient code (and imperative style explicit looping is usually terribly inefficient in these languages as one example) simply because they are living withing the .NET CLR jail cell. Therefore they will use the language with the least impedance mismatch to the CLR: C#.

As has been mentioned often, the Java JVM has many of the same issues. However the developers of the Java JVM never claimed to efficiently support languages other than Java as first class citizens. The recent furor over the .NET CLR makes this seem like one tof the few wise choices they made so far.

So to reiterate, the issue is not whether a language can be targeted to the virtual machine, it's whether the object code produced from source code in two different languages can interoperate and the answer is simply no, only the subset of features shared by C# and other languages can interoperate.

Think maybe better not

[Pussy Is Money]

So there is some interesting technology behind .NET.

Why?

It solves problems. Let's assume it solves problems. Such as, you can write in different languages. Even use objects as objects (!) in different languages. To some extent. That is the impressive part.

There is also a virtual layer. It has been compared to the JVM. I am not going to compare it to the JVM. I am not even calling it a virtual machine. That is not to disparage the effort -- but .NET is much bigger than just a virtual machine. One could also convincingly argue that a virtual machine is not, ultimately, the most interesting part about efforts such as .NET.

Efforts such as .NET. What kind of efforts are there that are like .NET? What is .NET? Nobody seems to know, really.

It is good to see that the .NET APIs and interfaces are being picked up. This is most certainly where a lot of .NET value is. Perhaps even most of the value. Who knows? Of course there is a lot of geewhiz computer science in .NET that you could also point out as desirable. The Python and Eiffel crowds will know. But personally; I believe a good solid API is worth a lot of, um, computer science.

Just to indicate how broad .NET really is. There is something there to please everyone. It's "virtual", but in a comfortably ill-defined myriad of senses, and it's great computer science, but it also means business.

If it succeeds, it might almost bring Microsoft in line with the rest of the computing world (UNIX). That is, peer review, sane architecture, sane libraries.

Right. So what is wrong with GNOME that can't be fixed without first creating, then resorting to Mono? Well, we don't have all the language bindings that .NET would offer. We would get a uniform API across languages for many things. Well, actually of course we would get excellent integration for oft-used languages, and languishing thesis project kind of support for lesser used languages.

Which is pretty much the way it is now. If you want to do text, you use Perl. If you want to do anything else, you use C. If you want to get virtual and a headache, you use Java. If you want to do computer science, you use Python.

Does anybody really believe that this will be any different under .NET? And when? How long will it take before we even reach that point? Would that time not be better spent making GNOME even better than it already is? How about writing some more documentation? If writing hundred lines of documentation fixes 400 potential errors now, versus .NET fixing thousands of potential errors in two, three years time -- what constitutes the better investment in our freedom?

Crossplatform multi-language support?

[Anonymous Coward]

Sure:

"Example for Syntax: identifiers. CLS identifiers cannot be disambiguated by letter case alone. This is incompatible with the behavior of most case-sensitive languages."

"The CLS only supports single, static inheritance. Languages such as C++ and Eiffel need multiple inheritance of implementation."

More funnies at: http://www.javalobby.org/clr.html

TH

When the functional paradigm is superior?

[Anonymous Coward]

I'm looking for few examples of code comparing, say, LISP to Perl or C or C++, which would show me where functional paradigm is superior over procedural and object oriented.

I'm not saying that functional languages are not better (it would be just ignorance of mine), it's just I haven't found any such problem yet, where functional paradigm would be any more convenient than procedural or OO.

Long time ago I didn't understand why to use object oriented languages, when the same can be done without OO. After a long time, I understood where OO is better. Now, I'd like to understand where functional is better, but it's harder, because functional languages are less popular than OO. They seem, however, to be used by hardcore hackers, so they are surely worth attention.

So... please show me (and others) the functional way of thinking! This is a serious problem, so please don't missunderstand it as a joke or something. Thanks.

Please mod it up so others could see it. I'm just a coward who wants to hide ignorance behind anonymity, and in the end, isn't that what AC posts are all about? :)

Re:GNOME and .NET change of heart

[kin_korn_karn]

Java is a raging success at the enterprise level. You can hire H1Bs straight off the boat to bash Java code for half the price of any other programmer.

To implement a Java project you need the following:

1 architect
1 business analyst type
X code monkeys, depending on the size of the project and the timeline.

India supplies the code monkeys at 1/3 to 1/2 the cost of an American, while the two people who have communication skills are paid what they're worth.

I'm sorry it's not PC. I like people from India. Sadly, half of what an american programmer makes is more money than a lot of people from India have ever heard of.

It's a manipulation and a scam on both sides - India farms out its best minds to artificially raise their GNP (and increase their status in the world), while US companies get cheap labor without having to establish an overseas presence. Brought to you by Dubya and the Indian government. Praise Jesus!

If you think this isn't real, talk to any US citizen who is a developer working in a non-Java technology. Talk to any H1B doing Java over here.

*spit*

Re:Who thought this?

[guinsu]

You know its intersted that Java wasn't designed for having lots of short-lived objects. Think of the performance benefits programmers might see (like in for loops, using String instead of StringBuffer etc).

COM

[Weezul]

Purely functional langauges stateless work quite well under an object oriented frame work. Yes, I know objectes are supposed to have state. Object level states are handled very well in all modern purely functional langauges via monads. I think Haskell has transioned to COM programming very nicely.

As a side note, anyone notice how all the current langague research is going on under Windows with Microsoft grants? Currently, most of the projects simultaniously support Windows and Linux, but these projects are currently focusing a lot of attention of COM and .NET. They are not even adding support for the various open source technologies like CORBA. I expect that you will find open source operating systems to be a bit behind the times langauge wize in a few years.

Why Functional Programming Matters

[dstone]

Okay, I apoligize for an extra long post here, but I still see people mischaracterizing functional programming. So I'm going to take a few excerpts from "Why Functional Programming Matters" by John Hughes. It's a short paper, worth your time if you're new to the functional paradigm.

No Side Effects:
Functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant - since no side-effect can change the value of an expression, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa - that is, programs are "referentially transparent". This freedom helps make functional programs more tractable mathematically than their conventional counterparts.

Higher Order Functions:
Functional languages allow functions which are indivisible in conventional programming languages to be expressed as a combi-nation of parts - a general higher order function and some particular specialising functions. Once defined, such higher order functions allow many operations to be programmed very easily. Whenever a new datatype is defined higher order functions should be written for processing it. This makes manipulating the datatype easy, and also localises knowledge about the details of its represen-tation. The best analogy with conventional programming is with extensible languages - it is as though the programming language can be extended with new control structures whenever desired.

Lazy Evaluation:
A complete functional program is just a function from its input to its output. If f and g are such programs, then (g . f ) is a program which, when applied to its input, computes g (f input). The program f computes its output which is used as the input to program g. This might be implemented conventionally by storing the output from f in a temporary file. The problem with this is that the temporary file might occupy so much memory that it is impractical to glue the programs together in this way. Functional languages provide a solution to this problem. The two programs f and g are run together in strict synchronisation. F is only started once g tries to read some input, and only runs for long enough to deliver the output g is trying to read. Then f is suspended and g is run until it tries to read another input. As an added bonus, if g terminates without reading all of f 's output then f is aborted. F can even be a non-terminating program, producing an infinite amount of output, since it will be terminated forcibly as soon as g is finished. This allows termination conditions to be separated from loop bodies - a powerful modularisation. Since this method of evaluation runs f as little as possible, it is called "lazy evaluation". It makes it practical to modularise a program as a generator which constructs a large number of possible answers, and a selector which chooses the appropriate one. While some other systems allow programs to be run together in this manner, only functional languages use lazy evaluation uniformly for every function call, allowing any part of a program to be modularised in this way. Lazy evaluation is perhaps the most powerful tool for modularisation in the functional programmer's repertoire.

Why you might care:
Modularity is the key to successful programming. Languages which aim to improve productivity must support modular programming well. But new scope rules and mechanisms for separate compilation are not enough - modularity means more than modules. Our ability to decompose a problem into parts depends directly on our ability to glue solutions together. To assist modular programming, a language must provide good glue. Functional programming languages provide two new kinds of glue - higher-order functions and lazy evaluation. Using these glues one can modularise programs in new and exciting ways... Smaller and more general modules can be re-used more widely, easing subsequent programming. This explains why functional programs are so much smaller and easier to write than conventional ones. It also provides a target for functional programmers to aim at. If any part of a program is messy or complicated, the programmer should attempt to modularise it and to generalise the parts. He should expect to use higher-order functions and lazy evaluation as his tools for doing this.

Re:Biggest oxymoron?

[markj02]

OCAML is comparable to other safe, compiled languages, including Java. SISAL and similar functional programming languages for numerical applications can even beat Fortran, mostly because there are more opportunities for optimization.

Functional programming language are an excellent match to the needs of modern processors. In fact, the only reason C and Fortran aren't complete dogs is because we invest enormous amounts of effort in adding special-purpose processor features to support imperative constructs, including speculative execution, branch prediction, byte-wise updates, instruction-level parallelism, etc. None of that hardware does any good for the computation itself--it just eats up precious real-estate in order to support the semantics of languages like C and Fortran. Functional programming languages not only remove the need for most of that hardware, they are also nicer to program in.