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

Look deeper... it's not that bad.

[SID*C64]

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.

GNOME and .NET change of heart

[Marx_Mrvelous]

After reading Miguel's long response to the Register article, I've really changed my mind about .NET architecture. I think I'm going to get a book and start learning it, maybe try to contribute to his effort.

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.

Re:GNOME and .NET change of heart

[Marx_Mrvelous]

http://mail.gnome.org/archives/gnome-hackers/2002- February/msg00031.html
That's his response. The things that changed my mind:
1.Using C#/CLI allows GNOME to suppotr many more programming languages much more easily.
2. .NET allows us to ditch the "bad" code that has been generated by patching and updating old libraries, etc. It's a potential fresh start that could be very improtant in the long run.
3. Memory protection. Like Java, it handles garbage collection and related issues very well.

I suggest to anyone to read the above URL, it's very informative.

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: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.

Re:GNOME and .NET change of heart

[elflord]

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!

I'd argue that globalisation is not at fault, in fact, quite the opposite is true. The apparent inequalities are caused by the fact that there is not complete freedom of movement. To the degree that we have globalisation, it makes the inequalities visible, but it certainly doesn't create them. There's nothing "artificial" about the way India is raising their GNP. A more brain-oriented economy results in a stronger currency (and hence higher GNP). If the Indian government are working to create a more brain oriented economy, good for them.

Re:GNOME and .NET change of heart

[ClosedSource]

"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.

Re:GNOME and .NET change of heart

[Courageous]

From having developed very large amounts of code with plenty of undocumented back-end, my guess is that the oodles of complaints about "hidden APIs" exploited by Microsoft is really more of an issue of exactly what programmers seemingly everywhere do: we write lots of code to get the job done, and then, at the last minute, document our public API. That still leaves plenty of very useful code (auspiciously, our "own") which we understand, but nobody else does. While I can acknowledge the possibility that there is malfeasance, Occam's Razor impels me to believe that the most obvious and likely explanation is the one which is most important to look at first.

Since to the best of my ability to discern, most programmers drag their feet writing documentation, and likewise since Microsoft employs something not all that different from "most programmers", it therefor logically follows that Microsoft programmers drag their feet writing docs and do only what they perceive they really have to do.

Of course they have an advantage when they use their own code. If you're a programmer, then so do you. And so do I.

C//

Re:GNOME and .NET change of heart

[Courageous]

You can hire H1Bs straight off the boat to ...
...India supplies the code monkeys at 1/3 to 1/2 the cost of an American, while...

Well, not quite true. Probably more like 30% less. It's illegal to pay an H1B less than the "prevailing wage," and so the companies have to tread very carefully to appear to not be doing so and give themselves some plausible deniability. Anyway, the answer is not so much to scrap the H1B system, but to A) enforce the current rules, and B) give people here on work visas more flexibility in finding new jobs. If an H1B could comfortably get a job at a higher wage within 6 months of entering the country, believe me, they would. That would be better for all involved, including the H1B worker.

C//

Re:GNOME and .NET change of heart

[kin_korn_karn]

Damn, Joe, you're everywhere. I used to post on a newsgroup you frequented back then. hint: email address.

I have to disagree. First of all, it being illegal to pay them less means nothing. I think there's a loophole with consulting companies. They can bill at the same rate as citizen, but pay the slave^H^H^H^H^Hconsultant whatever they want.

I think the work visas should be limited, period. 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. They're often young enough that they can get by without even requiring health benefits, too.

What we have with the H1Bs is the recipe to economic collapse, rapid inflation, etc. Just look at the early 20th century immigration boom. That eventually led to the great depression, which led to WWII. The only difference is that those people came to stay - what happens when companies get dependent on bottom-of-the-barrel cheap labor and can't remain profitable without it? if the cheap labor gets taken away, they go bankrupt, and that screws the economy, too.

There are no easy answers here, and I hate it, because most folks I've met from India have been fine people.

Re:GNOME and .NET change of heart

[elflord]

I have 28 years experience. I know all the hot technologies. I've been out of work for five months now and I'm getting close to the end of my resources. It's easy to feel generous when you're employed, but not when the only people left in your old company are Chinese and Indians. What am I going to do for my family . . .

It's not a matter of feeling "generous". I don't blame you for feeling pissed off, but isolationist policies would not really help you very much. The problem is that we are in a global economy, and sticking our collective heads in the sand doesn't change that. If the government legislates isolationist policies, jobs move off shore, and the same Chinese and Indians still replace you, the only difference is your office moves to them and not the other way around.

The reason you're in this mess is that your labor is too expensive (or at least is perceived that way. The perception is probably actually true of you and most American tech workers). If the US currency was a tad weaker, you'd be cheaper in the world economy, and hence more employable. Conversely, if the Indian currency becomes stronger, the Indian workers become more expensive, and less appealing as a source of "cheap labor".

Cheers, and by the way, best wishes,

Re:GNOME and .NET change of heart

[Courageous]

I think the work visas should be limited, period.

Well if we're bringing people over here, and there leaving from over there, and these people have higher IQs on average, there is at least one long term argument which suggests that their brain drain is our brain gain. Ultimately we can't prevent companies from outsourcing entirely to foreign countries, so it follows that having smart foreigners come here to become citizens has its benefits in comparison to the alternatives.

Most protectionism is based on gut feelings. Much of those feelings aren't based on the counterintuitive truth of economics, which is by no stretch a zero sum game. In the topsy turvy world of economics, when more players enter the playing field, there actually ends up being more for everyone. This can be a sour pill to swallow, of course, when you're one of the ones who's currently not in the more for everyone category. Economic changes can be disruptive on a microscale, of course.

If there is a loophole for contractors, it should be eliminated. All indentured servitude aspects of the system should likewise be eliminated. Under those circumstances, employers would likely not even so much as use the H1B system as much, as you and I both know that their nom-dejure explanation for H1B requests is really deception: what they actually want is cheaper workers.

If they want these badly enough to set up operations in a foreign country, that's fine, but it shouldn't be at the expensive of immigrants who are future citizens.

And with that, I'll leave you with a quote from Ayn Rand: "I believe that immigrants are better than those born here. The immigrants actually had to want to be here. Everyone else was simply born."

(paraphrased)

C//

Re:GNOME and .NET change of heart

[elflord]

I have to disagree. First of all, it being illegal to pay them less means nothing. I think there's a loophole with consulting companies. They can bill at the same rate as citizen, but pay the slave^H^H^H^H^Hconsultant whatever they want.

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

Re:GNOME and .NET change of heart

[PhiRatE]

P/Invoke

More windows-only hooks than you can shake a large stick at, all in one command.

Re:GNOME and .NET change of heart

[kin_korn_karn]

Well if we're bringing people over here, and there leaving from over there, and these people have higher IQs on average, there is at least one long term argument which suggests that their brain drain is our brain gain.
They take food from the mouths of Americans. I'm sorry. Like I said, I like the people, but I have to take care of #1.

Ultimately we can't prevent companies from outsourcing entirely to foreign countries, so it follows that having smart foreigners come here to become citizens has its benefits in comparison to the alternatives.
Who benefits? Society? American culture? Who cares? As someone facing unemployment soon, I can say, it sure as hell isn't me that benefits.

Before you chide me for being selfish, let me state that it's hard to care about your nation's culture developing when you might be bankrupt or unemployed for a while. If you want science behind it, Maslow serves the purpose.

In the topsy turvy world of economics, when more players enter the playing field, there actually ends up being more for everyone.
Spoken like someone who has it easy at the point in time in which they speak.

Economics is not a synergistic game. No system reaches >100% efficiency. There's always loss in any system, and that includes a nation-state's socioeconomic system. When your country hangs you out to dry, it's real hard to care about its well-being. Taliban, anyone?

