Functional Languages Under .NET/CLR

fp dork by Anonymous Coward · 2002-02-07 02:33 · Score: -1, Offtopic

fp

First Donkey by DonkeyHote · 2002-02-07 02:33 · Score: -1

Fr0st P1st!

fp by Anonymous Coward · 2002-02-07 02:33 · Score: -1, Offtopic

fourth post!

Big deal by October_30th · 2002-02-07 02:34 · Score: -1

Having to learn the incomprehensible functional language like Scheme made me to switch from CS to Physics.

Good riddance to that crap.

--
The owls are not what they seem

Re:Big deal by tundog · 2002-02-07 02:38 · Score: 0, Offtopic

What I don't get about Physics is, years after my last U-Grad Physics course I STILL havn't found that frictionless frozen pond.

--
All your base are belong to us!
Re:Big deal by October_30th · 2002-02-07 02:41 · Score: -1

Well, well. What you know. I in turn haven't found a real-life application written in LISP or Prolog.
Goddamn. A language that favours recursion over iteration and in which the use of variables is considered a bad habit deserves to die.

--
The owls are not what they seem
Re:Big deal by Anonymous Coward · 2002-02-07 02:46 · Score: 0

you just dont know where to look. it is right next to the perfect sphere and the infinitely long cylinder.
Re:Big deal by Eponymous,+Showered · 2002-02-07 03:06 · Score: 1

The Gimp
DSSSL

Both developed in Scheme
Re:Big deal by October_30th · 2002-02-07 03:09 · Score: -1

Yeah, and Emacs too.
With "real-life application" I meant something the people are actually willing to buy.

--
The owls are not what they seem
Re:Big deal by Eponymous,+Showered · 2002-02-07 03:59 · Score: 1

If they are willing to buy it, then it has to be for sale. If it is for sale, then the source is (usually) closed. If it is closed, we have no idea what it's written in. For all we know, MS Office XP is written in a combination of Scheme, Haskell, and Mondrian.

I was wrong about The Gimp. Not written in Scheme. Script-Fu uses Scheme. My bad.
Re:Big deal by Anonymous Coward · 2002-02-07 05:45 · Score: 0

A language that favours recursion over iteration
This needs rephrasing: your obviously deficient teacher favoured recursion over iteration
Re:Big deal by Anonymous Coward · 2002-02-07 13:08 · Score: 0

Lisp does not favor recursion over iteration, and Lispers do not think that use of variables is a bad habit. You're thinking of Scheme, which is a different language entirely. (But even Schemers don't think variables are bad!) For some information on software written in Lisp, see www.lisp.org and Franz success stories.

Terrarium by Anonymous Coward · 2002-02-07 02:38 · Score: 0

The Terrarium game alone is enough to make me try .NET

I'm probably going to loose badly but I'll keep on trying. I'll probably use the : [assembly: OrganismClass("NakedBabe")]

Re:Terrarium by JWSmythe · 2002-02-07 02:42 · Score: 1

I read and reread the available materials on Terrarium. I want to play too, but it really looks like a cheap way to get Joe-Admin to install the .NET framework on his system. They say you need to have your Terrarium on a high-availability machine, if you plan to win. For most people, their home machine isn't going to do, it's going to be a server. Look, now they have .NET installed on x-million web servers. :)

I tried to submit the Terrarium project as news, but aparently my karma isn't good enough to be considered yet. :)

I'm putting up an old back-end server just to play.. Something that I don't mind formatting afterwards, just to get rid of .NET . Our networks are Linux based, we only have a few legacy NT servers left (and lots of licenses to reinstall! Yippie!), so I won't be using .NET for future development.

--
Serious? Seriousness is well above my pay grade.
Re:Terrarium by ayjay29 · 2002-02-07 04:34 · Score: 2

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

--
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated up.

Look deeper... it's not that bad. by SID*C64 · 2002-02-07 02:38 · Score: 2, Informative

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.

Who cares? by Anonymous Coward · 2002-02-07 02:38 · Score: -1, Flamebait

Prolog and Lisp don't fit the .Net model anyhow. So who really gives a rip? Real programmers will use C#, C++ and C.

Java is for lamers!

Re:Who cares? by Anonymous Coward · 2002-02-07 02:48 · Score: 0

Haha you weenie.. Real programmers will use C#, C++ and C.. May I laugh in your face? You're considering C for real programmers? You obviously have never heard about The Story Of Mel... C.. pff
Re:Who cares? by Anonymous Coward · 2002-02-07 03:02 · Score: 0

.
You should say "unless you call it MS C# " .

The first 2 letters are the decisive ones for market adoption. :-)

The following ones can be anything you like: C# J# Cool# ... who cares...

Very Beta by Mattygfunk · 2002-02-07 02:39 · Score: 1

At this point it is still an alpha-quality release; it's hard to install, there are still many parts of the standard library which are not yet implemented for this port, it's not well tested, not yet efficient, and undergoing continual change in our development snapshots...

I think that it may just be a little early to have a release at all considering all that.

Re:Very Beta by monkey_jam · 2002-02-07 06:06 · Score: 1

At this point it is still an alpha-quality release; it's hard to install, there are still many parts of the standard library which are not yet implemented for this port, it's not well tested, not yet efficient, and undergoing continual change in our development snapshots...

And this is different from a microsoft release, how?
boy, i love microsoft.
Re:Very Beta by GunFodder · 2002-02-07 08:33 · Score: 1

Microsoft never releases anything that by current standards is hard to install. Remember who their user base is.

Comment removed by account_deleted · 2002-02-07 02:40 · Score: 0, Offtopic

Comment removed based on user account deletion

GNOME and .NET change of heart by Marx_Mrvelous · 2002-02-07 02:40 · Score: 4, Funny

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.

--

Moderation: Put your hand inside the puppet head!

Re:GNOME and .NET change of heart by October_30th · 2002-02-07 02:44 · Score: -1

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.

--
The owls are not what they seem
Re:GNOME and .NET change of heart by Masem · 2002-02-07 03:00 · Score: 5, Insightful

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.

--
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Re:GNOME and .NET change of heart by October_30th · 2002-02-07 03:03 · Score: -1

release code that would run on 100% of the computers out there, not just 95%, would be a godsend
But slow as molasses as shown by the existing Java applications.

--
The owls are not what they seem
Re:GNOME and .NET change of heart by woodja · 2002-02-07 03:34 · Score: 1

Did Miguel write a response to RMS & the article in the Register? If so, what is the link to that article.
Re:GNOME and .NET change of heart by tempest303 · 2002-02-07 03:38 · Score: 1, Offtopic

how the hell was this modded down as a Troll? fscking stupid moderators...

--
The Free desktop that Just Works
Re:GNOME and .NET change of heart by Malc · 2002-02-07 03:48 · Score: 1

I agree: I was so excited when I first read about Java, and when I first tried it. To bad it fizzled so much. Who knows, maybe there is still hope for it, or maybe it will be marked down in history as one of those "languages" that helped popularise the next big one, like Smalltalk for example.

MSFT seem to deliver more practical solutions from a business perspective, that tend to be more evolutionary than revolutionary. Whether or not this lives up to Java's promise, it's pretty exciting, even if it only results in a new incompatibly development framework/environment.
Re:GNOME and .NET change of heart by Marx_Mrvelous · 2002-02-07 03:51 · Score: 0, Troll

Slashdot moderation is unreliable, you didn't already know that? That's why we need meta-moderation, to moderat the moderators.

99% of "overrated" are just jealousy, and 99% of "Troll" are people who disagree with your opinion. It's just the way slashdot works.

--

Moderation: Put your hand inside the puppet head!
Re:GNOME and .NET change of heart by Marx_Mrvelous · 2002-02-07 03:57 · Score: 2

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.

--

Moderation: Put your hand inside the puppet head!
Re:GNOME and .NET change of heart by tempest303 · 2002-02-07 04:04 · Score: 1

Oh, I knew, but it doesn't make me any less pissed off about it. ;)

I had a similar change of heart about exploring a .NET clone in Mono after reading Miguel's extended statement on Mono and Gnome, so I was, in part, sympathizing with my comment...

oh, well...

--
The Free desktop that Just Works
Re:GNOME and .NET change of heart by kin_korn_karn · 2002-02-07 04:27 · Score: 3, Interesting

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 by rabtech · 2002-02-07 05:14 · Score: 5, Insightful

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.

--
Natural != (nontoxic || beneficial)
Re:GNOME and .NET change of heart by elflord · 2002-02-07 05:28 · Score: 2

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 by Morphine007 · 2002-02-07 05:50 · Score: 1

Those are PUBLICLY AVAILABLE INTERFACES. There is nowhere to "HIDE" windows-only hooks

In case you haven't been paying attention, we know all this, what we're afraid of is the following scenario:

MICROSOFT: now that you've made the switch so that 50% + of your apps are using our "publicly available interfaces" we're going to close them and change the interface so your shit won't work anymore...

EVERYONE ELSE: but...but... you can't!!

MICROSOFT: so sue us?... I'm sure in 4 years when the case is settled we'll be more than happy to open it all back up again.... 's just too bad we'll have 99% market dominance... but hey; that's life right?

... or am I just being paranoid?

--
Oh god, that woman is John Romero!
Re:GNOME and .NET change of heart by Anonymous Coward · 2002-02-07 05:51 · Score: 0

One thing about java, and why I think java fails to live up to its potential is that the VM is explicitly designed to support java only. I was at a talk given by Larry Wall, and he mentioned a discussion he had with Gosling where he asked Gosling if he had specifically designed the VM to make it "impossible" to implement a C compliler. Gosling's answer supposedly was "yes". This always springs to mind when I read posts about java already providing a VM and that the .NET VM is needless duplication. The java VM is not simply platform-independent byte-code, it is platform-independent byte-code that enforces OO methodology.
Re:GNOME and .NET change of heart by ClosedSource · 2002-02-07 05:53 · Score: 2, Insightful

"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 by Anonymous Coward · 2002-02-07 05:58 · Score: 0

This would also break existing windows applications of course, so I don't see them doing it.
Re:GNOME and .NET change of heart by Anonymous Coward · 2002-02-07 06:09 · Score: 0

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!

Do you enjoy being wrong? There's no scam on the Indian side of the equation - their computer scientists are willing to work in the United States for lower wages.

George W. Bush is irrelevant to the issue. After all, the practice peaked during the Clinton years. Currently, due to the economic downturn and increased xenophobia and disappearance of many "new economy" companies, many H1B workers have been fired, are at risk of being fired, and are despereately searching forvisa sponsors. Congress is responsible for increasing the number of H1B visas granted, which they did under pressure from software companies. Partly because foreign labor is cheaper and easier to dominate (80 hour work week, no overtime pay, or I'll have you deported), partly because there is (was) a shortage of domestic labor.
Re:GNOME and .NET change of heart by Anonymous Coward · 2002-02-07 06:16 · Score: 0

Although the method signatures may not change, their behavior may, or there may be undocumented behavior for certan values of arguments.
Also, Microsoft could also add classes or methods that only their own developers have documentation for. So, they could create Office.NET, but it would only run on MS's .NET even if another implementation had all the documented APIs.
This is what MS has done with the Win32 API, and why it is so difficult to create a windows emulator/clone.
Re:GNOME and .NET change of heart by smittyoneeach · 2002-02-07 06:21 · Score: 1

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.

This is how you use Linux to advertise 'Doze. Get everyone to buy in at the API level, only to discover that, magically, for reasons buried deep in the implementation, stuff just kinda runs faster on 'Doze.
The counter argument is that the Open Source community can take the same APIs and implement them more efficiently elsewhere.
Thus, if you're Mr. Softy, you have to innovate at a higher frequency than the OS community.
Will history discover that the MS tortise can beat the OS hare, given a sufficient lead?

--
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Re:GNOME and .NET change of heart by arn@lesto · 2002-02-07 06:44 · Score: 1

Microsoft's implementation of the CLI could (and probably already does) have extra instructions that are not documented publicly. MS could then produce a .NET module that uses them but doesn't work on other implementations of the CLI.
If you want to gain the same advantage then you'll have to licence the info from MS because they'll have the instructions patented. If the module is critical to the .NET world then MS has effectively locked people onto their platform because that module doesn't run on other CLI platforms.
This is exactly what MS was trying with the Java VM before Sun stopped them.

--
- AndrewN
Re:GNOME and .NET change of heart by Courageous · 2002-02-07 07:28 · Score: 2

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 by Courageous · 2002-02-07 07:32 · Score: 2

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 by Anonymous Coward · 2002-02-07 07:39 · Score: 0

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 . . .
Re:GNOME and .NET change of heart by Anonymous Coward · 2002-02-07 08:05 · Score: 0

"To bad it [Java] fizzled so much."

Say what? I saw a study predicting that by the end of this year more programmers will be using Java than any other language. Even if that's not true, in just the last couple of years Java has become THE preferred language for web apps, replacing bug prone CGI methods with JSP and Servlets, now it's poised to dominate the wireless world with JME, and it's just a matter of time before Swing apps become more popular as further optimized JVMs and faster PCs replace the older/slower ones.
Re:GNOME and .NET change of heart by kin_korn_karn · 2002-02-07 08:17 · Score: 2

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 by elflord · 2002-02-07 08:20 · Score: 2

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 by kin_korn_karn · 2002-02-07 08:22 · Score: 1

not enough xenophobia, AFAIC. With the fall of the dot coms there is NO shortage of domestic labor, there's a glut. that drives my salary down one notch. then come the H1Bs, driving my salary down another notch while filling the gaps that I used to fill.

Same thing happened in every other industry. My dad works for one of the few surviving big steel companies, They're half-Japanese now. Jap steel was far cheaper when Reagan dropped the tariffs.

fortunately, I'll be out of this chickenshit industry in a few years, at the most.
Re:GNOME and .NET change of heart by Courageous · 2002-02-07 08:30 · Score: 2

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 by elflord · 2002-02-07 08:31 · Score: 3, Informative

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 by PhiRatE · 2002-02-07 08:39 · Score: 2

P/Invoke

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

--
You can't win a fight.
Re:GNOME and .NET change of heart by anshil · 2002-02-07 09:03 · Score: 1

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

Things that target in thought about how windows is particular implemented, and are hard to rebuild on other systems that use other techniques.

Take in example drive letters, you have them in unix after all? No. Take in example functions accepting backslash paths. Take any API functions that build upon the messaging concept windows uses. You have to workaround it hardly to rebuild it for X. Take direct-X hooks. Take IE library hooks. (Sure you want to have some sort of HTML pane do you? Now they would be suprising if they didn't use the IE libs for that would it)

--

--
Karma 50, and all I got was this lousy T-Shirt.
Re:GNOME and .NET change of heart by kin_korn_karn · 2002-02-07 09:08 · Score: 2

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 by Anonymous Coward · 2002-02-07 09:26 · Score: 0

Actually, Sun does add undocumented features to its JVM which most of its class libraries use. If you're interested, go take a look at the GCJ page about why they can't.
Re:GNOME and .NET change of heart by Courageous · 2002-02-07 09:36 · Score: 2

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 by Anonymous Coward · 2002-02-07 09:53 · Score: 0

What I don't understand is, what is the advantage gained by creating a .NET VM over a JVM? Is there some slack that's not being taken up by the JVM? And what if there are VM instructions and then VM instructions for the rest of us? And what about the authentification issues, and the software licensing issues. I don't see how this is going to be functionally any different than Java. And what about the information leakage built into all MS products these days? The creepiest thing of all is hearing someone carry on like this on SlashDot.
Re:GNOME and .NET change of heart by kin_korn_karn · 2002-02-07 10:00 · Score: 1

The loss of American business to foreign countries will hurt you more than any system of immigration ever will.
The world wasn't a dead piece of rock before the Internet boom, though. Sure, we didn't have this "wonderful" global village thing going on, but we did have stability and we knew what was important. I can't believe I'm thinking this way, anti-technology, but tech and tariff games and global trade has made the the USA sell out its own people.

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.
It's the soft conquest that's going to kill us. The USA, functionally speaking, owns the world. If you think of the Earth as a corporation, the USA is the majority shareholder (and 9/11 was a crazy ex-employee coming to work with an AK-47, but that's a digression). The analogy then could be drawn with a company that loses interest in its basis for existence and over-diversifies until their core is dead. Think of Eastman Kodak. I understand GE went through something like that before Welsh raped the place and started over. I could be totally off base, that was well before I could comprehend this stuff.

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.
Economics divorced from the society in which it applies is suicidal. The people ARE the economy. Without us the economy wouldn't exist. Take care of us and the economy will take care of itself.

While I understand how [facing unemployment]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.
Who cares about them?!?! the world revolves around me!! :)

Hell, even having a sense of humor is hard right now.

I'm sorry you're going through a tough time.
Yeah, so am I. I was stupid and counted on luck and made the fundamental mistake of relying too much on people that had no reason to support me. All of which are personal issues.
Re:GNOME and .NET change of heart by Anonymous Coward · 2002-02-07 12:16 · Score: 0

uhhh..dude..maybe the indians and chinesease smarter? lol
Re:GNOME and .NET change of heart by Tsujigiri · 2002-02-07 17:08 · Score: 2

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.

--
"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
Re:GNOME and .NET change of heart by Anonymous Coward · 2002-02-07 17:44 · Score: 0

This is more for calling "legacy" code. I try to avoid P/Invoke and COM Interop at most all costs.
Re:GNOME and .NET change of heart by DodgyGeezer · 2002-02-07 18:16 · Score: 1

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)? That's right, to provide a welfare safety net that ensures that your family is provided for. If you don't like your current situation, vote for a governement that will fix this situation, or move your family to a more caring country that places human needs above greed and money.

BTW, I might sound unsympathetic... I'm not. I understand your situation: I have a friend in Denver who was unemployed for a similar length of time until a couple of months ago. His wife was an intern, and he has three children. I've never seen a man get so desparate. He ended up accepting a huge paycut.

The USA is a great country if you're wealthy. It sucks if you're not, and it's a downright disgrace if you're unemployed and low on funds.
Re:GNOME and .NET change of heart by DodgyGeezer · 2002-02-07 18:35 · Score: 1

> > The loss of American business to foreign
> > countries will hurt you more than any system
> > of immigration ever will.
>
> The world wasn't a dead piece of rock before the
> Internet boom, though. Sure, we didn't have this
> "wonderful" global village thing going on, but
> we did have stability and we knew what was
> important. I can't believe I'm thinking this
> way, anti-technology, but tech and tariff games
> and global trade has made the the USA sell out
> its own people.

Stability? Good lord man! Don't you remember the recession in the early 90's right before the internet boom? You know, images of union workers on strike, la-dee-da-dee-dah. Before that, there was Reagan calling USSR the "evil empire". There have been many many nasty recessions, just like this one or worse. There's been lots of instability, such as the 70's oil crisis, or the Cuban missile crisis, or Pearl Harbour. Get with the programme: things are bad for you right now and you're staring down the barrel, but really, is this bigotry and small-mindedness really necessary? You could have been in this situation many a time before the internet boom. Nothing has changed. If you don't want this to happen again, pay more taxes and get a goverment that will provide a safety net for it's citizens instead of options for going of to war.
Re:GNOME and .NET change of heart by DrSkwid · 2002-02-08 00:37 · Score: 2

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

move to India?

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Re:GNOME and .NET change of heart by Courageous · 2002-02-08 06:42 · Score: 2

...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 by Courageous · 2002-02-08 06:48 · Score: 2

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 by elflord · 2002-02-08 13:09 · Score: 2

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 by Tsujigiri · 2002-02-09 14:25 · Score: 2

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.

--
"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
Re:GNOME and .NET change of heart by Courageous · 2002-02-09 17:21 · Score: 2

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 by Tsujigiri · 2002-02-10 11:45 · Score: 2

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.

--
"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
Re:GNOME and .NET change of heart by Courageous · 2002-02-11 06:42 · Score: 2

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 by einhverfr · 2002-02-13 08:16 · Score: 2

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

--

LedgerSMB: Open source Accounting/ERP

It changes no ones mind by Anonymous Coward · 2002-02-07 02:40 · Score: -1, Troll

because .net is microsoft, .net is evil.

a beowulf cluster... by Anonymous Coward · 2002-02-07 02:42 · Score: -1, Flamebait

running functional programs on .NET would still be outperformed by my commodore 64

Re:a beowulf cluster... by gazbo · 2002-02-07 04:07 · Score: 1

Junis' C64 is faster than any beowulf cluster.

I hear MD5 hashes physically tremble at the thought of being cracked by our wacky Afghan friend.

Nice linking there again by Anonymous Coward · 2002-02-07 02:44 · Score: 0

"To this end I would like to drawn peoples' attention to two resources,"

The first link has nothing about "peoples' attention", and "two resources" has only one document linked. Where's the other resource?

What's with Slashdot and stupid/misleading linking..

Mondrian for .NET by cdmoyer · 2002-02-07 02:44 · Score: 4, Informative

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.

--
/* CDM */

Re:Mondrian for .NET by Morphine007 · 2002-02-07 03:34 · Score: 1

Mondrian is a modern, purely functional language specifically designed to leverage the possibilities of the .NET Framework.

AAAAUUUUGGGGGHHHH!!! ENGLISH MUTHAFUCKA; DO YOU SPEAK IT!!??

*sigh* ... almost makes me want to take up gardening and stay away from CS....

--
Oh god, that woman is John Romero!
Re:Mondrian for .NET by djelovic · 2002-02-07 03:39 · Score: 1

The thing that bothers me about Mondrian is that it uses only boxed data types, which are all allocated on the heap. That's gonna hurt the performance badly.

I once tested Java's int vs. class Integer for some matrix calculations. Calculations using the class Integer was 16 times (!) slower.

Dejan
Re:Mondrian for .NET by Graspee_Leemoor · 2002-02-07 04:17 · Score: 1

"almost makes me want to take up gardening and stay away from CS...."

You're kidding, right? Have you heard two hardcore gardeners have a conversation? It's just as geeky, jargon-filled and ultimately pointless conversational masturbation as a slashdot story on .net!

In fact, if you ever check out the letters page in a specialist magazine (no, not those ones) e.g. Land Rover Monthly or Model Aeroplanes Weekly or whatever, you'll recognize the style immediately- there is an underlying similarity running through all specialist hobbies (which may or may not have commercial applications).

I think it's a testosterone thing.

graspee
Re:Mondrian for .NET by jovlinger · 2002-02-07 04:39 · Score: 2

well, that does explain the motivation behind the ILX website design...
Re:Mondrian for .NET by jovlinger · 2002-02-07 04:53 · Score: 2

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.
Re:Mondrian for .NET by Morphine007 · 2002-02-07 05:15 · Score: 1

You're kidding, right? Have you heard two hardcore gardeners have a conversation?

hehehe... no can't say that I have. I still maintain my point though; I'll be looking through something as inane as a job offering and can't help but laughing at myself for having to reread the offering about 4 times just to convince myself that it really is written in english. ;)

--
Oh god, that woman is John Romero!

Who thought this? by saforrest · 2002-02-07 02:45 · Score: 2, Insightful

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? by relinquish · 2002-02-07 02:52 · Score: 3, Informative

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.

--
Relinquish
Re:Who thought this? by Anonymous Coward · 2002-02-07 02:54 · Score: -1, Offtopic

You are way fucking off track.
Re:Who thought this? by entrox · 2002-02-07 02:57 · Score: 3

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.

--
-- The plural of 'anecdote' is not 'data'.
Re:Who thought this? by JamesOfTheDesert · 2002-02-07 02:59 · Score: 2, Insightful

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.

--

Java is the blue pill
Choose the red pill
Re:Who thought this? by Pussy+Is+Money · 2002-02-07 03:25 · Score: 0

The question is not whether you can "write .NET" using a functional language. The question is whether you can take your Lisp program, run it through a .NET-aware Lisp compiler, and end up with something useful (i.e. suffering only minimal loss of functionality and no more than acceptable loss of performance).

--
Pushin' 'n dealin', shovin' 'n stealin'
Re:Who thought this? by affenmann · 2002-02-07 03:26 · Score: 2, Informative

> 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? by Anonymous Coward · 2002-02-07 03:47 · Score: 0

Glasgow Haskell Compiler?
Re:Who thought this? by RedGuard · 2002-02-07 04:02 · Score: 1

MS have kidnapped Britain's entire population
of functional language designers.
Re:Who thought this? by smallpaul · 2002-02-07 04:08 · Score: 3, Insightful

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? by jwpalmer · 2002-02-07 04:09 · Score: 4, Insightful

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? by guinsu · 2002-02-07 04:37 · Score: 3, Interesting

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).
Re:Who thought this? by jovlinger · 2002-02-07 05:01 · Score: 1

1) the lifetime of objects is a GC issue. Generational collectors deal very well with short lived objects. Which GC scheme a VM uses is an [important] impl issue, not language design.

2) The tailcall is critical for pretty much all functional languages. However, the stack inspection used by Java's security model interacts poorly with tailcail optimization. NET apparently uses a similar scheme. There are ways around it, but they are system wide.
Re:Who thought this? by affenmann · 2002-02-07 06:24 · Score: 1

Your points are valid, but note also that objects in the JVM (and presumably .NET) are heavier than neccessary, thus making the allocation of new objects more costly. (The problem being that (higher-order) functions are often compiled to classes, which is clearly to heavyweight)

Quoting from Meeham,Joy:"Compiling Lazy Functional Programs to Java Bytecode":
Wakeling ascribed the poor performance of his compiler when compared to Hugs to the poor memory handling in the JVM, hypothesising that memory-allocation in Java is an order of magnitude more expensive than in Hugs. Functional programs will create and destroy objects on a more frequent basis than an imperative object-oriented one ...

Anyway, it's good to see that these problems are addressed by someone at MSR. Hope it really finds its way to .NET.
Re:Who thought this? by arn@lesto · 2002-02-07 06:55 · Score: 1

The real issue is that while I can implement a tail call implementation using the existing CLI/JVM instructions it isn't very efficient. Without a tail call instruction in the JVM/CLI the runtime compiler/optimizer is prevented from recognizing the tail call and emitting better machine code.
Programs written in functional language use call instructions much more than traditional ALGOL like programs. The overhead of the call matters much more than you would expect.

--
- AndrewN
Re:Who thought this? by tyse · 2002-02-07 13:07 · Score: 1

There is a tailcall instruction in the .NET CLR.

It's currently not particularly efficient, but the fact that it is there means that it can be made efficient. But that's a quality of implementation issue, not an instruction set design issue.

Donket Dot Net by DonkeyHote · 2002-02-07 02:45 · Score: -1

Publicity by Anonymous Coward · 2002-02-07 02:47 · Score: -1, Offtopic

With CNET, ZDNet, and Slashdot.org doing their jobs, Microsoft gets all the .Net publicity they need.