This can be a sour pill to swallow, of course, when you're one of the ones who's currently not in the more for everyone category.
"Everyone" means everyone, and includes me and all the other lame-ducks and unemployed. Please rephrase.

- Josh

Re:GNOME and .NET change of heart

[Courageous]

They take food from the mouths of Americans.

Nothing like they will if we don't compete.

Who benefits?

The loss of American business to foreign countries will hurt you more than any system of immigration ever will. The failure of American business culture to compete internationally and domestically will hurt you more than any immigrant ever can. Preventing immigration is not the answer.

Economics is not a synergistic game.

In fact it is. Your statement is completely at the odds with the fundamental basis of modern economics. This, however, occurs at the systemic level over larger periods of time and protects individuals at any particular time point not at all.

No system reaches >100% efficiency.

Non sequitur.

Please rephrase.

You understood what I meant clearly enough.

As someone facing unemployment soon...

While I understand how that stings -- and I sympathize! -- being stung does not in any special way demonstrate that a perceived solution that would have prevented a particular sting would be the best for the overall nation of individuals.

I'm sorry you're going through a tough time.

C//

Re:GNOME and .NET change of heart

[Tsujigiri]

The USA, functionally speaking, owns the world. If you think of the Earth as a corporation, the USA is the majority shareholder

HA HA HA HA HA. That is the stupidist thing I have heard in a long time. What is especially funny is that so many Americans actually do believe this, that some how the world is there to support and adore the US.

This is actually more stupid than an event that happened to my Brother-In-Law studying on a international Scholarship in Germany.

Apparantly, the US has a separate agreement with the German government to the rest of the world for their students (they can't play nicely with the other children, or they don't want to be shown up or something), so US students study in a separate class to the rest of the world.

Anyway, my Brother-In-Law was talking to one of them and the American says "So it's really hot in Australia at the moment isn't it?" to which B-I-L answers "Yeah, it is quite hot over there."

Then the American student says "But you do still call it winter, don't you? I mean it's winter in the rest of the world!" Even this guys friends had to turn away in amazement.

Re:GNOME and .NET change of heart

[DrSkwid]

What am I going to do for my family . . .

move to India?

Re:GNOME and .NET change of heart

[Courageous]

...but we did have stability and we knew what was important...

No, not really. Stability isn't much of a feature of modern economic society. Apparently you missed the big tech bust in '90, which really hit San Diego hard in particular (where I live), but even more we should consider the power of shifting economic dynamics over history. To wit:

Consider the world of 1900. At this moment in time, over 90% of the U.S. population was dedicated to agrarian pursuits. Today, less than 2% of the population is dedicated to agricultural work. That's a massive shift in labor allocation: entire careers and lines of work evaporated wholesale, creating an entirely different and better and more abundant economy. During the same time period, agricultural productivity rose over 400 times.

The USA, functionally speaking, owns the world

Not really. Get a copy of the CIA factbook. China has the world's second largest economy at about half the size of the U.S. Japan's is a close third. And really, these changes are nothing new. In the 50's, the U.S. GNP was literally larger than all the GNP's of all nations on earth combined. It's a diferent world today, and it's a better world. As it turns out, economies are not a zero sum game. In the topsy-turvy world of economics all players get to have more and it doesn't have to be at the expense of the other players.

This of course doesn't negate localized effects. The world is a chaotic place and sudden changes in economic realities temporarily displace people as they adapt to new markets.

Take care of us and the economy will take care of itself.

Obviously various societies around the globe are experimenting with different levels of this belief. What does seem true however is that any attempt to universally protect all individuals generally produces a society with misery and paucity of goods.

What appears to be the dominant successful model is to not protect workers from the demand-changes of business, but rather to help them adapt and to likewise perhaps encourage business to promote this adaptation.

I can't believe I'm thinking this way, anti-technology, but tech and...

You're blaming the wrong target. The tech economy bubble is to be blamed on very bad business decisions. If I only had $10 for every venture investment made without insisting on the otherwise mandatory business plan with a clear market analysis and plan for profitibility. What happened is that the various venture capitalists all got stupid. The market expanded to accomodate the sensical and the lucky, but ejected the idiots and also-rans. My quip for the day: "too many players began to think of the tech economy as Vegas and not Wall Street."

Hope things turn out well for you, Mr. Whitt.

C//

Re:GNOME and .NET change of heart

[Courageous]

What is especially funny is that so many Americans actually do believe this

We're trailing on vapor. :) In the 50's it was in many ways true. The U.S. GNP post-war-time economy had a major portion of world wide production power.

The other day I was perusing the y. 2000 CIA factbook. I found it interesting to note that China has about half the GNP of the U.S., and that they are now the second largest economy in the world. Of course, their per capita GNP isn't all that spectactular yet, but that's just a matter of time. It appears that the sleeping dragon is finally awakening.

...that some how the world is there to support and adore the US...

Well if you'd really like to lick our boots, please go ahead. Just try not to be so sychophantic about it, okay? It's embarrassing. :) :)

C//

Re:GNOME and .NET change of heart

[elflord]

Now you're experiencing the bad side of the USA. Why do you think other western countries such those in Europe or Canada expend so much effort on building a more caring society (at the expense of higher taxes)?

How true is this ? The top marginal tax rate in the US is 40% IIRC, and they also have state income taxes on top of that, and a steep property tax on top of that. Unemployment is a desperate situation even in a "caring" country, especially if you're used to earning a lot of money.

Re:GNOME and .NET change of heart

[Tsujigiri]

That's the other annoying american habbit, they tend to quote out of context to try to look clever. As you put it:

The other day ... the ... CIA ... found it interesting to note that China ... isn't all that spectactular yet, but ... [would - ed] really like to lick our boots, ... It's embarrassing. :) :)

I think that says it all really.

Re:GNOME and .NET change of heart

[Courageous]

That's the other annoying american habbit, they tend to quote out of context to try to look clever.

I didn't quote you out of context. However, if you're trying to look clever, you should probably correctly spell the word "habit". One "b".

Grow a sense of humor.

C//

Re:GNOME and .NET change of heart

[Tsujigiri]

I didn't quote you out of context.

You sure did quote me out of context, or did you not realise. Oh, that's right. Americans don't believe in context. Everything to suit themselves.

You see I posted this:

[quote]
HA HA HA HA HA. That is the stupidest thing I have heard in a long time. What is especially funny is that so many Americans actually do believe this, that some how the world is there to support and adore the US.
[end quote]

And you replied with this:

[quote]
...that some how the world is there to support and adore the US...

Well if you'd really like to lick our boots, please go ahead. Just try not to be so sychophantic about it, okay? It's embarrassing. :) :)
[end quote]

So if you can't understand that that is quoting out of context you obviously are a lost cause. So go back to your isolated, secluded US life, shouting at the TV when the "green back" is not doing so well against foreign currency.

Oh and while we are on the subject of spelling it's "sycophantic" not "sychophantic" (were you trying to invent a word like "psychophantic" perhaps??). I can get the big words right. :)

And as far as "growing a sense of humor" (ah, the humour crops are up this year, there will be plenty of humour seeds to plant next year), I think that the fact that I have continued this conversation with you for this long without getting angry or being nasty is a testament to my humour. (And if you notice, it can be spelt as humor(US) or humour(the rest of the english speaking world))

Anyway, it's been a pleasure talking with you (no really). So have a nice day (no REALLY) and try to see things from other peoples point of view (it really makes the world a better place). I look forward to our continued correspondence in the near future.

Yours Sincerely.
Damien Byrne.

Re:GNOME and .NET change of heart

[Courageous]

Well if you'd really like to lick our boots, please go ahead. Just try not to be so sychophantic about it, okay? It's embarrassing. :) :)
[end quote]