What about speed? by tal197 · 2002-02-07 02:52 · Score: 5, Interesting

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? by jguevin · 2002-02-07 02:59 · Score: 2, Informative

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? by Rentar · 2002-02-07 03:01 · Score: 3, Interesting

.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? by NulDevice · 2002-02-07 03:04 · Score: 4, Interesting

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.

--
----
"I used to listen to Null Device before they sold out."
Re:What about speed? by DrPascal · 2002-02-07 03:07 · Score: 1

Speaking purely from basic tests with VisualStudio.NET BETA 2, most of the C# apps I compiled did take a noticable, but short period of time (half second?) to display a simple Dialog Box application.

What I do know is that this pause is probably because of the JIT compiler, and the fact that it was running in "Debug" mode. Supposedly in a production installation, the installer can run a "PreJIT" on the program, converting it to native code and allowing it to run at full speed, in comparison to say, a C++ app with identical functionality. (I have not tried any "PreJIT" for the record though... it was just in the Wrox book I was reading.)

I'll tell you though, I was rather frustrated with the BETA 2's "helping out" with the code writing (such as accidentally double clicking on the form drawing writing 20 lines of scattered code), because it didn't tell me that it added the code, nor did it provide a method to undo the action. But that is an IDE issue, and you asked about overhead... so forget it. :-)

--
DrPascal: Not the language, the mathematician.
Re:What about speed? by tal197 · 2002-02-07 03:17 · Score: 1

Thanks for the replies!

Well, it sounds like start-up time is good (which is the important thing for me).

Compile time doesn't matter much, since I guess the compiler is running under the CLR too, so someone will write a fast C version sooner or later (as eg, IBM's jikes solved the compilation speed problem of Sun's javac).
Re:What about speed? by John_Booty · 2002-02-07 04:36 · Score: 2

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.

--

OtakuBooty.com: Smart, funny, sexy nerds.
Re:What about speed? by egomaniac · 2002-02-07 04:57 · Score: 3, Interesting

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.

--
ZFS: because love is never having to say fsck
Re:What about speed? by unclefucknut · 2002-02-07 05:24 · Score: 1

IIRC, one difference between the java JIT and .NET JIT is that the .NET JIT saves the JIT compiled code for reuse. Thus, in theory, .NET apps should be faster after a good run through. I am however not 100% on this, since I read about this during early stages of .NET. It might just have been some vapour feature...
Re:What about speed? by Darren+Winsper · 2002-02-07 05:38 · Score: 1

The problem with a lot of perl problems seems to be the theory that "if you can't obfuscate it, it's not worth doing" ;)
Re:What about speed? by KGIS · 2002-02-07 05:40 · Score: 1

.Net does save previously compiled code for later use. It also can let you to compile code before executing the program for the first time so that when the user runs it for the first time they don't have the initial cost. For example you can compile the code at install time to take advantage of the specific hardware in the machine you are installing to.
Re:What about speed? by Anonymous Coward · 2002-02-07 06:01 · Score: 0

I don't deny hotspot has some cool stuff.

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

secondly, every benchmark for which this is true is not a good benchmark. I don't mean to say java's slow, but the cases where it beats C++ on speed are very artificial.
Re:What about speed? by RubberMan · 2002-02-07 06:03 · Score: 2, Informative

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? by egomaniac · 2002-02-07 06:35 · Score: 2

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

--
ZFS: because love is never having to say fsck
Re:What about speed? by jimmu · 2002-02-07 06:36 · Score: 1

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

Well, sort of. Actually, all the .net langauges (including ASP, but thats going to be written in C# or VB.net anyway) is compiled down to something called MSIL. The first time the appliation is run, its compiled down to native code using the Common Language Runtime. (CLR). Every time after that, the compiled version is run, unless the MSIL version has been changed, in which case it gets compiled again. The first time a .net program is run, there is some lag time, becuase the app needs to be compiled, but it isnt noticable except for really large applications. So there is a Just in time compiler, it just doesnt get invoked every time the application runs. The CLR is cool, becuae it measn that any .net language (or, indeed anylanguage that can access the CLR) has access to all the same system functions. Not more Calling Windows API's for VB programmers, its all built in. Basically, ti comes down to the language you feel more comfortable with, since both VB and C# can do the same thing.

--

----
One of us needs to stick ones' head in a bucket of ice water.
- Hobbes
Re:What about speed? by Anonymous Coward · 2002-02-07 06:56 · Score: 0

Actually, a c# compiler based in c is already in the works. See dotGNU and the Portable.NET project.

cheers.
Re:What about speed? by Steveftoth · 2002-02-07 06:59 · Score: 2

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? by Steveftoth · 2002-02-07 07:02 · Score: 2

what's wrong with tar zxf someprogram.tar.gz cd someprogram ./configure make ; make install
Re:What about speed? by Anonymous Coward · 2002-02-07 07:08 · Score: 0

BULLSHIT! Whatever! So why don't I see any shink-wrapped Java applications? So how come I don't see EJB servers on the TPC site? So how come I don't see any MAJOR websites using Java/EJBs on the back end? Quit kidding yourselves.
Re:What about speed? by egomaniac · 2002-02-07 07:20 · Score: 2

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.

--
ZFS: because love is never having to say fsck
Re:What about speed? by Anonymous Coward · 2002-02-07 07:20 · Score: 1, Insightful

I tried the same test: is x prime ? x < 1000000 java 43,421 sec c# 24,769 sec (java 1.3.1, .net 1.0) (win2000, XP1800+) class Prim { // c# static void Main (string [] args) // java static void main (String [] args) { for (long a = 2; a < 1000000; a++) { // c# bool prim = true; // java boolean prim = true; // c# for (long b = (int)System.Math.Sqrt(a); b > 1; b--) // java for (long b = (int)Math.sqrt(a); b > 1; b--) if ((a % b) == 0) { prim = false; break; } // c# if (prim) System.Console.WriteLine(a); // java if (prim) System.out.println(a); } } }
Re:What about speed? by Rentar · 2002-02-07 07:59 · Score: 1

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

I've never said anything else ...

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.

Indeed, it is cool technology. But those people who claim that Java is slow haven't played around with it for a long time or have used GUIs made with Java. Granted: Up to date PCs are fast enough for running most Java GUIs, but that's a shame. They should not be "fast enough for most GUIs", they should be "overkill for all GUIs". (And, yes, I do "play around" with Java all the time at work; both on the server and at the client).
Re:What about speed? by Hard_Code · 2002-02-07 08:40 · Score: 2

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

--

It's 10 PM. Do you know if you're un-American?
Re:What about speed? by RubberMan · 2002-02-07 10:00 · Score: 1

I gave your code a try ( I used a slighly different approach originally) and came up with this numbers:

C:\Temp>java Prim
Count: 78500
Execution Time: 17134 ms

C:\Temp>prim.exe
78500 primes found
Time taken = 31004 ms

I'm using the IBM 1.3 jdk on a 1gig with 512 megs ram on w2k.
Re:What about speed? by chfleming · 2002-02-07 10:21 · Score: 1

java 43,421 sec
c# 24,769 sec

Let me add to that
(gcc 2.96, RedHat 7.2, Athlon 1.4GHz)
14.71 sec

Though , I don't know how much of this can be attributed to the overhead of WinNT.

No, wait a minute, it can't just be that because your proc is 400 MHz faster than mine.

So in this case C must be twice as fast as C# must be twice as fast as Java. Makes sense I guess.
Re:What about speed? by Anonymous Coward · 2002-02-07 11:13 · Score: 0

ok, so MS compiler. fine, no prob, although Intel or any other compiler can be plugged into Vstudio, which is what I do, but I get your point.

I'd never say java is too slow - algorithms can be too slow, languages can require too much memory, but rarely is a language too slow.

I've read the report - 'Java faster than C in the average, and this is a low-level benchmark that's heavy on numerical and array code, so this is no mean feat.'

I say that's crap. numerical code, untrue except for the places where C falls short of FORTRAN (poor optimistation, particularly of integer powers, the whole float/double thing - irrelvent on todays chips mostly), but java does no better. Arrays - only if java has a clever way to beat cache hits, and it simply cannot have one by virtue of its spec. So how can it possible beat the tight array lookup of C - answer - it can't, except maybe hotspot can do it's fancy stuff - but Hotspot was slower!

Java very nice, fast enough - yes. Faster than C, I'll change my opinion when I see it done. and no, javalobby have not done it. I code in java when I can, I love it. but I'm one of the 99.9999% of coders who don't care about the v. slight speed hit we might be taking (I'll admit I very much doubt I use the fastest algorithms, I code inefficiently).
Re:What about speed? by Anonymous Coward · 2002-02-07 11:20 · Score: 0

oh, and don't get me started on threads. you can code threads in java to be fast on one machine.

they'll be damn slow on another.

in C, well, you're outside the standard so it's not C. which is faster? not a valid question.
but a team of windows programmers, plus a team of solaris programmers will make your app fast on either, with a few macros. a team of java programmers will never get it fast on both. the one-size-fits-all thread model will kill one or other of them, unless the entire thing is rewritten from scratch.
Re:What about speed? by Kanasta · 2002-02-07 13:08 · Score: 2

More worrying, how big is the .NET runtime that the user has to download to run my 10kb text editor?
Re:What about speed? by Anonymous Coward · 2002-02-07 17:58 · Score: 0

Initial compiles can be drastically improved by not putting any code in the aspx files (no server side SCRIPT tags, for example) and ONLY using the aspx to inherit from a pre-compiled class. Even if you do this, if the CodeBehind page directive is present, it will still check the version whichs adds a small bit of overhead. On our production applications, we only have aspx files and dll's (in the bin directory, of course). All of the "source code" get's filtered out by our "deployer" program (also written in C#).
Re:What about speed? by Anonymous Coward · 2002-02-07 18:02 · Score: 0

Ya, a lot of "ASP Gurus" and VB folks are being forced to learn how to build structured applications. Of course, I've already seen some very poor OO Designs from these so called "Programmers".

DISCLAIMER: ASP and VB is cool for the job and I'm not bashing people who happen to like VB's (verbose!) syntax. However, 99% of VB/VBScript programmers who don't have a strong foundation in another language are generally very poor coders.
Re:What about speed? by Anonymous Coward · 2002-02-07 18:04 · Score: 0

Should have been rated "Informative, if you like BULLSHIT".
Re:What about speed? by Lips · 2002-02-08 00:55 · Score: 1

I must agree with this. VB is ok, (servlets are nicer). But because it is pushed as being easy to use, a lot of nuf nufs use it and use it incorrectly. If a person doesn't know what IDL is, they should be using VB to create DLLS.
Re:What about speed? by Lips · 2002-02-08 00:58 · Score: 1

oops. shouldn't
Re:What about speed? by MobyTurbo · 2002-02-08 08:08 · Score: 1

I really like the idea of a common cross-platform runtime, but not if it makes my text editor take 5 seconds to load!
I see that you don't use Emacs. ;-)
Re:What about speed? by Steveftoth · 2002-02-08 08:54 · Score: 2

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.
Re:What about speed? by Moghedien · 2002-02-15 04:51 · Score: 1

The .NET Framework Redistributable is ca 20MB.

--
I've come to... anesthetize you!

The problem by Anonymous Coward · 2002-02-07 02:52 · Score: 1, Informative

The problem hasn't been that you can't implement some functional languages with CLR and ILR. The problem is that to implement a particular functional language (scheme and common lisp spring to mind) you've had to drop some functionality (in fact, do a partial implementation). Will this be addressed? Who knows? I note that the first passes at Python.NET and Perl.NET ran into the same sorts of problems and ended up with a comprimise of integrating with the .NET stuff but not an implementation under .NET.

boy, good thing by Frothy+Walrus · 2002-02-07 02:54 · Score: 3, Funny

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

nice solution to a non-issue.

Re:boy, good thing by Anonymous Coward · 2002-02-07 03:26 · Score: 0

5 - you didnt count me >:|

canAttack(A, B):-

partOf(A,C),

canAttack(C,B).
Re:boy, good thing by Anonymous Coward · 2002-02-07 03:28 · Score: 0

Are there that many!
Re:boy, good thing by Anonymous Coward · 2002-02-07 04:14 · Score: 2, Informative

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
Re:boy, good thing by Anonymous Coward · 2002-02-07 05:48 · Score: 0

Ugh, I have to use Pro/Engineer every day and it is the most unstable, bug-ridden pile of poo I've ever had the misfortune to use. It core dumps at least once a week. It would be a good thing if PTC were forced to rewrite it from the ground up.

What's to change by Mike+Connell · 2002-02-07 02:55 · Score: 2

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

--
Tales from behind the Lagom Curtain

Re:What's to change by Anonymous Coward · 2002-02-07 03:33 · Score: 0

Didn't read Miguel's reply yesterday, did you?
Re:What's to change by SpaceLifeForm · 2002-02-07 03:59 · Score: 1

Not MSFT. You are a fool if you believe this .NUT technology will change things for the better.
Hell, MSFT cannot fix .NET security exploits in 6 months on their own servers!
This is just another security nightmare waiting to happen.

--
You are being MICROattacked, from various angles, in a SOFT manner.

so much for 'multilanguage' ... by Anonymous Coward · 2002-02-07 02:57 · Score: 0

Well, it was obvious from the beginning that the Sharp/Cool Virtual Machine (or whatever it is called now) could only support 'heavily Sharpenized' languages. Just look at the die-hard VB newsgroups to see their opinion about the "vbnet" syntax.

Exactly the same as the many different "languages" available for the Java VM. ( A nice list, by the way! Have a look here: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml )

However, invoking the VM from another language is an entirely different issue. What about "Managed LISP" ? Could it be useful?

How .NET murdered my children and raped my wife by DonkeyHote · 2002-02-07 02:58 · Score: -1

Standard ML and Haskell implementations by hsenag · 2002-02-07 03:00 · Score: 3, Insightful

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 by xacto · 2002-02-07 03:01 · Score: 3, Interesting

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 by JohnsonJohnson · 2002-02-07 03:19 · Score: 4, Interesting

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 by mmacdona86 · 2002-02-07 03:35 · Score: 1

There is another issue-- The CLR provides built-in support for some, but not other, models of higher-level language constructs (such as exception propagation and method dispatch). If the language implementation needs similar concepts but for one reason or another can not use the built-in support, it can still be implemented but it will run an order or magnitude slower (it will essentially be impractical). So the CLR is actually only useful as a target for a sub-set of languages and for other languages that have been designed specficially to use it.
Re:IL, like Java Byte Code, is simply assembler by Anonymous Coward · 2002-02-07 03:52 · Score: 1, Informative

Anything one could do in native assembler, one could do in IL or JBC.

Incorrect. Java byte code doesn't allow many things that you can do in assembler, for example read from a memory address, call a function in memory (basicly anything to do with memory pointers). These restrictions make it hard to generate effecient byte code for languages like C and Lisp.
Re:IL, like Java Byte Code, is simply assembler by Malc · 2002-02-07 04:04 · Score: 2

"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:IL, like Java Byte Code, is simply assembler by Anonymous Coward · 2002-02-07 04:09 · Score: 0

All assembly languages are *not* created equal. It is impossible to compile C to Java bytecodes, for example - unless you count writing another VM in Java, a VM that *is* capable of executing C code, and then compiling C to that second VM. (If you don't believe me, try implementing pointers. The whole JVM design is based on the requirement that pointers should be impossible, because they are unsafe.)
Re:IL, like Java Byte Code, is simply assembler by Anonymous Coward · 2002-02-07 04:25 · Score: 0

Pointers are non-trivial but possible to emulate in the JVM. You turn them into references behind the user's back. Similarly for pointer arithmetic, you turn them into lookups into a table of references. Incompatible static C casts would be slow (you'd have to do work to cast a byte * to double * while in C it would just assume the bits were all valid) but other casts would be fine. No need for a VM in a VM. What wouldn't be possible is pointer arithmetic that takes you outside of your allocated space. For that you'd need an internal VM that doesn't care about safety.
Re:IL, like Java Byte Code, is simply assembler by Anonymous Coward · 2002-02-07 05:36 · Score: 0

Anything one could do in native assembler, one could do in IL or JBC.

Not true. In Java Bytecode some things are very awkward to express. For example C's longjmp, pointer arithmetic, casts, etc cannot be translated without very contorted constructs. There is no full translator from C to JVM.

In .NET they have covered this much better.
Re:IL, like Java Byte Code, is simply assembler by JohnsonJohnson · 2002-02-07 05:42 · Score: 1

And COM/CORBA have been such a rousing success that Microsoft is now touting the CLR. I don't have much experience in developing applications that use CORBA (I think it's sufficient to equate CORBA and DCOM) but I did look at it at one point for the application we develop where I work. Our application depends on communications between devices over a network and we thought it would make developing easier if each instance of the application presented a set of objects that could have messages passed over the network relatively seamlessly. This seems to be exactly the problem CORBA was meant to solve but after looking at the amount of complexity using CORBA would require versus what we actually needed to do we decided against CORBA.

That's all aside from your point though, from what I can tell though, COM and CORBA work best for languages that are statically typed and classes are defined entirely at design time. Languages like Smalltalk, Dylan and ObjectiveC need not apply. Furthermore, I didn't get too far into the CORBA IDL capabilities but it seems that there is no provision for passing executable code as an argument. For languages like LISP, Haskell and ML this is one of the fundamental programming techniques used. I do believe CORBA had some support for generic programming of which C++ templates are an example.

So basically COM/CORBA work well for the relatively small number of ALGOL like languages with static typing and statically derived objects a la C, C++, Ada, Pascal etc. Languages that use different paradigms do not fit well with COM/CORBA nor has the CLR removed these limitations. However in Miguel's reply he stated that he believed using the CLR will allow GNOME developers to essentially use any language they felt like. While for a relatively small family of languages: C, C++, Java, C# and thier ALGOL derived cousins (Ada, Pascal, Modula) this is true for a much larger set of programming languages there are many features that will not interoperate with .NET causing one to write code that is inefficient when expressed in the idiom of those languages. I've seen what happens when FORTRAN programmers try to use Mathematica and very often they end up with Mathematica code that runs two orders of magnitude slower than people who use a more functional style. It is from stories like this that functional languages have developed a reputation for inefficiency. Writing LISP with a C# accent is similarly futile but that is essentially what the CLR enforces, LISP interfaces must use a C# idiom and even more importantly any LISP programmers using objects from the .NET framework will find C# idioms creeping through thier programs whether they export any objects or not.

Incidentally it's not only the paradigmatically different languages that are second class citizens in the CLR. There is not support in the CLR for Eiffel assertions which enforce the design by contract style favoured by Eiffel programmers even though Eiffel is ulimately a descendent on the infamous ALGOL tree.

Interface design is necessarily constrained by the constructs that can be used in an implementation. Procedural APIs are very efficient when used with imperative languages as in numerical codes for example, but for functional languages a style which passes functions as first class arguments and avoids side effects is much more efficient. So you can't define the interface independently of the implementation environment you expect to use and the CLR's environment is too restrictive to allow the types of interfaces used by a large number of programming languages.

.NET is like java but way behind by Anonymous Coward · 2002-02-07 03:01 · Score: -1, Troll

Functional languages are already presend for the JVM, look at kawa for example.

LISP by Anonymous Coward · 2002-02-07 03:03 · Score: -1, Offtopic

LISP sucks and you know it.

However Jessica Alba rules all the way. And so does Heather Donahue.

the promise of functional programming... by knulleke · 2002-02-07 03:03 · Score: 1

has never materialized. It's nice from a theoretical point of view but for all practical purposes functional programming has never delivered.

--
no sig error.

Re:the promise of functional programming... by shd99004 · 2002-02-07 03:08 · Score: 2

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

--
Will work for bandwidth
Re:the promise of functional programming... by JohnsonJohnson · 2002-02-07 03:27 · Score: 1

As an everyday user of Mathematica which is essentially a LISP like language with pattern matching facilities I beg to differ. I also use Matlab, Ada, FORTRAN and C and can definitively state that my productivity is highest in Mathematica both for numeric and symbolic codes.

This is of course a horses for courses argument anyway, for many tasks (GUI implementation, manipulation of operating system objects, database interfacing) only a masochist would use Mathematica. However that does not mean Mathematica has not delivered on the advantages of functional programming. As for doing these other tasks in a functional paradigm, there are many Haskell, ML and CLOS developers who are happily writing GUIs and operating system level services but not so many database driven applications.

Before looking at what appears on the shelves of your local CompUSA, on the software list at Amazon.com, or the jobs advertised in your local paper or on HotJobs remember that 90% of all software is not developed for general consumption but to solve problems within a (usually) smaller organization.
Re:the promise of functional programming... by Spock+the+Vulcan · 2002-02-07 03:38 · Score: 1

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

Which, incidentally, is not a functional language at all, but one of the Declarative programming paradigm. However, it is possible to use it for functional programming.

Lisp is also object-oriented by jdmmmmm · 2002-02-07 03:04 · Score: 0

Every decent implementation of Lisp that I know of comes with CLOS (Common Lisp Object System).

Re:Lisp is also object-oriented by hding · 2002-02-07 04:26 · Score: 2

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

Think maybe better not by Pussy+Is+Money · 2002-02-07 03:08 · Score: 2, Interesting

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?

--
Pushin' 'n dealin', shovin' 'n stealin'

Re:Think maybe better not by knulleke · 2002-02-07 03:28 · Score: 1

bullshit

--
no sig error.
Re:Think maybe better not by Pussy+Is+Money · 2002-02-07 03:42 · Score: 0

hey there you here too huh...nev m'nd

--
Pushin' 'n dealin', shovin' 'n stealin'

Think strategy, not technology by pubjames · 2002-02-07 03:09 · Score: 3, Offtopic

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 by JanneM · 2002-02-07 03:26 · Score: 1

First, the Gnome foundation has nothing to do with Mono.

Second, exactly how would open source people ignoring .net in any way help their cause, or hurt MS?

As you say yourself, .NET may be great technology. SHould we then succumb to the Not Invented Here syndrome and ignoring the technology just because of its origin?

Most people enthusiastic over Mono aren't even interested in compatibility issues with MS' implementation; they want to use it to develop Linux apps, not run MS stuff.

Of course the field is clear for people to design a competing standard that is better than .NET. I haven't seen any activity on that front, though.

/Janne

--
Trust the Computer. The Computer is your friend.
Re:Think strategy, not technology by Anonymous Coward · 2002-02-07 03:27 · Score: 0

They're not interested in 50%, they want 100.
News Flash! Corporation wants to maximize market share! Film at 11.
Re:Think strategy, not technology by pubjames · 2002-02-07 03:32 · Score: 2

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 by pubjames · 2002-02-07 03:36 · Score: 2

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 by Lord+Omlette · 2002-02-07 04:06 · Score: 2

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

--
[o]_O
Re:Think strategy, not technology by trg83 · 2002-02-07 04:22 · Score: 1

Exactly. All Microsoft has to do is change the rules of the game and you can scrap your project. It WILL happen.
Re:Think strategy, not technology by inburito · 2002-02-07 04:46 · Score: 2

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 by Anonymous Coward · 2002-02-07 04:53 · Score: 0

It works, doesn't it?
Re:Think strategy, not technology by Anonymous Coward · 2002-02-07 05:21 · Score: 0

Additional News Flash! Best interests of a corporation may not be in the best interests of developers and consumers!

Yet Another News Flash! Those thinking strategically have advantage over those who are not!
Re:Think strategy, not technology by Melantha_Bacchae · 2002-02-07 05:36 · Score: 2

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 by inburito · 2002-02-07 06:00 · Score: 2

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 by Anonymous Coward · 2002-02-07 06:08 · Score: 0

You are familiar with the IBM antitrust cases of the 70s, right?
Re:Think strategy, not technology by Anonymous Coward · 2002-02-07 07:39 · Score: 0

I completely agree. But if Miguel's going to do it anyway, embrace and extend.
Re:Think strategy, not technology by Raffaello · 2002-02-07 07:41 · Score: 1

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

... So far so good...

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

... OK, so far....

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