So if you can't understand that that is quoting out of context you...
----
What you fail to realize is that you're experiencing a language failure. While I understand that English isn't your first language and sarcasm is therefor difficult to detect, there was sarcasm present in my message to you along with a liberal two -- two! count them! two! -- smiley faces to alert you its presence. So, it would appear, not only are you guilty of lacking a sense of humor, you need to acquire some understanding about important written linguistic markers of the digital age.

C//

Re:GNOME and .NET change of heart

[einhverfr]

I disagree with your perspective that one will see a large chunk of code that will not be cross-platform compatible. (If it is, Java will kill it rather quickly ;))

The basic point, I think is that the .NET classes are supposed to be the REPLACEMENT for the Win32 API, and Win32 hooks exist for interoperability with legacy components. These APIs are really messy compared to the .NET classes, so the classes are much better from a developers' perspective. With the exception of connecting with legacy COM components, I can see absolutely no reason to do development using the Win32 hooks.

A don't know about others here, but I HAVE studied .NET and I think it does show these elements of promise. The issue is though that unless it is cross-platofrm, it cannot truly compete with Java, which is why I think that the third party implimentations, such as MONO and Portable.NET are important to its acceptance as a platform (otherwise the performance hit of the JIT does not make it worth it).

Mondrian for .NET

[cdmoyer]

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.

Here's a blurb from Dr. Dobbs:
Mondrian is a modern, purely functional language specifically designed to leverage the possibilities of the .NET Framework.

Re:Mondrian for .NET

[jovlinger]

well, that does explain the motivation behind the ILX website design...

Re:Mondrian for .NET

[jovlinger]

They (microsoft research) have Simon peyton jones. Trust him to know how to handle this. BTW: if you are interested in program transformation, read this paper. It is truly one of the 10 eye-opening papers of my academic carreer.

Author: Simon L Peyton Jones and John Launchbury
Title: "Unboxed values as first class citizens in a non-strict functional language"
Pubn: Proc. 1991 Conf. on Functional Programming Languages and Computer Architecture, Cambridge Mass., Sept 1991.

ftp://ftp.dcs.glasgow.ac.uk/pub/glasgow-fp/paper s/ unboxed-values.ps.Z

The one caveat is that you need to be able to pass unboxed values around at the vm level. I seem to recall CLI does this.

Who thought this?

[saforrest]

What basis for thinking this would anybody have?

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 .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?

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.

Re:Who thought this?

[relinquish]

As far as I understand the issue is a performance one.

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.

Re:Who thought this?

[entrox]

The problem lies in the CLS: Common Language Specification. .NET libraries and applications can be written in a colorful mix of languages and must be able to interoperate. Interfaces tend to look a little bit differently in functional languages than in imperative ones. If I use feature X of my preferred language in my library, which isn't available in your preferred language, you won't be able to use the library how it's supposed to be used. Herein lies the difficulty: making those inter-language operations as painless as possible. It's a hard problem and while going to a lowest common denominator is surely a possibility, it surely will alienate the users of say functional languages.

Re:Who thought this?

[JamesOfTheDesert]

As long as the language is Turing-complete, it should be possible;

The question has to do with getting the language to run well, and correctly, on a stack-based VM.

Re:Who thought this?

[affenmann]

> As far as I understand the issue is a performance one.

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 .NET) are designed primarily for object oriented langages having long(er) lived objects with identity and storage.
It's this mismatch that makes it hard to use functional languages *efficiently* with .NET.

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.

Re:Who thought this?

[smallpaul]

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 .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?

There is a big difference between implement EMACS or TCP/IP *in* a language and implementing a language *on* .NET! Your mixing apples and oranges.

Nevertheless, there is no question whether functional and logic languages can work on .NET. The only question is whether they can work with sufficient efficiency that they will be tools, not toys.

Re:Who thought this?

[jwpalmer]

I think that this is an instance of an unclear question. The question is not "Is it possible to implement functional languages in .Net?", but rather, "Do the bytecode primitives efficiently support execution of functional language primitives?"

You might be able to implement a functional language interpreter supporting closures, lazy evaluation, etc., in the standard bytecode, but that's not the point. The point of the CLI is to effectively support efficient execution of programs written in ANY language. Therefore, writing another layer on top of the bytecode to support features unique to functional languages eliminates many advantages functional languages provide, and can potentially disallow correct execution of complex functional programs.

So, if the bytecode representation was designed to support object-oriented languages, it's probable that it WILL NOT efficiently support recursion and partial evaluation. This is the crux of the argument, and why people are concerned with the existing bytecode spec.

There is a lot of work being done in this area, though, so there is hope that this will be resolved. After all, Microsoft does have some of the best minds in functional programming thinking about the problem.

For more information, see:

http://research.microsoft.com/~dsyme
http://www.research.microsoft.com/~emeijer
http://www.mondrian-script.org

- j

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).

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?

[jguevin]

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.

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?

[John_Booty]

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.

This is very insightful. As a guy who's been programming in the Windows world for a while, I can tell you the ease and ubiquity of Visual Basic have definitely produced a ton of bad code, and allowed a lot of unskilled people to quicky hack out a lot of bad code. It's not that VB's such a bad language (for what's it's supposed to do), you can actually produce nice code with it if you wat. You could probably say the same about Perl or many other languages of course.

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.

Re:What about speed?

[RubberMan]

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

Re:What about speed?

[egomaniac]

"but 'beats visual C++' ? firstly - what is that? you mean C++ (why should the ide affect benchmarks!?)."

I'm not sure I follow you. You can't debate the performance of languages without referencing specific compilers, since by definition a language doesn't perform without a compiler (or interpreter or VM or whatever). MS Visual C++ is a good choice for comparison, because the vast majority of commercial applications were compiled with it.

According to the Java Performance Report, the IBM JVM beat VC++ in a variety of standard benchmarks. These aren't artificial "allocate a million objects" benchmarks; they're things like neural nets and FFTs which are actually done in real life. Go read the report.

It's worth noting that the Intel C++ compiler did a lot better, but the fact is that if Java is better than Visual C++, it's good enough for the masses considering that the masses are happy with Visual C++. (Remember that GCC sucks ass performance-wise, and most Linux fans are perfectly happy with it).

Re:What about speed?

[Steveftoth]

One thing that you didn't mention that I think is really cool about the hotspot technology is that it can dynamically inline functions. Since it is profilling your code as it is being executed, it also keeps track of what code is calling what. And it will inline code if it is running certain paths a lot.

This means that depending on WHAT you do during an application's execution, determines which code gets compiled to native. Very cool stuff.

HP had the Dynamo project that did the same thing, but with precompiled PA-RISC code. Links...
http://www.hpl.hp.com/cambridge/projects/Dynamo/ in dex.htm
http://slashdot.org/article.pl?sid=00/03/23/1062 57 &mode=thread

Re:What about speed?

[Steveftoth]

what's wrong with
tar zxf someprogram.tar.gz
cd someprogram
./configure
make ; make install

Re:What about speed?

[egomaniac]

The facts that:

A) average users could never do that
B) it doesn't allow for seamless installations
C) it takes forever
and,
D) it frequently doesn't work on the first try

Try out Java Web Start if you want to see how applications should be installed.

Re:What about speed?

[Hard_Code]

what's wrong?

* checking that you have aasdf12455.so .... no
* checking your FU compiler .... /usr/bin/fuc
* checking that your FU compiler supports BAR feature .... DUNNO
* checking that you have 1000 arbitrary dependencies satisfied .... PARTIALLY
* OK we are ready to proceed and create a subtley broken binary which will provoke you to ripping out your hair when it breaks (or breaks other things) in non-intuitive horrible ways and to waste an ungodly amount of time futzing with these stupid makefiles

Re:What about speed?

[Kanasta]

More worrying, how big is the .NET runtime that the user has to download to run my 10kb text editor?

Re:What about speed?

[Steveftoth]

I guess that I should to have put the <this is a funny joke to me> tags around my previous message.

But seriously, JWS is awesome. If only the apps started with JWS used the SAME JVM. now that would be ultra cool. Not that I'm complaining, cause it's way better then any other platform for auto distribution of apps right now.

boy, good thing

[Frothy Walrus]

all four Prolog and LISP Win32 applications developers were getting nervous.

nice solution to a non-issue.

Re:boy, good thing

[Anonymous Coward]

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

What's to change

[Mike Connell]

I dont think anybody seems to have a great problem with the technology - ie bytcode and VM's - although it seems rather premature to be thinking of applying it to GNOME at the moment. Get some medium sized apps running under Mono first before crippling GNOME with something that isn't ready.

The real problem is Microsoft. It might be a cool technology, but Microsoft wont think twice before taking their ball and going home with it.

Mark my words: If it happens, it'll all end in tears.

Could work out well for the KDE guys though ;-)

Standard ML and Haskell implementations

[hsenag]

Work has been done on implementing two major functional languages for .NET: Standard ML and a partial implementation of Haskell at the Mondrian site (it already seems to be slashdotted so I won't make this worse).

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.

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.

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

[Malc]

"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."

Hasn't that always been the case? This is the argument that could be applied to COM. COM successfully provided binary compatibility between languages, and I can't see them throwing that away. With COM, one doesn't design the interfaces based on your favourite features of your chosen language - the interface comes first at design time, and what you do in the implementation is largely irrelevant. I imagine that .NET will be the same.

Re:the promise of functional programming...

[shd99004]

Yes in AI they have been useful - LISP was made for this purpose actually. Although I do like Prolog a lot more.

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?

Think strategy, not technology

[pubjames]

A lot of the debate about .NET and the open source focuses on the technology, and not the strategy.

Let's consider some facts first. One of Microsoft's basic strategies is the complete domination of markets. They make no secret of this (although they have not been successful at it outside of the desktop space). Here are some instances where senior Microsoft people have stated they want to completely dominate a market:

1) Internet access with MSN.
2) The handheld market with Windows CE
3) The game console market with X-Box.

In all three cases above, they have made it clear that they intend to dominate that market, and have even stated that it is "the Microsoft way" to do so. They're not interested in 50%, they want 100. Admittedly they haven't yet been successful in this any of the above markets (in fact I think we can now safely say that they've failed with Internet access), but that is their intent.

So, what has this to do with .NET? Well, .NET is a technology, but it is also a strategy. Its aim is to completely dominate software development in the future.

Now, Microsoft's strategists will have spent a long time thinking about this. They will have hypothosized about potential problems, and developed contingency plans. Microsoft knows that in order for .NET to be successful, they need to win developers over to it. In order to do that, they need to give the appearence of it being an open and non-threatening platform to use. But that's only appearances. Their aim with .NET is to completely dominate the provision of any type of software service over the internet (which will include pretty much everything within a decade) and to get their slice of every transaction made.

That's why I despair when I hear people in the Open Source community talk about implenting stuff in .NET. If you think you will ever beat Microsoft by playing by their rules then you have your head in the sand. Think about what contingency plans Microsoft might have in place. Remember that they have a war mentality - what would you do if you were Microsoft? Think about the Haloween memos.

Has anyone, for instance, looked through all Microsoft's patents, to check that their isn't a surprise that they could pull out of the sack if things aren't going their way? Has the Gnome Foundation, for instance, got the financial means to defend itself should Microsoft attack it legally? Why are some parts of the .NET strategy still vague, when Microsoft is "betting the barn" on it?

.NET is perhaps great technology. But I implore everyone in the OSS community to stay away from it. Bill Gates will tell you that the best technology doesn't necessarily win in the long term, it is what has mindshare. OSS is getting more mindshare every day. Don't help MS by supporting their technologies. Your software project will get killed if it starts to threaten MS if you do.

Re:Think strategy, not technology

[pubjames]

SHould we then succumb to the Not Invented Here syndrome and ignoring the technology just because of its origin?

Yes, that's exactly what I'm saying. Microsoft do it all the time. That's why they're promoting C#, and not trying to improve Java. They're great strategists. Some parts of the OS community has recently shown itself not to be.

Re:Think strategy, not technology

[pubjames]

News Flash! Corporation wants to maximize market share!

Different companies have different strategies. Look at IBM - it's strategy is one of partnership with other IT companies, and it is proving very successful. Few companies in the IT industry have the warlike "kill the competition at any cost and get 100% of the market" mentality that Microsoft does.

Re:Think strategy, not technology

[Lord Omlette]

We were talking about Functional Languages under .NET CLR, what were you going on about?

Re:Think strategy, not technology

[inburito]

Wake up.. Microsoft has spent countless hours and a lot of money to come up with something that is actually good! It doesn't matter what their strategy is but as a technology .net framework is terrific. Note that .net generally refers to a lot more than just .net framework, which is what de Icaza is enthusiastic about.

We can get the benefits of the technology and ignore the strategy. Even if microsoft decides to change it's api or use patented processes it cannot prevent oss-community from essentially getting a free lunch on microsoft's expense because it is impossible to patent something as broad as .net framework. They might be able to lock up some minor details but it is the concept that matters.

So microsoft pulls out the rug from underneath us and somehow prevents further interoperability with future .net revisions. What are we left with? A great technology.. What is there to lose?

Oss has always been about taking the best ideas and implementing them in an open manner. What is different here? Nobody is going to force you to use it but if it is going to increase developers productivity then why not?

Re:Think strategy, not technology

[Melantha_Bacchae]

inburito writes:

> We can get the benefits of the technology and ignore the strategy. Even
> if microsoft decides to change it's api or use patented processes it
> cannot prevent oss-community from essentially getting a free lunch
> on microsoft's expense because it is impossible to patent something as
> broad as .net framework. They might be able to lock up some minor
> details but it is the concept that matters.

Put it this way: A rich shark invites you to come swim with him in his new, high-tech pool. You think "even if the shark decides to go swimming in one of his other pools, I still get to keep this one. Cool!".

You are forgetting that this is a huge man-eating shark, the technology is bait and trap, and *you* are *his* free lunch.

At least go to http://www.uspto.gov/patft/ and do a quick patent check on obvious things they could use against you.

Come on, Tok Wira, these sharks have got to pay!
New Kirk calling Mothra, "We need you today!"

Re:Think strategy, not technology

[inburito]

I would rather put your analogy this way:

A rich shark has a fancy new high-tech pool. You think that the pool and technology is good but would rather not swim with the shark in the same pool.

So you take a good look at the technology, go back to your own pool and recreate it there.

Shark has spent all that money installing all those hi-tech equipment there and you essentially just collect the benefits without putting in as much effort.

And if it turns out that all of those hi-tech equipment don't work like planned you still have your own pool..

Now who ate whose lunch and at what cost?

Re:Think strategy, not technology

[inburito]

Okay.. Where does it say that .net framework is anything but a developers tool to make better applications faster? That is the million dollar question..

.net is a strategy for world domination, .net framework is a technology and this is probably where you are misled. Microsoft's ultimate strategy is using latter to accomplish the former.

However, it just so happens that the technology is great as such and by creating an open alternative you essentially undermine microsoft's ultimate strategy.

Better yet, you don't need to spend all that effort coming up with something new because someone else already did it for you..

.NET is a quagmire

[darkatom]

.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.

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 .NET well!

Re:.NET is a quagmire

[SteveX]

You're saying that Microsoft's technologies don't work very well for things they weren't designed for? Gee, no kidding.

And TCP/IP makes a terrible 3D graphic API.

- Steve

Re:.NET is a quagmire

[thelexx]

Considering the number of shills about right now, I'm headed to oblivion for this, but after reading a couple of your comments I feel compelled-

" You're saying that Microsoft's technologies don't work very well for things they weren't designed for? Gee, no kidding."

No, I think he was saying Microsoft technologies don't work very well, period.

LEXX

Re:.NET is a quagmire

[SteveX]

Well, he said that MFC doesn't work very well if you try to do something beyond what it was intended for, and that's very true. MFC is a pain to work with as soon as you don't want the default behaviour...

But if you don't want it's default behaviour, don't use it. I wouldn't write a 3D game in MFC, and I wouldn't complain that it was a crappy environment for writing one.

If a technology sucks for what it was designed for then go ahead and beat on it. The early DirectX APIs were rotten 3D game APIs, and that's what they were designed to be. MFC, on the other hand, isn't so bad at what it was designed for.

Same with OLE/COM. MAPI, well, MAPI sucks. :)