But when he changes certain key, and proprietary, aspects of his pool, and starts charging for their use, your pool won't interoperate with everyone else's pool (read, the 90% of desktops that run the Shark's OS, and .NET frameworks). So life passes you by.

You don't get eaten by the Shark, but the Shark has cleverly gotten you to waste several precious years when you might have kept pace with him in the important server space, where he still doesn't dominate.

Too bad, you fell for his ruse, and though he hasn't eaten you, he has eaten your lunch.
Re:Think strategy, not technology by ink · 2002-02-07 08:11 · Score: 1

But when he changes certain key, and proprietary, aspects of his pool, and starts charging for their use, your pool won't interoperate with everyone else's pool (read, the 90% of desktops that run the Shark's OS, and .NET frameworks). So life passes you by.
Where is it written that Mono's goal is to inter-operate with Microsoft Windows? You are letting your hatred and fear blind you. Microsoft dotNET is evil, no doubt about it, but the dotNET foundation classes, CLR, and C# are very simple and good technologies. That they probably won't inter-operate with Windows is no big loss, we are already at that point right now; and if they happen to inter-operate on some level then that's just icing on the cake.

--
The wheel is turning, but the hamster is dead.
Re:Think strategy, not technology by inburito · 2002-02-07 12:46 · Score: 2

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 by darkatom · 2002-02-07 03:12 · Score: 4, Insightful

.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 by Anonymous Coward · 2002-02-07 03:27 · Score: 0

then go back to your VI and EMACS editor and let the rest of the world move on with dot.net
Re:.NET is a quagmire by Anonymous Coward · 2002-02-07 03:29 · Score: 0

MFC is .NET 0.5? what have you been smoking mate? missed the point somewhat methinks...
Re:.NET is a quagmire by Anonymous Coward · 2002-02-07 04:11 · Score: 0

Are you nuts!?!!??

OLE and DocObects are part of the underlying foundation of .NET.

Get real and go learn something!
Re:.NET is a quagmire by SteveX · 2002-02-07 04:58 · Score: 2

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 by Ssrit · 2002-02-07 05:57 · Score: 1

Not true. .NET is an entirely new foundation. It is not based on OLE or any previous technology. It is an entirely new VM. It has no reliances on COM or Win32. Now, Microsoft's version of .net has extensible ability to make USE of existing COM objects. This is because Microsoft positions this as a replacement for their current COM/etc mess, and the only way to do this is gradual. So people need the ability to use their existing components. .NET Framework is what you make it. If you choose to design your components so they aren't cross platform, then you are more than welcome to. This makes it actually USEFUL. Microsoft provides System.Data.OleDbClient and System.Data.SqlClient for dataaccess by default. I already know there are System.Data.Odbc classes floating around. Obviously SqlClient will only work with pure MS-SQL, OleDb will only run on a platform where OleDb is available. MS hasn't locked you into these, it's just the only ones they feel they should spend their engineers time on.
Re:.NET is a quagmire by thelexx · 2002-02-07 06:29 · Score: 2

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

--
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
Re:.NET is a quagmire by Anonymous Coward · 2002-02-07 08:21 · Score: 0

One .NET to rule them all...
Re:.NET is a quagmire by SteveX · 2002-02-07 08:22 · Score: 2

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 by ink · 2002-02-07 08:26 · Score: 2
.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.
--
The wheel is turning, but the hamster is dead.

It's the API's stupid. by IGnatius+T+Foobar · 2002-02-07 03:15 · Score: 2

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.

--
Tired of FB/Google censorship? Visit UNCENSORED!

it really doesn't matter by markj02 · 2002-02-07 03:18 · Score: 5, Insightful

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.

Real information by undone9 · 2002-02-07 03:19 · Score: 1

Yes, any language can run just fine on the CLR. However, not all .net-tweaked languages are created equal: C# is the only language that does not carry a performance penalty for writing managed code...the others are either ports or are inherently limited.

For example:

Visual Basic makes use of exceptions as part of control-flow manipulations. Those are very expensive in the .net world (as they should be), so MS changed a lot in the language to allow people to write performant apps. However, old VB code is still dog-slow.

Managed C++ isn't bad for performance, though the syntax is ever worse than regular C++. If you want anything approaching native speed though, you will want to stay away from the garbage collector (virtual method invocations are very expensive in GC'd objects, since they require a jump out of the managed world into the vtable and then back in again).

The problem with functional languages on .net is pretty obvious: you lose tail-call optimizations, since the security model depends on the stack. This is one of the biggest drawbacks to writing fast functional code on .net, and it seems that there's no way around it without ripping up the security infrastructure and putting in a new one.

E

Re:Real information by brlewis · 2002-02-07 03:36 · Score: 2

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.
Re:Real information by The+Bungi · 2002-02-07 04:22 · Score: 1

Visual Basic makes use of exceptions as part of control-flow manipulations. Those are very expensive in the .net world (as they should be), so MS changed a lot in the language to allow people to write performant apps. However, old VB code is still dog-slow.

Totally incorrect. In the VB6 environment, an exception is a COM IErrorInfo object that is marshalled by value to the receiver in the stack context. This is an expensive operation. Further, the fact that many VB coders use these exceptions to control program flow makes things worse, but it's by no means the only way to do things.

In .NET, an exception is a framework "light" class, usually inherited from System.Exception. Throwing these is the preferred way to signal problems, especially now that VB.Net has class constructors (can't return a value from a constructor, remember?)

Finally, VB6 code is significantly faster than the equivalent VB.Net code, especially when doing UI stuff. WinForms are dog slow and will continue to be until Microsoft implements all those performance enhancements they talked about but didn't make it into the current release. Ditto for COM Interop, data access and most other things. The only few things I can think of right now that are faster in .NET are XML handling and remoting.

Hope this helps.
Re:Real information by undone9 · 2002-02-07 10:00 · Score: 1

You're not listening. I never said MS didn't add functionality that was lightweight. I said that if you take old code you'll find it runs significantly slower on the CLR than it used to, because there are fundamental problems in VB5 that MS had to change in VB6 for speed.

And no, VB6 is not faster than 5 at UI. Believe me.

The way they deal with file handlers is a mess too. I'll leave it at that.
Re:Real information by Anonymous Coward · 2002-02-07 10:02 · Score: 0

It's my understanding that the runtime does a stack walk to check for permissions. If a function makes a tail recursive call to code that gets executed with higher privildges, the security model in .net needs to ensure that the stack contains enough information to prevent malicious code from getting access to code with more permissions.
I wouldn't be surprised if there are ways to prove certain things safe, but I don't believe any of this made it into v1, and I've heard that the number of cases where this proof can be made to run is almost nill.

It$ all about the ca$h! by JohnBE · 2002-02-07 03:21 · Score: 0

Whilst .NET as a concept may be wonderfull, if the industry doesn't demand support (and a lot of companies won't) for OSS and Free Software compilers, these will be less of a priority. People who demand support for OSS and Free software compilers are not neccisarily where the money is (they roll their own). It's fairly obvious when things are funded in a non-grant way.

Does the future of the internet really belong in the hands of companies who may be hit by recessions? Open Sourcing, real Open Sourcing, keeps ensuring that a product lives on. Shit, you should see some of the wonderful stuff produced at Xerox-PARC, which got really screwed, a lot of it hasn't lived on because it wasn't Open Sourced.

I think maybe if Microsoft did opensource everything they would dominate the market still because they'd still be the experts. They'd probably marginalise Linux too. Especially in the third world, China and India.

I seriously doub Microsoft could go the same way as Xerox but I imagine people said that about Xerox.

- John

--
e4 e5

Project 7 by EvilKevin · 2002-02-07 03:22 · Score: 1

Check out Project 7. Microsoft is funding development of a variety of functional language front-ends for .NET including Scheme, SML, Mercury, and Haskell. Dan's work has been to provide a higher-level IL than MSIL (CIL) that may make writing a front-end for functional (or some object oriented) languages easier. AFAIK the Haskell front-end is the only one using Dan's higher-level IL.

Microsoft Haskell Press Release by KieranElby · 2002-02-07 03:24 · Score: 2

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)

Bill Gates, Age 32, Found Dead by Anonymous Coward · 2002-02-07 03:24 · Score: -1, Troll

I just saw some sad news on MSN - Chief Technology Officer for Microsoft corporation, William Gates III, was found dead in his Seattle, Washington home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't like or use his company's software, there's no denying his contributions to the software monopoly's business. Truly an American icon.

Re:Bill Gates, Age 32, Found Dead by Anonymous Coward · 2002-02-07 03:29 · Score: -1, Offtopic

this is sad news?
Re:Bill Gates, Age 32, Found Dead by Anonymous Coward · 2002-02-07 03:31 · Score: -1, Troll

this is sad news?

you're implying it might be happy news!? the man is dead, goddamnit! and i for one love the elegance of windows compared to the klunky, kludgy lunix operating system
Re:Bill Gates, Age 32, Found Dead by ErrantKbd · 2002-02-07 03:51 · Score: 1

If Bill Gates died at the age of 32, that means he dropped out of college when
he was about 2 years old, and formed Microsoft at the age of 5!

Just goes to show you, he was truly amazing.
Re:Bill Gates, Age 32, Found Dead by Graspee_Leemoor · 2002-02-07 04:34 · Score: 1

I was thinking about this the other day. They were showing some archive footage of Mr. G. at the XBox launch and he looked very old in his trendy XBox jacket- like some sad old woman wearing make-up and a short skirt.

I suddenly thought about what would happen if he just had a heart-attack tomorrow and died. God knows, his job must be pretty stressful, even if he doesn't read slashdot.

I realized I would miss him- at least as a concept. I mean I dislike a lot of things that MS has done, but in the end they are a company trying, like every other company, to make as much money as possible.

But think about it- no play is complete without its villian, and he does make life more interesting. I mean, how cool would slashdot be without anti-ms stories and postings, as well as anti-sun, anti-sony etc.?

Headlines:

* Gnome developers release new cool desktop.
* KDE developers in love fest with gnome developers.
* Everyone gets along splendidly and collaborates on new open-source software.
* We all love each other.
* Miguel and RMS have polite disagreement over whether to call it "free beer" or "free lager".

Etc.

So, I guess what I'm trying to say is that if Bill Gates died tomorrow I would say- "That's a shame- he seemed like an OK guy, really."

So go ahead, flame away.

(Hmm. Maybe you're not supposed to drink with this cough-medicine.)

graspee
Re:Bill Gates, Age 32, Found Dead by Anonymous Coward · 2002-02-07 05:38 · Score: 0

Sadder than if YOU died!

There is no such thing as "Turing complete" by yerricde · 2002-02-07 03:25 · Score: 2, Informative

As long as the language is Turing-complete, it should be possible; the question is in the level of difficulty

No physically implementable computer system is Turing-complete, as a Turing machine has an unbounded storage tape. Even C on a 64-bit architecture isn't, as it limits you to only a few exabytes of memory.

--
Will I retire or break 10K?

Re:There is no such thing as "Turing complete" by JamesOfTheDesert · 2002-02-07 08:57 · Score: 1

No physically implementable computer system is Turing-complete ...
Being Turing-complete, in the sense generally used when discussing languages, does not mean it can *literally* implement a Turing machine. It means the language (or system) can compute the same functions as can a Turing machine, with the understanding there are finite resources.

--

Java is the blue pill
Choose the red pill

A Valid Question by JohnDenver · 2002-02-07 03:25 · Score: 2

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.

--
"Communism is like having one [local] phone company " - Lenny Bruce

Re:A Valid Question by Anonymous Coward · 2002-02-07 03:33 · Score: 0

This is a valid question followed by his opinion, so why is it modded down to -1?
It wasn't modded down. Apparently, October_30th has negative Karma significant enough to cause all postings to default to a -1 rating. Check October_30th's signature.
Re:A Valid Question by Anonymous Coward · 2002-02-07 04:44 · Score: 0

Oh... I forgot about those...

Efficiency and convenience by YoJ · 2002-02-07 03:27 · Score: 3, Insightful

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.

Re:Efficiency and convenience by KagakuNinja · 2002-02-07 08:31 · Score: 1

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.

This is supported in Java via anonomous classes, therefore the JVM supports it. I assume C# has similar mechanisms.

Haskell by hoggy · 2002-02-07 03:28 · Score: 5, Informative

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 by hoggy · 2002-02-07 03:32 · Score: 2

Oops! forgot to mention that the "main brain" I referred to is the legendary Simon Peyton Jones.
Re:Haskell by Anonymous._.Coward · 2002-02-07 04:21 · Score: 1

I met Don Syme in MSR Cambridge last September. He showed a game of life simulator written in ML with a graphical front end in C#. They are working on Haskell with SPJ for .NET but Don's been busy working on generics (C++ style templates) with Andy Gordon and others. They wanted to get generics into the CLR before the specification was sealed.

--
take a triptonica to subthunk
Re:Haskell by Anders+H�ckersten · 2002-02-07 07:15 · Score: 1

I'd be surprised as heck if the Glorious Haskell Compiler wasn't targetting .NET real soon.

That's the Glasgow Haskell Compiler, not Glorious. I'd love to see .NET for Haskell, since it's a lovely programming language that I have far fewer uses for than I'd like...
Re:Haskell by Jagasian · 2002-02-07 08:41 · Score: 2

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 by Truth_nz · 2002-02-07 10:05 · Score: 1

Nope - They going for nhc98 at last check. I should know - I was given it to do as an 4th year engineering project (Computer Systems Engineering), last year.
However due to lack of funding, the university didn't have any Win2k installs, so I was told to aim to have a Haskell to Java converter.
It proved to be impossibly large for a 4th year project, but I got a working framework, and a skeletal converter (i.e. it compiles simple single file programs).
I'm still waiting on the marking of it (supervisor problems). However nhc98 claims to be open source, which I believe would mean that my one would also have to be so as well. If I can get the university to put what I've done up on a web page I'll do so, and notify those at nhc98 so they can do what they want with it.
I have no idea what M$ are doing with it now (if anything at all) - as they went through my supervisor, and I was only interested in getting it done as a project.
Re:Haskell by hoggy · 2002-02-07 10:12 · Score: 2

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 by Kirruth · 2002-02-07 11:54 · Score: 1

Interesting that Massey university are among the leading lights behind Mondrian .Net, according to this page. Make sure you get your royalties, dude.

--
"Well, put a stake in my heart and drag me into sunlight."
Re:Haskell by Anonymous Coward · 2002-02-07 13:31 · Score: 0

Lisp is not untyped; Lisp is very strongly typed. It is usually dynamically, rather than statically typed, though. Strong typing and static typing are orthogonal concepts. Lisp can be statically typed, though, and some Lisp compilers have good type inferencing (CMUCL). It's true that Lisp shouldn't be held up as the "poster body for Functional Programming", though. Only non-Lispers claim it is such a thing!
Re:Haskell by Jagasian · 2002-02-07 14:35 · Score: 2

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 by divbyzero · 2002-02-08 05:02 · Score: 2

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.

--
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
Re:Haskell by mrdlinux · 2002-02-08 21:50 · Score: 1

You are a bit confused. Dynamic typing implies that values have types; not variables. Please get your facts straight before calling Lisp a "historical" artifact. I think there are quite a few tricks left in the old bag yet. Common Lisp looks to be quite alive and kicking, thank you, and it seems that it would be well worth your while to learn a bit from it.

You might start by noting that people are raving in other threads of the ability for Java compilers to mix interpreted and compiled code at runtime. You might want to note that Lisp compilers have been doing that for decades. How about decent GC? Or good development environments? CL compilers all seem to have the nicest IDEs, because CL is such a dynamic language. Oh it doesn't conform to functional ideals as a result; but that's okay: Lisp ain't functional anyway. It's not imperative or OO either; it's any and all. It's good to be flexible.

There is a reason why many programming techniques were pioneered or prototyped in Lisp.

--
Those who do not know the past are doomed to reimplement it, poorly.
Re:Haskell by Jagasian · 2002-02-09 10:14 · Score: 2

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.
Re:Haskell by mrdlinux · 2002-02-10 12:04 · Score: 1

You are right in the sense that type information is not known at compile-time. But the notion that "types are automatically inferred concepts used for (automatic) software verification" sounds rather ML-centric :). Types have a very distinct mathematical meaning as sets of valid values. Think of such concepts as domain and range, and then tell me that "types are not part of an actual algorithm".

I wasn't very clear in my original post about this but I think you are mixing up strong typing with dynamic typing. Strong typing ensures that type semantics must be followed precisely. Dynamic typing by itself is not a true type system because it's not the whole picture.