- Steve

Re:.NET is a quagmire

[ink]

.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.

Ugh. How many times does it need to be said? dotNET is a marketing term for many technologies, APIs and products. Mono is not attempting to implement dotNET, they are simply using the "core" technologies from it. I was very skeptical of dotNET when it was announced and brought out, and as a Java programmer I was wondering what was going to happen with it. But, Microsoft has managed to create an open technology that binds to many different languages: Something Sun has never been able to do with Java. That Microsoft has a whole bunch of proprietary frameworks, applications and APIs all lined up to go with dotNET doesn't matter at all. There are many proprietary extensions to the Java platform which don't diminish the usability of Java and its core (JDK) libraries.

Yes, fear dotNET, you have reason to. Please, though, differentiate between what Mono is doing and what dotNET is trying to do. dotNET will bring a new transport to the internet which will have presentations that are completely proprietary (something that ActiveX and MSN have as yet failed to do). Yes, they are taking the entire w3c in their sights with it by circumventing their standards all together. Yes, it will be yet another attempt by Microsoft to control the internet. But we shouldn't disregard the technology underneath, because it

• Has multi-lingual bindings
• Has simple XML/SOAP transactions
• Uses published standards
• .. and is actually HERE and available.

I suppose the only legitimate critique of Mono (other than you simply don't like multi-lingual object transparency) would be that it somehow legitimizes this technology for other ends. I don't buy that, because after all -- both Linux and Windows are written with C, a good technolgy. You wouldn't stop using C/C++ because Microsoft wrote MFC would you? That analogy perfectly mirrors throwing out the dotNET framework because of the overall dotNET strategies employed at Microsoft.

It's the API's stupid.

[IGnatius T Foobar]

CLR is no big deal. It's basically a clone of parts of the Java framework. As with any programming environment, it's the API's that make things happen. The CLR claims "language independence" but in reality it favors languages that look and quack like C#.

But the API's ... well, it's a pretty safe bet that the .NET version of Visual Basic is going to generate code that makes calls to lots of Windows-specific, unpublished, and possibly patented API's. Forget about running them under Linux, ever.

I'm singularly unimpressed by claims that the .NET framework will revolutionize programming. It's just the new way for Windows developers to write Windows programs that run on Windows. So what? If you want true cross-platform ability, you write it in a portable runtime environment like Java or Python, or you write to a portable toolkit like Qt or wxWindows.

What the .NET framework might do for us, however, is create a Windows platform on which more apps are well-behaved. This would mean that once WINE is able to successfully run the DLL's that implement the .NET framework, all apps built on that framework will begin to run properly. I'll take that much.

But the patent stuff ... that scares the hell outta me. Rather than obscure the API's, they simply put 'em right out in the open, slap a patent on, and stand an army of lawyers in front of us saying "don't even think of cloning this." Dead stop. We have to avoid this at all costs.

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.

Microsoft Haskell Press Release

[KieranElby]

Microsoft And Yale Conclude Agreement To License Technology For Haskell

Microsoft Demonstrates Haskell-Compatible Browser and Tools

NEW HAVEN - Feb 7, 2002 - At a press conference today Microsoft Corp. (Nasdaq: MSFT) announced it has concluded an agreement to license the Haskell programming language and related technology for inclusion in Microsoft products. As part of this agreement Microsoft will develop and maintain the reference implementation of Haskell for Windows(R) platforms, such as the Windows(R)98 and Windows NT(R) operating system.
Also, Microsoft demonstrated a number of Haskell-compatible technologies collectively code-named "Curry." The technologies demonstrated included Haskell support in the Microsoft Internet Explorer 5.0 Web browser using a built-in, high performance just-in-time (JIT) compiler; an integrated development tool Haskell; and integration of the Haskell language with industry-standard component object model (COM) objects through Microsoft ActiveX(TM) Technologies for the Internet and PC. Microsoft further outlined its plans for Haskell support, indicating that future versions of Microsoft Internet Explorer for Windows and Apple(R) Macintosh(R) will include the ability to run Haskell applets distributed through the World Wide Web. The company also outlined plans to create a high-productivity development tool for Haskell, based on its award-winning Developer Studio technology.

Microsoft is currently being sued by Sun over trademark infringement issues relating to its licensing of Java technology from Sun. A U.S. District Court judge granted Sun Microsystems Inc.'s request for a preliminary injunction that prevents Microsoft from using Sun's Java Compatible(TM) logo to promote and distribute its Internet Explorer 4.0 and related products. In response, Microsoft has taken the unprecedented step of completely abandoning Java in favor of what they consider to be "a vastly superior programming language technology" in the words of Microsoft founder Bill Gates.

In a project that has been kept under wraps ever since the initial adoption of Java, a team of Microsoft researchers has prepared an alternative programming language for use in case of a serious dispute with Sun over the future of the Java language. After evaluating many programming languages, the team settled on Haskell as being the best alternative to Java. According to Chris Fraser, a Microsoft research scientist, "Haskell's polymorphic type system is far superior to the one developed for Java." Also, he asserts that "purely functional programs are the wave of the future: object oriented programming has reached a dead end." As other developers integrated Java into Microsoft products such as the Internet Explorer, this "shadow team" created secret versions of these same products using Haskell instead of Java. The team leader, Conal Elliott, asserts that due to the elegance and expressiveness of Haskell, his team was able to completely duplicate the work being done with Java using only a tenth of the manpower. As all tools needed to switch from Java to Haskell are already in place, Microsoft expects to completely purge its products of Java within a period of less than two months.

"Haskell technology will provide a great way for our developer customers to create innovative applications for the Web," said Dave Hanson, vice president of development tools at Microsoft. "We intend to be the premier supplier of Haskell-compatible tools to Internet developers."

"Microsoft's commitment to Haskell is both impressive and comprehensive, and this agreement makes them one of the leading Haskell supporters," said Paul Hudak, the former head of the Haskell committee. "Microsoft's licensing of Haskell broadens support of the technology significantly."

"Integrating the Haskell language with .NET is something our customers and ISV partners think is extremely important," said Erik Meijer, the new senior vice president of Internet platforms and tools, at Microsoft. "It brings a whole new dimension to Haskell: a clear path for integration with existing applications, systems and technologies. It means that you don't have to start over to take advantage of Haskell."

Current Haskell developers reacted with both joy and concern at this announcement. Simon Peyton-Jones, a prominent Haskell implementor, said "I guess this means the end of our research efforts here. There is no way a small research group such as ours can compete with Microsoft." At Yale, Alastair Reid was more optimistic: "Now I can get out of this hellhole in New Haven and get a real job at Microsoft." In fact, many Haskell developers are expected to join a new Microsoft research group in Nottingham, England which will be headed by Mark Jones, a prominent Haskell researcher. Dr. Jones explained that "they wanted me to come to Redmond but I decided to remain here in Nottingham. When they decided to build a research center here for me I was thrilled!"

Additional information on Microsoft Corporation is available on the Internet at http://www.microsoft.com. Additional information on Haskell is available on the Internet at http://www.haskell.org.

Microsoft Windows, Windows NT and ActiveX are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.

(spoof reproduced from http://haskell.org/humor/press.html, originally released 1 April 1998)

There is no such thing as "Turing complete"

[yerricde]

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.

A Valid Question

[JohnDenver]

October_30th wrote:

Uh... what exactly made you change your mind?

In my opinion, Miguel was just avoiding answering the real issue: .NET is and always will be a Microsoft initiative and property.


This is a valid question followed by his opinion, so why is it modded down to -1?

I for one (and I'm sure there are many more) would like him to explain how he resolves many of the arguments from those who voice against .NET

I always thought Insightful moderations from some offering Insight. This guy just said that his opinion changed after reading the article. Why? Give us an overview.

Efficiency and convenience

[YoJ]

I don't think people are worried that there will never be a way to write functional programs in .NET. This is clearly possible. As someone else said, the IL virtual machine is like assembly with some extra features. The things people worry about are efficiency and convenience.

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.

Haskell

[hoggy]

Given that one of the main brains behind Haskell now works for Microsoft Research and has always been a strong proponent of FP on commercial platforms - I'd be surprised as heck if the Glorious Haskell Compiler wasn't targetting .NET real soon.

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.

Re:Haskell

[hoggy]

Oops! forgot to mention that the "main brain" I referred to is the legendary Simon Peyton Jones.

Re:Haskell

[Jagasian]

Haskell, unlike Lisp, is a true functional programming language in that it only makes use of function abstraction and application for expressing computation, while Lisp uses sequencing of commands and assignments. Not only that, Lisp uses a form of evaluation which is not strongly normalizing, while Haskell uses lazy evaluation, which is commonly known to be strongly normalizing. This means that I could write the same function in either language, and the Lisp version would never hault (i.e. lockup, infinite loop, diverge, etc), while the Haskell version would run correctly to completion.

In addition, Haskell has an extremely powerful mechanism for catching software errors/bugs: a polymorphic type inference system. You don't even have to type the variables or functions yourself, the compiler can figure them all out automatically. This is a great form of software verification. Lisp is untyped. The point is that Lisp shouldn't be the poster-boy for Functional Programming. Haskell is far sexier. Haskell is free, well documented, and there are several good introductory books on it.

Basically my point is that Lisp should be taught as a language with a historical value, but when you want to teach someone functional programming, teach them a purely FP language like Haskell. http://www.haskell.org

Personally, I could give a damn about .NET/CLR and especially the appearence of FP or declarative languages on that platform. Most of the users of .NET/CLR are going to only know how to and only want to know how to program in one of two languages (C# or VB). I like to call that type of programmer "simple".

Re:Haskell

[hoggy]

That's the Glasgow Haskell Compiler, not Glorious.

Heh heh. I know. I was at Glasgow during a lot of it's development. "Glorious" was the local joke.

Re:Haskell

[Jagasian]

When I refer to Lisp, I am obviously referring to the common use and implementation of it. It addition, "dynamic" types do not form a type system that can be used for software verification, and therefore do not serve the original intent of type-checking. So yes, "typed" and "dynamically typed" are two totally different things that have names that are very similar. Other than that, a "dynamically typed" language is by no means strongly typed.

Re:Haskell

[divbyzero]

Of course Lisp should not be the poster-boy for functional programming. Lisp's great strength is that it is not rooted immovably in any single programming paradigm. As a language, it gives no favoritism to functional, procedural, declarative, or object-oriented styles. It handles them all in the same syntax, and has standardized or readily-available library support for features which make them respectively convenient to use. Particular implementations may well be have performance optimizations for one or the other of the above, but they are not inherent to the language.

Re:Haskell

[Jagasian]

Dynamic "types" are nothing more than extra pieces of runtime information, i.e part of the actual algorithm/program. Types are automatically inferred concepts used for (automatic) software verification. Types are NOT part of the actual algorithm/program. "Dynamic types" is an abuse of the word "type".

While "dynamic types" uses the word "type", it is far from the original meaning of "type" used by mathematicians such as Russell, Church, Curry, etc... "Dynamic types" only share a common word with true "types".

To claim that a "dynamic type" system is by any means a true type system is silly.

What a major Lisp vendor says:

[OOPChugALug]

I recall an interesting commentary on this very topic by a Lisp Developer at Franz:

See http://groups.google.com/groups?hl=en&frame=right& th=b55cb0947065a389&seekm=48zh6nn1q.fsf%40beta.fra nz.com#link2

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 .NET platform? Seems to me
> that Microsoft .NET is a wide-open side-door for Lisp to enter into IS
> 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, .NET is a framework in which
software is constrained to conform. Thus, we would have to change
our calling sequence, object, typing, and gc architectures to
conform to .NET's.

3. The result would be MS specific, and not portable to other systems.
This point is weak, because it is conceivable that .NET will be /
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.

Re:Real information

[brlewis]

undone9 wrote:

you lose tail-call optimizations, since the security model depends on the stack

Could you say more about this? Discussion on comp.lang.scheme said that the CLR does support tail calls, though support for continuations is not there.

Tail calls and dynamic typing

[yerricde]

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?

SML.NET

[Tom7]

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

Initialization speed and bytecode verification

[brad.hill]

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.

That's Because...

[Tom7]

That's just because nobody uses it. I program in functional langauges almost exclusively, as do some of my friends, and we're having a great time. I think a good marketing force behind one of the modern functional langauges could make it really soar -- Java is a pretty mediocre language that has met with great success essentially because of marketing.

Might as well use lisp/scheme (yes really)

[ajm]

As more and more "modern" (i.e. well known for at least 10 years outside of the "mixed ability corporate development team") features you get closer and closer to lisp/scheme. Once you add closures, which AFAIK, the clr doesn't, you effectively have lisp with a different syntax. Well whoopie. I'd make the "flamebait" statment that any language might as well be lisp/scheme or lacks some feature that lisp/scheme has. The converse, that lisp/scheme lacks something that vb,perl,python,java etc. already has, is not true.

.NET And Multipule Languages

[MissingNetLink]

Here is an interesting article to you who think your
language will get the same level of support under .NET http://www.javalobby.org/clr.html

Re:Lisp is also object-oriented

[hding]

Given that CLOS is part of the ANSI Common Lisp standard, this is hardly surprising; one can't claim to be standards compliant without providing it. :-)

Re:Terrarium

[ayjay29]

I've dabbled with Terrarium. It's pretty neat I think.
Don't try the "NakedBabe" option though, you'll just get surrounded by hungry carivores...

It's an ECMA standard.

[SteveX]

This isn't like Samba, where the Samba guys are basically reverse engineering a proprietary Microsoft protocol (CIFS aside.. it was never really intended to document all of SMB).

With C# and the CLR, well, it's an ECMA standard. Go look it up. And the ECMA standards group has policies that deal with patents on their standards...

- Steve

Re:It's an ECMA standard.

[pubjames]

With C# and the CLR, well, it's an ECMA standard.

That's a gross simplification. If you use C#, then you'll be using the APIs, which are not ECMA standards.

Re:It's an ECMA standard.

[SteveX]

True but it's unlikely that a patent would invalidate the entire class library. There may be specific algorithms in some of the classes that turn out to be patentable (though Miguel has said they're being careful about that), so if Microsoft says that some particular class is covered by a patent, then the folks implementing the Mono-compatible framework will just reimplement it.

The core stuff, the CLR and the language, are covered by the ECMA standard.

- Steve

well, not quite

[markj02]

Of course, you can implement any language on JVM and CLR (even C with unsafe features). The question is: how efficient is it going to be?

A compiler for Itanium or P4 can directly take advantage of instruction-level parallelism and hyperthreading, while going through CLR or JVM precludes that. That's particularly important for functional programming languages because they make exploiting such parallelism much easier than object-oriented languages.

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.

It's not going to be portable, folks

[nagora]

MS are not going to make .NET portable. How obvious does it have to be before idiots stop posting comments about how the future could be great if .NET is done well?

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

Re:It's not going to be portable, folks

[brunes69]

What are you smoking. .NET already portable. If the class definitions for any objects in the .NET api change, it is TRIVIAL to update these classes in Mono.

Re:It's not going to be portable, folks

[nagora]

.NET already portable.

Yes, part of .NET is already portable and it'll stay that way until after launch. Just long enough for three-time-losers to think that it's a "standard". Then MS will change it and all the little pointy-haired-bosses will run around shouting "we have to have Microsoft.NET, we can't risk hidden incompatabilities" and WHOOSH goes the Mono .NET subset into the dustbin of history.

To answer your first question: what I'm smoking is experience.

TWW

Re:It's not going to be portable, folks

[brunes69]

You don't understand the way .Net works. The entire API is made up of a set of base classes and their data objects and associated methods. Every single one of these classes will eventually be imlimented in Mono. If an accessor method changes, it is TRIVIAL to duplicate that in the corrosponding method in Mono. Even if MS decides to trash certain classes in favour of new ones, Mono can do the same, with even less amount of effort than MS, since Mono is just duplicating the API design, thilw MS had to design it in the first place. This is not the same as COM or MFC, not even close.

Re:cool but... why?

[wadetemp]

First, an interesting thing about this is that .NET really boils down to an XML parser/generator

No, not really at all. .NET is no more an XML parser/generator than the Microsoft platform SDK is. Yes, it includes an equivalent to the MSXML libraries, but it's basically the unreleased MSXML4.

Prolog...

[Gingko]

I have ported Prolog to the CLR. (A very naieve implementation, more a proof of concept). It was work done as part of my Microsoft student sponsorship dealie this summer.

It worked fine. Backtracking, lists, the lot. I implemented a marshaller to move data types from the CLR to Prolog, and extended Prolog with a couple of predicates to allow object instantiation from classes and method invocation. Syntax was a little ugly, but that can be fixed up. I think the semantics were fine.

So it can be done. Pretty easily, in fact.

Henry

They'll need to carry a patent notice

[yerricde]

well, it's a pretty safe bet that the .NET version of Visual Basic is going to generate code that makes calls to lots of Windows-specific, unpublished, and possibly patented API's.

"Unpublished" and "patented" are at a certain level mutually exclusive. if Microsoft wants to collect damages, Microsoft will have to put conspicuous patent notices on every single copy of Windows, or perhaps even require every developer that uses VB.NET to put patent notices on their software.

True, but largely irrelevant over time

[Ars-Fartsica]

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.

Re:True, but largely irrelevant over time

[Ars-Fartsica]

So essentially the CLR and the .NET framework on top of it must necessarily be the most productive way of producing code?

No, I'm not sure that will be the case, but it could end up being the most popular, which is likely more important. I share some of your concerns that this may wipe out some innovation in language features, but I have long held the opinion that programming is ultimately a dismal profession and MacCode (a pun on MacDonald's) is the future.

However because imperative languages lack a read-eval loop, it is a nontrivial exercise to turn parsed code into a callable function, a trivial exercise in LISP.

But this debate has already been played out. LISP has numerous cool features, but it is dead in the marketplace. I don't think the coolness of LISP is going to change anyone's life or share price at this point in any case.

Nonetheless you make some good points and I think your posts are very well-informed, I just strongly believe that market forces are shaping programmer tools more than technical excellence. Java seems to bear this out.

Re:hmm... do me a favor

[elflord]

When they have locked a minor detail which marketing departments view as "essential", be it a nice graphical widget or whatever, they will be recomending their respective managers to switch to the MS technology that supports it.

So what ? They could also add a "graphical widget" to perl, C++, C, or any other standard. Why is C#/.Net any different ? There are these silly comments on how Microsoft could sink the standard by adding proprietary or even patented extensions, but they can in fact do the same to any standard. I think most of the Mono bashers are blinded by their pent up anti-MS rage.

Re:No its Bill Gates that is Stupid

[bryanbrunton]

I agree with you on patents in .NET.

But clearly the biggest mistake that Gates and his evil hearted minions made was to bring the eye of the government upon themselves before they had the key components of their next generation framework inside a patent protected harbor.

Consider this alternate reality: Microsoft doesn't blow its sham of a business model in a quest after meaningless web browser market share. It instead safely lies low preparing .NET with many of its key components patented.

And prior to .NET, in this alternate realm, Microsoft could successfully have been enforcing patent claims against open source technologies like SAMBA without fear of the DOJ boom coming down upon their actions. WINE would have been obliterated many years ago in a flurry of lawsuits. Tools that were even tangently related to any of MS patents could have been targeted.

We should be pleased that Microsoft didn't have the intelligence and forebearance to pull something like this off. Open source wouldn't be nearly where it is today. As to whether they can turn the patent tables in their favor in the future, is yet to be seen.

Re:GNOME and .NET change of heart - another idea

[TheAwfulTruth]

Coming from someone that has spent years writing cross platform code for Linux, Windows and even the Mac, I say:

Go ahead! There's NOTHING wrong with that! If I want to write a Gnome only program I'll gladly take advantage of additional tools. If I want to write a cross platform program I'll stick to the cross platform set. I'm an engineer, not a fucking moron. I KNOW what will and won't work cross platform via docs and trial and error (Much like developing HTML). This is the exact situation with MS's extended Java. EXACTLY. It was MY choice as a developer to go windows only or cross platform. That wasn't evil in any way, just like Gnome extending .NET is not evil in any way. It would be NICER if everyone developed everything lockstep, but Sun was glacial about providing additional features that they didn't see a use for. So move aside Sun...

If MS doesn't go fast enough for the Gnome crew (Though I seriously doubt that would happen) then they can fill in as needed. In fact, even if I could write 90% of the code commmon for all platforms and 10% customized for the platforms I wanted to support. That would be infinately better than not having it at all.

.net will help

[EnglishTim]

Hopefully .net will help.

I'll be able to write my programs using a mixture of stuff - Prolog for what it's good for, C++ (or C#) for what it's good for, Python for what it's good for. I'll be able to follow the program through in my debugger irrespective of what that part of the code is written in.

No more of that annoying glue code (or at least, not much...)

I'm looking forward to it.

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:Why Functional Programming Matters

[Kanasta]

What I remember about Functional Programming is the lack of variables for temp storage.

As a result, everything is recursive. It was very difficult to write iterative versions of functions, and when you finally wrote them, they were hard to read.

The recursive version is easy to read (and maybe maintain?), but very slow. Maybe it was just our platform.

It was a pain to write. It's probably not worth the benefits it your $50/hr programmer has to spend double the time to write your programs.

Re:Why Functional Programming Matters

[dstone]

It's probably not worth the benefits it your $50/hr programmer has to spend double the time to write your programs.

Very true. So don't hire an imperative specialist to write functional code! If you believe that it would still take a functional specialist twice as long to write functional code then I'd like to get a link to some supporting evidence or case studies.

Hell is freezing over and pigs are sprouting wings

[telstar]

Could it be? Are there some positive posts regarding a Microsoft technology on Slashdot?

I've just started to scratch the surface of what .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.

Yup...

[Da VinMan]

And that simply emphasizes (yet again) that the problem with most programming languages/IDEs isn't the languages or the tools; it's usually the culture of the users of that language or tool.

I could go on and on, but I will just contain the rant.

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.

Beg to differ!

[krokodil]

Prolog is NOT functional language. Prolog is logical programming language. LIST is functional programming language.

Why on the earth people keep confusing PROLOG and LISP?! They are so different.

Now on the subject: Prolog is not generic programming language which could be fit into generic-purpose VM. It requires quite specific algorightms implemented in VM (Unification, Resolution) which are of little interest to other languages. Yes, they could be put into VM, but this is like putting regex library there.

Lisp is different. There was talks about putting it to Java VM, so I guess it will be possible to put it into the .NET.

Re:Beg to differ!

[An Ominous Coward]

unable to address functional and logic languages such as Prolog and LISP.

Jumping to make yourself look smart generally results in the opposite.

Re:Beg to differ!

[Courageous]

Prolog is logical programming language...

Well, sort of. Prolog belongs to a family of programming languages sometimes referred to as "evaluative". It doesn't pay to worry about these things too much, however. Some people look at things differently, and by some ways of conceiving the world, Prolog is validly considered a functional language with a very limited kind of function: a predicate.

C//

SML vs O'Caml

[Tom7]

OCaml and SML are different languages, OCaml is the one implementation of OCaml (...) and SML/NJ is one of many implementations of SML. Some other SML implementations worth checking out are MLton, Poly/ML, Moscow ML, and (soon) TILT/ML.

I don't know of any other mature ML dialects (though there are plenty of spin-off languages).

Personally, I like SML the best, but here's the rundown.

Here's some reasons to prefer SML:
- Many more compilers on (I believe) more architectures. There are something like 10 SML compilers vs 1 for caml.
- A more stable, thoroughly designed and defined language. Caml's is defined by the implementation and docs, and changes somewhat frequently (though the core language usually stays the same).
- A fancier module system
- More aesthetic, I think.

Here's some reasons to prefer O'Caml:
- Faster? Their native code compiler is awfully good. I think mlton (for SML) can stand up to it pretty well, but caml's is probably faster for most stuff.
- More hacker-oriented; it has stuff that's pretty difficult to justify from a theoretical or aesthetic perspective, but which is useful in practice. One example is a C-style "printf" keyword.
- One compiler and one platform means a rallying point for tools and libraries, so I think they are somewhat richer in this area.

Either way, you'll be able to do almost anything you want. All SML compilers I know of have C library interfaces, so you can pretty easily hook into libraries when you write your programs. I think it's mostly a taste issue..

Re:hmm... do me a favor

[elflord]

No, you couldn't add it if it's been copyrighted.

I don't understand this comment. They can't directly add anything to the ECMA standard either, because they don't have control over it. They can make changes to their implementation, but they can do (and have done) the same with C and C++.

But if they extend a widely supported, if not by then market dominant, standard that they own... then I think we're in deep sh*t...

They don't "own" it. That's the whole point of being standard -- it implies that it's not "owned". If it's well supported and market dominant, that's actually a good thing, because that will imply that there are several implementations, which will imply that the standard will have more active participation from third parties.

Slashdotted Slashdot?

[Bodrius]

Am I the only one who has to reload each page of this thread three times to avoid the "Cannot connect to server" little pagey?

Can slashdot be slashdotted?

Re:Biggest oxymoron?

[Courageous]

Functional programming languages not only remove the need for most of that hardware, they are also nicer to program in.

A categorical claim that a functional programming language is "nicer to program in" is the kind of question that begs for evidence. Presumably since speed of learning and so forth are measurable, you'd only make a claim like this if you thought some psychologists somewhere had studied the phenomenon. Of course, it's far more likely that you mean "I personally find functional programming languages easier to program in" and that you're just an unusual MIT mutant. Given the hordes of sorry meatheads programming in VB by preference, I'm afraid I view it likely that your statement is not exactly right. I think it's most likely that people actually think imperatively (and I'm admitting that's just an educated guess, but I think it's a good one, what do you think?). Hence that's why programmers prefer languages that give them imperative forms. It also explains the relative paucity of Lisp and especially Prolog programmers, wouldn't you say?

C//

Re:Biggest oxymoron?

[markj02]

Well, I would think that anybody can figure out that "nice" expresses a personal preference.

But there is a real question: why do people use imperative programming languages so much? I think a big part is that, for old-style processors, they were a good match. That's why there were taught, and that's why our whole industry is built around them. And regardless of what the cause of their preference, the "hordes of VB programmers" simply aren't producing very good code, and a lot of that has to do with bugs due to imperative features.

The problems that people have with SML, Haskell, Prolog, and Lisp, are not due to their functional (=non-imperative) features but their syntax, their type systems, their support for higher-order functions, and their complexity. It is possible to design functional programming languages that are easy to use. Non-academics seem to have no trouble with the significant functional (=non-imperative) feature sets of Logo, Tcl, Splus, Fortran2000, XSL, SISAL, and PHP.

Re:Continuations & Scheme

[daytrip00]

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.

Re:Biggest oxymoron?

[Courageous]

The problems that people have with ... Lisp...

How many large Lisp efforts have you worked on? Modern Lisp as realized by industry is dominated by classical imperative programming style as realized from within what is otherwise claimed to be a functional language. It's just not so in practice. Modification by consequence and imperative forms exist everywhere. That's just how it is.

In your list of languages which have functional aspects, you neglected to mention C. While indeed programmers have little trouble with the functional aspects of these languages (C, Tcl, PHP) that nevertheless isn't by any stretch the dominant realization of these languages. Imperative style rules the day. I believe that this reflects the way that human beings actually think:

Do this to that.

It's a common thought pattern.

C//

HotSpot beats VC++?

[Anonymous Brave Guy]

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.

Cite, please?

I'd be very interested to know what technology is letting you beat Visual C++, since that's what we develop with at work. (But please tell me you're not comparing brand new Java 1.4 systems to the years-old Visual C++ 6 and not the just released Visual C++ .NET.)

Re:Biggest oxymoron?

[markj02]

You implied that Lisp is a functional programming language, not me. I agree with you that you are wrong.

Imperative style rules the day. I believe that this reflects the way that human beings actually think.

Well, and I believe that you are wrong on this one, too. First, most knowledge people have is declarative and rule based, nor procedural. Second, from teaching students, it's clear that they have no problem with expressing themselves declaratively or functionally. Third, in my experience, the majority of non-trivial bugs in software systems are due to aliasing, unexpected state changes, and race conditions, so I would argue that people are very poor at imperative programming.

Re:GNOME and .NET change of heart - another idea

[ahde]

The problem is, right now *if* Ximian fully implements Mono as planned, and Microsoft doesn't expand their functionality at all, the numbers are 75% customized for Windows already. 900 classes in the ECMA spec vs. around 3600 in the current Microsoft implementation.

Re:Biggest oxymoron?

[Courageous]

While indeed programmers have little trouble with the functional aspects of these languages (C, Tcl, PHP) that nevertheless isn't by any stretch the dominant realization of these languages.

Since you avoided this sentence, I'll assume it was too much of a hot potato for you. It's true, though, you know? What you're failing to realize is that functional programming languages aren't popular for a reason: they aren't popular, because largely people don't like them.

C//

Re:Real-world speed comparison

[SimonK]

Yes, but only because they didn't use an application server (after all .NET actually has no such thing), but they put all the application logic in stored procedures. If you implemented the equivalent J2EE application using JSP and stored procedure's you'd probably get similar performances. C# will probably always need less code, although most of the code (other than the actual application logic) they got rid of is trivial getters and setters.