Lisp has dynamic and strong types; ie. the number 3 is an integer and it may be bound to any variable, the type information being carried along with it. It may be used by operations which expect integers, but trying to apply a character operation to it would fail with a runtime exception. Fortunately Lisp has an excellent condition system. (Note that certain compilers can perform optimizations that eliminate the need to carry type information at runtime. Python, used by CMUCL and SBCL, can perform this sort of optimization as well as various static type inference analysis. In Lisp, though, static type analysis is an optimization; not a necessity.)

I understand that this makes it very hard to analyze a program statically at compile-time, and that there is a place for such analysis, but remember that the world is a dynamic place and not every program you write will fit well into the static mold. That's basically the reason why I like Lisp. It's not a mathematical reason, but a practical one.

--
Those who do not know the past are doomed to reimplement it, poorly.

It's P/Invoke, Stupid by Anonymous Coward · 2002-02-07 03:29 · Score: 0

Making a call to an undocumented API from .NET would be the best thing for the OpenSource world. P/Invoke structures are incredibly easy to detect in CIL binaries, and because of the nature through which they load, they contain all of the ordinal and parameter information necessary for anyone to call them. However, you would be wrong. The Visual Basic specific libraries do use P/Invoke, mostly for COM, but it's all out in the open.

What a major Lisp vendor says: by OOPChugALug · 2002-02-07 03:30 · Score: 2, Informative

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.

shuga for my honey by redGiraffe · 2002-02-07 03:32 · Score: 1

kind of frightening how microsoft is pushing .NET as developer candy?

"Here kids, its cool, have some. What you want more, well, ya gonna pay. Start walking them streets."

-- moral: your gonna pay and get f**d

I don't give a damn by WildBeast · 2002-02-07 03:32 · Score: 1

I don't care if MS is evil or has a monopoly or whatever the hell, I just want to use the best tools for the job. The thing is that MS always provided great tools for making simple apps but when you try to create something a little bit more advanced using MS tools, it was a pain in the ass. Did they solve that with .NET? I'm not sure. I used to be able to look at PHP and ASP code and quickly understand how it works; with the new ASP.NET, I look at the code and I get confused, I have no idea what code does what.

Re:I don't give a damn by Anonymous Coward · 2002-02-07 04:55 · Score: 0

It's because it is OOP and not anymore Procedural language. I am myself a ASP developer and the learning curve is pretty steep for me..

Tail calls and dynamic typing by yerricde · 2002-02-07 03:37 · Score: 2, Informative

Anything one could do in native assembler, one could do in IL or JBC.

Not if the language doesn't support constant-space tail calls, which are the primary method of iteration in the Scheme programming language, and which can be implemented with a jmp (or whatever it's called) in any silicon CPU's assembly language. I've read that Java bytecode doesn't support it, but Microsoft added a tailcall instruction to MSIL at the request of compiler developers.

The Java platform's VM and the CLR both require code to be type-safe. How does this mesh with the dynamic typing (in .NET framework terms, everything inherits from System.Object and all variables are of type System.Object) that some functional languages use?

--
Will I retire or break 10K?

Crossplatform multi-language support? by Anonymous Coward · 2002-02-07 03:38 · Score: 1, Interesting

Sure:

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

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

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

TH

Re:Crossplatform multi-language support? by Anonymous Coward · 2002-02-07 05:03 · Score: 0

The problem with these assertions is that they claim that a language like C++ cannot be ported to .NET since they require case-sensitive identifiers, and do not permit multiple class inheritance. However, Microsoft has already released a C++ compiler that does compile to the CLR, and has no problems with either issue, or any other c or C++ related issue. I have not seen the C++ code that it cannot directly compile to the CLR. Of course, would you expect anything closely resembling truth from a site called "JavaLobby?" No, I didn't think so.
Re:Crossplatform multi-language support? by Anonymous Coward · 2002-02-09 00:18 · Score: 0

Only "managed" c++ gets to play friends, YOU learn your facts.

SML.NET by Tom7 · 2002-02-07 03:41 · Score: 4, Insightful

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

When the functional paradigm is superior? by Anonymous Coward · 2002-02-07 03:43 · Score: 1, Interesting

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

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

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

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

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

Re:When the functional paradigm is superior? by Rocky · 2002-02-07 04:05 · Score: 1

Go here, and be illuminated.

--
"I'm an old-fashioned type of guy. I worship the Sun and Moon as gods. And fear them."
Re:When the functional paradigm is superior? by Anonymous Coward · 2002-02-07 04:45 · Score: 0

See Why Functional Programming Matters by John Hughes.
Re:When the functional paradigm is superior? by Anonymous Coward · 2002-02-07 05:03 · Score: 0

Well to be honest, I was counting on some examples which would convince me, that I really need to read The Wizard Book and learn such languages as Lisp, Scheme, Elisp, Guile and Unlambda -- not where to find those info, which itself is not very hard.
All I need is a motivation.
Just like when I understood the idea of inheritance and the real OO code reuse, together with the idea of moving data to the foreground and that with a good data you need simple algorithms -- that day I understood, that I have to learn Smalltalk, Objective C, C++ and OO Perl.
Today I need to know why I need to learn how to think with the functional paradigm. It's a serious problem, which stops many people before they learn functional languages.
Many years ago I was writing C programs to process text, and I could do everything that way, I just didn't realize, that there were better ways to do the same. That was before I knew Regular Expressions, egrep, sed or Perl. Now I write Perl one-liners for tasks, which used to take me days of writing C code, but I didn't know that before, because "If the only tool you have in the toolbox is a hammer - every problem looks like a nail."
So now I ask for a reason to learn the functional way of thinking. I need to know it before I actually learn them, just to have a strong imperative. Learning the new way of thinking is a long and hard process, I just want to know what waits for me at the end.
I hope someone who know that reason, will tell me and those who also need it, why it's worth the efford. Thanks in advance.
-- Your Anonymous Coward who wants to learn new ways of thinking...
Re:When the functional paradigm is superior? by dlakelan · 2002-02-07 05:26 · Score: 1

One fairly unique reason to learn functional languages is that there are no side effects.

Because there are no side effects debugging becomes easier and can be done more statically (ie. by reading instead of running the code).

With a functional language you can ask the question: Does this function, when fed the right input, produce correct output? And you never have to look outside the function to answer this question (ie. no global variables). This is a MAJOR boon to debugging, because you can debug a single function and you're done with considering that function forever.

Combine this with garbage collection, no pointers, no stack smashing, no "unsafe" data types, compilers that can do some wicked optimizations (like removing entire sections of code because it can prove they will never be called), and some of the other great things about functional languages, and you have a system where you never ever spend time running a debugger asking the question "why is this core dumping" etc.

Depending on who you are you'll get correct running code easily 2 times faster, sometimes 10 times faster, and if you have particularly hairy C/C++ code functional languages can be 100 times faster to write working code.

now as for runtime speed, for compiled functional languages vs well written hand optimized C code, you have a factor of 2 speed difference typically.

On the other hand, the compiled functional code vs TYPICAL C code is often a factor of 2 faster for the functional language, because C is actually hard to write.

functional languages are also easier to profile and remove hot spots from.

--
((lambda (x) (x x)) (lambda (x) (x x))) http://www.endpointcomputing.com a scientific approach to custom computing.
Re:When the functional paradigm is superior? by Anonymous Coward · 2002-02-07 05:28 · Score: 0

please show me (and others) the functional way of thinking

After 31 years of programming, I haven't seen one. I've looked hard. I even wasted $65 on SICP. I've ask that question in other forums, is there an example of a problem that is easier to solve using functional programming. I haven't seen an answer yet.

It might be like OO. I've heard others ask the same question about OO, except with the additional requirement that it's a nontrivial problem. The trivial examples of OO in textbooks work well, but things fall apart when a newcomer goes to apply the same process to a larger problem. I haven't seen any good nontrivial examples of OO in textbooks, but I have worked on several projects were OO did help. Maybe, functional programming is the same way. You have to make a few mistakes and get knee deep in it to "see the light."

They seem, however, to be used by hardcore hackers, so they are surely worth attention.

Nice insight. I'll agree with that, and that's also why I keep trying to find a project that is done better with LISP. I haven't found one yet even though I've done prototypes of several different systems.z
Re:When the functional paradigm is superior? by Anonymous Coward · 2002-02-07 06:20 · Score: 0

With a functional language you can ask the question: Does this function, when fed the right input, produce correct output? And you never have to look outside the function to answer this question (ie. no global variables). This is a MAJOR boon to debugging, because you can debug a single function and you're done with considering that function forever.
I agree that these are great advantages, but they don't have anything to do with the functional nature of the language.
Combine this with garbage collection, no pointers, no stack smashing, no "unsafe" data types, compilers that can do some wicked optimizations (like removing entire sections of code because it can prove they will never be called), and some of the other great things about functional languages, and you have a system where you never ever spend time running a debugger asking the question "why is this core dumping" etc.
Well, these are arguments why the higher level of abstraction is better than the lower level of abstraction -- not, however, why the functional paradigm is better than the imperative paradigm.
Depending on who you are you'll get correct running code easily 2 times faster, sometimes 10 times faster, and if you have particularly hairy C/C++ code functional languages can be 100 times faster to write working code.
now as for runtime speed, for compiled functional languages vs well written hand optimized C code, you have a factor of 2 speed difference typically.
On the other hand, the compiled functional code vs TYPICAL C code is often a factor of 2 faster for the functional language, because C is actually hard to write.
functional languages are also easier to profile and remove hot spots from.

I have heard exactly the same arguments in discussions why Perl is better than C, and even many years ago (believe it or not) why C is better than Assembly. Exactly the same arguments.
This is just high-level vs. low-level, closer-to-problem vs. closer-to-machine, automatical optimization vs. manual optimization. If those are the only advantages of functional languages, than I don't need functional languages at all, because I can have the same with any good high level imperative language.
I assume, however, (maybe I'm just being naive) that there really are true advantages of the functional paradigm itself. Please, if anyone knows them, share your knowledge. Thanks a lot.
Re:When the functional paradigm is superior? by Anonymous Coward · 2002-02-07 06:57 · Score: 0

After 31 years of programming, I haven't seen one. I've looked hard. I even wasted $65 on SICP. I've ask that question in other forums, is there an example of a problem that is easier to solve using functional programming. I haven't seen an answer yet.
I'm slowly starting to think, that maybe the early functional languages were great because they where the first high-level languages, but now, when the high-level imperative languages are popular, they are no longer superior -- in other words -- the only real advantage of functional languages was the level of abstraction, not the paradigm itself.
I've been programming in imperative languages for about 15 years, and I've been asking questions about functional imperative advantages for maybe 8 years. I haven't yet heard any reason why I should sacrifice my time and learn those languages. And by learning I mean real learning, sacrificing maybe years of my life to master another ways of thinking, not just memorizing syntax and semantics, to express the same old way of thinking, but just using new words -- like most of Perl newbies write C code in Perl, never minding to learn how to think in Perl.
I'm quite surprised and very disapointed, that you haven't found answers to the very same questions, given your experience, twice as long as mine. Maybe there just simply are no real advantages strictly in the paradigm of functional languages?
Re:When the functional paradigm is superior? by JohnsonJohnson · 2002-02-07 07:53 · Score: 1

Today I need to know why I need to learn how to think with the functional paradigm. It's a serious problem, which stops many people before they learn functional languages.

Many years ago I was writing C programs to process text, and I could do everything that way, I just didn't realize, that there were better ways to do the same. That was before I knew Regular Expressions [oreilly.com], egrep [gnu.org], sed [gnu.org] or Perl [oreilly.com]. Now I write Perl one-liners for tasks, which used to take me days of writing C code, but I didn't know that before, because "If the only tool you have in the toolbox is a hammer - every problem looks like a nail."

As one idea to consider, lets take your text programming exercise. Imagine you have a block of text that is actually represents a program. Assume you need to transform that program using a regular expression, simple enough in Perl/C/choose your own poison. OK, now exectue that program. In Perl, which has borrowed some ideas from the functional paradigm it's possible, in C it's a nightmare. You have 3 choices: develop an interpreter for that language in C and pass the code to it. Spawn off a process that calls a shell script that executes the program, but if you need to communicate with the program as it is running you're going to have to jump through some extremely tight hoops. Dump the code to a text file, terminate your program, fire up the appropriate compiler/interpreter and again any interprocess communication requires significant programmer effort.

Granted this is not a problem everyone has, executing random code has caused enough problems for Microsoft Outlook already. However, for applications which support a domain specific language, usually for scripting purposes, this problem is common. So aside from the readability and maintainability advantages that functional programming advocates tout there's a problem that functional programming style supports that's difficult in a nonfunctional language. For an example of this idea writ large look at Mathematica.

Also don't confuse functional programming style with a functional programming language. Just as you can do OOP in pure C without the ++ you can do functional programming in C or more easily in Perl but most easily in Haskell, ML or LISP.
Re:When the functional paradigm is superior? by Anonymous Coward · 2002-02-08 02:02 · Score: 0

What high level languages? C++? Java? We have some
high-level scripting languages, yes. I understand
your problems, I've been circling around Haskell
about a year. Haskell has some very nice features
but I didn't get real work done with it. Then I
had a look on OCaml and wrote my next small
project in it. Now I am doing a bigger project
with it, a SIP proxy. Want some numbers?
vovida: C++, SIP header parsing and output, ~50000 LOC
SIP header parsing and output in OCaml: ~5000 LOC
maybe my parser is not as complete as vovida's,
but there's no factor 10 between them.

The Haskell guys have done a decently fast http
server in ~1500 lines of code.

You have to change thinking, that's right. But
every C++ text book praises the virtues of
constness. And that's exactly how FPLs work:
'const' is standard and 'mutable' is the exception.

Really? by AndyMouse+GoHard · 2002-02-07 04:00 · Score: 1

You would open up your machine and allow mobile .NET code to execute on it? I'm not sure I would allow that with Java, which at least has been around for awhile and has a mature security model.

There's nothing new in this game, it could very easily be done with a JXTA or Jini framework.

Bill
----------------

--
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.

Re:Really? by OSgod · 2002-02-07 08:44 · Score: 1

Could be done but hasn't.

That's the difference between success and has beens.

Gnome on windows.. by Anonymous Coward · 2002-02-07 04:01 · Score: 0

If Gnome did fully embrace Mono, would this mean that using Gnome on a Microsoft Windows/.NET OS would be possible?

Initialization speed and bytecode verification by brad.hill · 2002-02-07 04:04 · Score: 3, Informative

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.

Re:Initialization speed and bytecode verification by Anonymous Coward · 2002-02-07 04:28 · Score: 1, Informative

The CLR does check type safety and context security at runtime.

That's Because... by Tom7 · 2002-02-07 04:04 · Score: 2

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.

Re:That's Because... by zome · 2002-02-07 06:55 · Score: 1

Well, Java is not that bad (for language structure, not performance), it's C++ that's mediocre, even though I prefer C++.

Java is more pf a pure OOP language than C++, just like Haskell is a pure functional language where ML is almost

OS=MS Developers by ksschen · 2002-02-07 04:05 · Score: 1

It is ok for me, that OS-Soft runs under Windows. But I have reason to not trust Microsoft. They regularly break promises. They want to use the Open Source Programmers as an additional resource for their Operating System - fine. But I also share the mistrust of Alan Cox and others, that they may change their politics. What will we do, if everything works fine for five years, Open Source keeps its market share (why should the MS-Share decrease, when every OS-tool works with Windows and people are accustomed to it?) and then afterwards MS invents a new patented feature, that is only licensed for Windows. And everybody wants to have it. Or they will change their license-policy. Then we will be in a much worse position than we are now - MS will then have the power of MS and the power of Open Source. And most Open Source Programmers will continue contributing to MS, because their programs will continue to run on Windows. And because there will be no technical reasons to migrate to 100 % Free Software, but some technical reasons to migrate to Windows, our share will shrink. Please think about that! Timeo Danaos et Dona Ferentes! küsschen

Might as well use lisp/scheme (yes really) by ajm · 2002-02-07 04:05 · Score: 2

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.

--
development.lombardi.com

Re:Might as well use lisp/scheme (yes really) by Anonymous Coward · 2002-02-07 12:58 · Score: 0

Lisp and Scheme are very different languages, and people should stop conflating them. What you say is true of Lisp, but far from true of Scheme.

Just what IS a 'functional langauge'? by Anonymous Coward · 2002-02-07 04:06 · Score: 0

Ok, so I'm a clueless idiot. Fine.
Here's your chance to impart some clue.

Just what is a "functional language" and why does [Language X] qualify but [Language Y] does not?

Thank you for any pending enlightenment.

Re:Just what IS a 'functional langauge'? by ErrantKbd · 2002-02-07 04:36 · Score: 1

Well, you ought to pick up a book on the subject, and this may be a bad explanation.

The general idea behind a functional language is that everything can be a function. In pure functional languages, you don't assign a value to anything, but rather functions provide values. That is, you run a literal through a function and examine (or use) the result. In most functional languages however, assignment is possible, and variables often take the value of a function.

One of the implications of anything being a function is that the value of a function is oftentimes a function, in which case you have a closure, named because by running a function on a particular value, you create a particular function based upon that value, i.e. you have closed around that value (the value is stored within the created function).
Here it becomes apparent where functional languages got their name.

There are tons of other mechanisms to explore within functional languages, and like I said you should try to pick up a book on the subject. There are lots of good ones out there.
Re:Just what IS a 'functional langauge'? by Anonymous Coward · 2002-02-07 04:42 · Score: 0

To get you started, there's:

functional language
and imperative language.

The soft links here are somewhat more explanatory than the nodes themselves -- others who reply on this thread should consider this an open invitation to write up something more useful.
Re:Just what IS a 'functional langauge'? by Graspee_Leemoor · 2002-02-07 04:48 · Score: 1

A purely functional style of programming means that you never change the value of a variable, instead using function calls which take an argument and then return a copy of the argument(s) transformed in some way.

You can even see functional paradigms in visual basic 6 if you are weird like that-

Public Function allowrant(username As String) As Boolean
If UCase$(Left$(username, 3)) = "RMS" Then allowrant = False Else allowrant = True
End Function

Although it looks like you are assigning to a variable here this is just the way you return values in vb functions. The real point is the ucase$ function and the left$ function; they don't change the argument, they just return a copy of it, modified in some way.

As to why one language qualifies as functional and another doesn't I have no idea because I have yet to meet a language everyone seems to think is functional where you can't assign to variables.

(Cue for "you obviously haven't met..." posts.)

graspee
Re:Just what IS a 'functional langauge'? by Anonymous Coward · 2002-02-07 07:12 · Score: 0
Functional languages in general do not have the concept of a sequence of instructions. The 'standard' in functional languages is Haskell, you might also want to check out the Functional FAQ.
Haskell has no assignment to variables, because of one of the most important properties of functional languages (though not obeyed by all languages calling themselves functional):
- A function called with the same arguments will always yield the same result, no matter what.
As a result, you can easily reason about it, you can't make mistakes like: oh, i has already been set to 0 by now.

cool but... why? by ErrantKbd · 2002-02-07 04:07 · Score: 1

First, an interesting thing about this is that .NET really boils down to an XML parser/generator (or does it? the whole thing is a nebulus blur (surprise! another nebulous blur from the corporate world that is going to change the world!)) And XML is really just
S-expressions, which is really the whole basis if LISP. And all this time has to be spent retrofitting lisp to .NET? How well engineered can this thing be?

Having said that:
This is a great effort, and functional languages are my idol, but why spend all this energy trying to retro fit LISP to the .NET nebula? Why spend time trying to warp any good tool to fit the jacket created by one company?

.NET is just another intermediate language. Are we going to go through this every time company X comes out with an intermediate language?

Of course, this isn't just company X, it is Microsoft. And just the fact that this matters is spooky enough. But the question still stands nonetheless.

Re:cool but... why? by wadetemp · 2002-02-07 04:58 · Score: 2

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.

Thinking ecologically... by harmless_mammal · 2002-02-07 04:10 · Score: 1

Frankly, I'd feel more comfortable with the software ecology we have today than what we'll have once everybody catches mono(.NET). I want bright people everywhere to be thinking about things in as many different ways as possible. That way evolution moves forward. Robust ecologies have lots of organisms competing for survival... some of them surviving in little tiny niches for eons, and others can live just about anywhere. Monocultures have their problems: evolution slows down because there aren't any other species to mix genes with, and then there is the problem of having the entire ecology vulnerable to a single disease. But we're talking software and software development, not biology... However, I think the analogies work here. Memes (ideas, ways of thinking) replace genes, programmers and corporations replace the organisms, and money/time/mindshare replaces the resources that all are competing for. I think it's incredibly premature to think about integrating mono(.NET) memes into other projects until it's proven itself in the darwinian sense.

.NET And Multipule Languages by MissingNetLink · 2002-02-07 04:21 · Score: 2, Informative

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

Issues with Lisp and .NET... by Anonymous Coward · 2002-02-07 04:23 · Score: 1, Insightful

Some of the issues are business related, and others are technical. The Lisp vendors don't see what the CLR buys them except a new-found slowness and a lack of portability. This may change with Mono, but there are some severe architectural issues to address.

The CLR is based on the concepts of classes and single-dispatch, calling methods that "belong" to a class. Lisp's CLOS is built on multiple dispatch, and can cleanly support prototype object systems. It's hard to retrofit these capabilities onto a class and single-dispatch system, but it's easy to go the other way. Emulating multiple dispatch without the ability to re-compile on the fly leads to slow code.

And, socially, many Lispers see Java, .NET, etc. as shallow attempts to mimic what they've had for over a decade: A portable, reflective, dynamic environment. Java and many of the .NET languages leave out key portions of Lisp. Lisp allows programmers to control how the code is read, translated, and then compiled without leaving the language. You can build infix Lisp in Lisp, with all the tools of Lisp at your disposal. Or you can eschew many of the tools in Lisp, all from Lisp.

Limitations of CLR by joshwalker · 2002-02-07 04:26 · Score: 1

The page below has an interesting discussion of why the implementations of many languages on .NET will be just C# with a new "skin"

http://www.javalobby.org/clr.html

Of course, I haven't checked the facts, so it could just be FUD.

It's an ECMA standard. by SteveX · 2002-02-07 04:36 · Score: 2

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. by pubjames · 2002-02-07 04:39 · Score: 2

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. by SteveX · 2002-02-07 04:45 · Score: 2

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 by markj02 · 2002-02-07 04:40 · Score: 2

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 by Weezul · 2002-02-07 04:47 · Score: 3, Interesting

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.

--
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell

Re:COM by Anonymous Coward · 2002-02-07 05:06 · Score: 0

Ximian is working on CORBA wrappers for Mono, and since they have remained on a kick about writing everything in C#, that means the Microsoft implementation will immediately benefit, and have classes that can speak CORBA.
Re:COM by unclefucknut · 2002-02-07 05:40 · Score: 1

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.
COM and .NET does not automatically exclude CORBA. The desktop perhaps doesn't need CORBA (never has, never will..? I'm not an expert on CORBA, but the last time I read about it, it didn't feel very snappy/light weight). CORBA is however still a good choice for heavy weight distributed systems.
And I see nothing that will make CORBA obsolete with .NET framework. Instead, I see new implementations which utilize .NET so that you can use ONE implementation of CORBA in many languages w/o the need to reprogramming it for each language.
Also, open source is become more popular on the windows platform. Ever looked at CodeProject or Codeguru? These are two of hundreds of good open source sites. Most of its user base however, do not generally like the GPL. Odds are that they use a BSD style license (I have seen some LGPL'd code though). Anyhow, I could very well imagine that someone implements a .NETified CORBA implementation (or bridge). There are legacy systems which use CORBA, and there are situations when DCOM won't do the trick. And there are Windows platforms which ultimately have to communicate with these systems. Thus, someone will make a .NET CORBA implementation and sell it. And then someone just don't want to pay for it. Then an open source implementation is born.
One implementation to rule them all... ;)

Re:Question by CyberDruid · 2002-02-07 04:53 · Score: 1

I checked out both links and it seems like you know your stuff ;). Thus I have a question for you.
I have drifted more and more towards functional programming. In fact, even my C++ is starting to look more and more functional, with lots of small functions and the occasional recursion. The logical step for me is to try out some functional languages and see if I find anything I like. I did this and ML was the one I liked best (mainly for 2 things: efficient compilers and possibility for an imperative style when that is the best solution).
The questions: What are the differences between ocaml and SML/NJ? Are there other mature ML-dialects (preferably with compiler, debugger, profiler and perhaps a plugin for glade, etc)? I have tested ocaml on some smaller programs and is quite pleased with it. Is there any reason why I should consider SML instead?

--

Opinions stated are mine and do not reflect those of the Illuminati

GNOME and .NET change of heart - another idea by RailGunner · 2002-02-07 04:53 · Score: 1

You can almost count on Microsoft adding goodies, and Mono will always be catching up to be compatible with Microsoft.. unless... Why don't we (the open source community) BEAT Microsoft at it's own game? Once Mono is released, let's embrace it and extend it to where beautiful UI features and widgets will run under Linux but *not* under Windows. Certainly if enough open source developers start contributing, just by sheer numbers we'll pull far ahead of Microsoft. This is a much better path then trying to match MS's offering bug for bug.. The key to success is building a better mousetrap, not the same mousetrap for a lower cost. Brand loyalty matters...

Re:GNOME and .NET change of heart - another idea by TheAwfulTruth · 2002-02-07 05:51 · Score: 2

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.

--
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
Re:GNOME and .NET change of heart - another idea by ClosedSource · 2002-02-07 06:11 · Score: 1

I agree. I think the idea that MS fooled Windows developers into thinking they could write applications using Windows Foundation Classes and have them run on any platform is absurd.

MS documented the fact that WFC was targeted for Windows:
"The combination of this class framework and RAD tool make it easy to build fast and powerful applications and components for the Microsoft platform using the Java language."
Re:GNOME and .NET change of heart - another idea by Anonymous Coward · 2002-02-07 06:34 · Score: 0

ROTFLMAO
Re:GNOME and .NET change of heart - another idea by ahde · 2002-02-07 17:06 · Score: 2

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:GNOME and .NET change of heart - another idea by Anonymous Coward · 2002-02-07 17:49 · Score: 0

But a lot of those classes are from namespaces like System.Drawing for example and are (and should be) very platform specific. Thanks to reflection, Mono can easily mimick the behavior of these classes and optimize them for Linux.

I'd rather have 3 optimized sets of drawing classes (one set for Linux, OSX, and Windows) then one cludgy slow performing set (eg. swing).

It's not going to be portable, folks by nagora · 2002-02-07 04:55 · Score: 3, Insightful

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

--
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"

Re:It's not going to be portable, folks by nvrrobx · 2002-02-07 07:57 · Score: 1

People seem to be quick to forget that there's a difference between the .NET Framework (what Mono will be implementing) and the .NET Initiative. The .NET Initiative includes things like Passport.NET, Hailstorm, the servers, etc. The Framework is just a core set of APIs, the CLR, VM, etc.

Microsoft doesn't have to make their VM portable. That's not really their job. If developers on another platform want it, then they'll have to implement it. For example, Java doesn't exist on the Amiga because Sun ported it there.

I don't see how the Framework being implemented on other OSes will be a problem? I see it as more of an advantage than anything else.

BTW, All of the releases of the .NET Framework have been freely downloadable off of MSDN. Keeping up with the changes through the betas wasn't all that difficult. It didn't require any cost except for maybe your time and your 'Net connection.
Re:It's not going to be portable, folks by brunes69 · 2002-02-07 09:10 · Score: 2

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 by nagora · 2002-02-07 11:48 · Score: 2

.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

--
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Re:It's not going to be portable, folks by brunes69 · 2002-02-09 03:37 · Score: 2

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.

hmm... do me a favor by Abnornymous+Howard · 2002-02-07 05:08 · Score: 1

Save your above comment ot disk or print it out. In a few years bring it forth, reread it and whipe your tears at your naivism.

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

In the US (and in an internet perspective that's what counts) it has been proved that anything can be patented so don't hold your breath. OneClick shopping anyone?

.. They might be able to lock up some minor details but it is the concept that matters. ...

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.

Nobody is going to force you to use it but if it is going to increase developers productivity then why not?

See above... Maybe small projects won't be forced, but in major companies it's not the programmer who decides and he seldom has much to say. And small projects is not what MS is conserned about. They want the big bucks.

btw... I'm saving my own comment.. ;-)

//A.H.

Re:hmm... do me a favor by elflord · 2002-02-07 05:20 · Score: 2

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:hmm... do me a favor by Abnornymous+Howard · 2002-02-07 05:47 · Score: 1

They could also add a "graphical widget" to perl, C++, C, or any other standard.
No, you couldn't add it if it's been copyrighted.
... but they can in fact do the same to any standard. ...
No and yes. They tried to extend Kerberos but failed cause it wasn't theirs to extend and it was already widely adopted. If they'd try to extend TCP/IP they'd (hopefully) fail too. 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...
//A.H.
Re:hmm... do me a favor by elflord · 2002-02-07 07:02 · Score: 2

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.

Prolog... by Gingko · 2002-02-07 05:09 · Score: 2

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

--
i don't do sigs. oops.

They'll need to carry a patent notice by yerricde · 2002-02-07 05:13 · Score: 2

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.

--
Will I retire or break 10K?

True, but largely irrelevant over time by Ars-Fartsica · 2002-02-07 05:18 · Score: 2, Insightful

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 by JohnsonJohnson · 2002-02-07 06:02 · Score: 1

So essentially the CLR and the .NET framework on top of it must necessarily be the most productive way of producing code? Given the horror that is Win32, with which I have first hand experience and the wounds to prove it, I seriously doubt Microsoft's ability to develop the uber-productive framework while simultaneously meeting the demands of maintaining share price with regular updates of the API and eliminating threatening programs by swallowing whole applications as portions of the next version of the API. In their domain the so called "exotic" features are very natural. For example, symbolic processing in an imperative language almost always necessitates writing of a parser (or using one from the framework). 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. When writing a computational algebra application therefore it is far more difficult to turn expressions into evaluable functions and then evaluate them in an imperative style than a functional. Granted not everyone needs a computer algebra system, but you'd be surprised at the number of people who use one and .NET has nothing to offer them. There are many other processing domains beyond the timely provision of paychecks based on information stored in an Oracle database for which languages with "exotic" features result in far more programmer productivity than most people are willing to give credit for. This whole discussion actually is an opportunity for open-source to address a problem: appropriate tools for domain specific tasks (of which producing the GNOME GUI is one) rather than adopting the solution of a proprietary code vendor. Most of all, the CLR address a specific business problem Microsoft has: that too many serverside applications are being written in Java because a lot of developers prefer the Java framework to BackOffice. All other hype aside that's the fundamental reason for the existence of C# and the CLR. The other portions of .NET from Passport to Hailstorm similarly are responses to the problem of maintaining Bill Gates' personal wealth as opposed to Larry Ellison's, Steve Case's and Scott McNealy's. The technical problems of programmer's in the pits are only an aside in this much larger overall picture. Miguel made a point, there is a technical need in GNOME for language interoperability. His answer however was to accept a solution that has too much baggage tied to it. I think Alan Cox's responses were an attempt to make Miguel see the light. Are there pieces of the CLR that are valuable? Probably, but not many. The free and open software movements (I've wandered a bit too far off topic here so I'll stop soon) should be aware of what proprietary software vendors are doing. But when a deficiency is apparent (such as the lack of a cheap, robust Unix-like kernel for x86 hardware in the early 90's) free and or open software developers should develop solutions that solve thier own problems, not Microsoft's.
Re:True, but largely irrelevant over time by Ars-Fartsica · 2002-02-07 06:11 · Score: 2

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.

For anyone interested by a3d0a3m · 2002-02-07 05:27 · Score: 1, Informative

Here is a link to an introduction to Moscow SML implementation, which has alot of good beginner info. And here is a link to SML .NET info, which is what you'll need to use to code SML apps for windows.

Re:No its Bill Gates that is Stupid by bryanbrunton · 2002-02-07 05:34 · Score: 2

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.

Continuations and Generators/Coroutines by ClarkEvans · 2002-02-07 05:52 · Score: 1

Does CLR support continuations?

Re:Continuations and Generators/Coroutines by mikera · 2002-02-08 00:49 · Score: 1

Nope. Not in a first-class sense anyway.

You can get the same effect by wrapping up code in a bunch of objects and passing them around in a continuation-like manner if you want, but I guess that would be just re-inventing the functional langauge wheel in a very inefficient manner.

They did add some support for tail recursion though.

does this mean.. by monkey_jam · 2002-02-07 05:53 · Score: 1

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

So as long as its turing-complete, .NET could work with it? So can someone get cracking with BrainF***) and Befunge 93?

Re:does this mean.. by Anonymous Coward · 2002-02-15 04:41 · Score: 0

Like this? :)

you forgot AutoCAD/AutoLisp by Anonymous Coward · 2002-02-07 05:56 · Score: 0

you forgot AutoCAD/AutoLisp - one of the first embedded languages in a major package.

Mod parent up! by affenmann · 2002-02-07 06:01 · Score: 1

Too bad I can't anymore.

.net will help by EnglishTim · 2002-02-07 06:01 · Score: 2

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.

Biggest oxymoron? by d2ksla · 2002-02-07 06:16 · Score: 1

If you want a high-performance functional programming language

Boy, and I thought "military intelligence" was the biggest oxymoron ever.

--

Freevo - Linux Multimedia Jukebox

Re:Biggest oxymoron? by markj02 · 2002-02-07 06:33 · Score: 3, Interesting

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.
Re:Biggest oxymoron? by Courageous · 2002-02-07 07:17 · Score: 2

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? by markj02 · 2002-02-07 07:39 · Score: 2

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:Biggest oxymoron? by Courageous · 2002-02-07 08:20 · Score: 2

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//
Re:Biggest oxymoron? by markj02 · 2002-02-07 11:41 · Score: 2

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:Biggest oxymoron? by Courageous · 2002-02-07 19:38 · Score: 2

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

Why Functional Programming Matters by dstone · 2002-02-07 06:17 · Score: 5, Interesting

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 by Anonymous Coward · 2002-02-07 08:24 · Score: 0

so basically you disallow static variables and pointers, and allow the implicit creation of coroutines by the compiler. and then this somehow magically results in modularity? yeah.. right :P
Re:Why Functional Programming Matters by Anonymous Coward · 2002-02-07 09:57 · Score: 0

Nope. Modularity results when programmers with a clue use good tools. Functional languages may well be better tools for modularity. But expect a learning curve. And until then, know how to code modularly as best you can in your imperative language.
Re:Why Functional Programming Matters by Kanasta · 2002-02-07 13:19 · Score: 2

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 by Shade,+The · 2002-02-07 13:44 · Score: 1

As I'm doing a course in it now at University, I'll agree with you about how much of a pain it is to program. But there are simple ways in SML at least to iterate, even though such methods may look recursive. Or perhaps I'm getting confused. I never professed to actually getting to know SML that well :)
Re:Why Functional Programming Matters by dstone · 2002-02-07 20:37 · Score: 2

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 by telstar · 2002-02-07 06:20 · Score: 2, Informative

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... by Da+VinMan · 2002-02-07 06:21 · Score: 2

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.

--
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!

Continuations & Scheme by Postmodernism+is+Dea · 2002-02-07 06:31 · Score: 1

Mainly I am worried that Scheme continuations didn't make it into .NET. Does anyone know more about this?

Re:Continuations & Scheme by daytrip00 · 2002-02-07 07:48 · Score: 2, Informative

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.

Beg to differ! by krokodil · 2002-02-07 06:35 · Score: 2

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! by An+Ominous+Coward · 2002-02-07 07:00 · Score: 2

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! by Courageous · 2002-02-07 08:08 · Score: 2

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 by Tom7 · 2002-02-07 06:51 · Score: 2

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

Slashdotted Slashdot? by Bodrius · 2002-02-07 07:16 · Score: 2

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?

--
Freedom is the freedom to say 2+2=4, everything else follows...

Real-world speed comparison by Oink.NET · 2002-02-07 08:19 · Score: 1

The Java Pet Store, Sun's J2EE best practices blueprint application, was rewritten in C#. It took 1/4 the code and performs anywhere from 15 to 28 times faster than J2EE. Check it out here. Debate on how it was done can be found here.

Re:Real-world speed comparison by SimonK · 2002-02-10 07:43 · Score: 2

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.

Functional Programming in XSLT - yes! by Random123 · 2002-02-07 08:23 · Score: 1

Dimitre Novatchev has published a proof for functional programming called "The Functional Programming Language XSLT - A proof through examples"

Until now it was believed that although XSLT is based on functional programming ideas, it is not as yet a full functional programming language, as it lacks the ability to treat functions as a first-class data type. Based on numerous concrete XSLT implementations of some of the major functional programming design patterns, including some of the most generic list-processing and tree-processing functions, this article provides ample proof that XSLT is in fact a full-pledged functional programming language. The presented code forms the base of a first XSLT functional programming library. It is emphasized that a decision to include higher-order functions support in XPath 2.0 will make functional programming in XSLT even more straightforward, natural and convenient.

The interesting question here is SHOULD XSLT be used in this way?

HotSpot beats VC++? by Anonymous+Brave+Guy · 2002-02-07 08:51 · Score: 2

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

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.

Numbers please... by OSgod · 2002-02-07 09:01 · Score: 1

It could be true -- but I'm not betting on it.

I think you'll find

VB
C
Java

In that order for the enterprise counted in # of developers employed... although powerbuilder might be above Java.

Then again -- i have no numbers either and would be interested in seeing some.

This came from an "emulator" discussion by yerricde · 2002-02-07 10:13 · Score: 1

[In practice, Turing completeness] means the language (or system) can compute the same functions as can a Turing machine, with the understanding there are finite resources.

OK. "Turing-complete with storage restricted to 128 MB" I can handle. I first began to point this out in a discussion on one of the Transmeta articles to somebody who argued that a Crusoe processor can in theory recursively emulate itself because it's "Turing complete." I responded that for each layer of emulation, you'd need additional storage (at least 1 KB for registers and 16 MB for the decode cache). Metacircularity for a system (often talked about in Lisp books) requires at least a constant amount of additional storage for each virtual machine, and you eat this overhead when you run a program inside JVM, CLR, VMware, Bochs, plex86, anything.

--
Will I retire or break 10K?

Re:This came from an "emulator" discussion by JamesOfTheDesert · 2002-02-07 15:56 · Score: 1

I do see your point. Saying two languages are essentaily equivalent if they are both Turing complete becomes acdemic if, to have one language emulate the other, you need unreasonable time and resources.
I think this applies to FP on .net; the concern was would would it take to get all of the features of a given a language emulated in CLR.
Sure, it can be done, but if it takes an hour to produce 'Hello, World!', then there is little value (other than prompting discussion on /.).
(I write this as I install Linux under VMWare on Windows 2000. )

--

Java is the blue pill
Choose the red pill

Embrace and Extend by Anonymous Coward · 2002-02-07 17:26 · Score: 0

Isn't this the definition of Embrace and Extend?

MS is embracing the whole Java run-anywhere thing, and now they are extending it to go faster...

This technique has been used to kill other companies and technologies before, and once .NET becomes the standard on both Linux and Win32, they will have complete control over us.

Perhaps we should generate our own technologies/work on older, portable standards that aren't currently controlled by MS?

Sure, Linux was built by copying other technologies, but the reason Linux is so successful is that it is not _controlled_ by any company. EG: If SUN changed the format of the ls command, we would not care. If Linux apps are ported to the new .NET CLI system, and MS changes X that we now rely on, we are sunk.

Surely this is part of the master plan to rid the world of Linux?

Re:What about speed? Compiled Java! by drpatt · 2002-02-08 08:54 · Score: 1

Just one more...
On a creaky 500MHz Celeron, 184MB RAM...
Java 1.3: 185s (using only Sun JDK).
C#: 116s.
Java 1.3 108s (compiled to EXE with JET 2.1)

Slashdot Mirror

Functional Languages Under .NET/CLR

344 comments