Functional Languages Under .NET/CLR 344
Numen writes "With all the talk of .NET being thrown about there is a common factor occuring through many discussions, namely the claim that .NET will be unable to address functional and logic languages such as Prolog and LISP.
To this end I would like to drawn peoples' attention to two resources, that shown how this may well be a non-issue, and to ask, does this change anybodies mind?
"
Look deeper... it's not that bad. (Score:2, Informative)
Hell is freezing over and pigs are sprouting wings (Score:2, Informative)
I've just started to scratch the surface of what
GNOME and .NET change of heart (Score:4, Funny)
Re:GNOME and .NET change of heart (Score:5, 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). The idea that any vendor could release code that would run on 100% of the computers out there, not just 95%, would be a godsend.
While .NET, and efforts by Miguel and Ximian to create Mono, and probably similar efforts inhouse at Apple, appear to offer the same promise, I still expect that we'll see a lot of Windows-specific hooks that would prevent a good chunk of code of being cross compatible. Not that one can't write fully compatiable .NET code that runs everywhere, but I would not be surprised if MS offered programming goodies (cool widgets, eyecandy features, etc) that would be easily be limited to Winboxen and leave other implimentations of the virtual machine out in the cold.
Re:GNOME and .NET change of heart (Score:5, Insightful)
I am constantly amazed at the complete LACK of understanding about what
Honestly! It's all Object Oriented; there is NOWHERE to hide anything from anyone! Implementation is another issue, but by virtue of the platform itself all the interfaces have to be public and accessible, which means they can be easily emulated. That's what mono is trying to do with WindowsForms; its the GUI component that Microsoft said was going to be Windows-only, except they are already working on emulating the public interfaces (though the implementation would be calling gtk/x)
Please... THINK about this stuff before you post it. Its no like Sun can go and hide some new solaris-only hooks in the JVM that suddenly make it incompatible with other platforms! In order to have developers use the new hooks, they have to make them public, and then anyone could create a compatible class for their platform of choice.
Re:GNOME and .NET change of heart (Score:2)
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 (Score:2, Insightful)
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 (Score:3, Interesting)
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 (Score:2)
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 (Score:2)
...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 (Score:2)
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 (Score:3, Informative)
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 - another idea (Score:2)
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
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.
Re:GNOME and .NET change of heart (Score:2)
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.
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.
A Valid Question (Score:2)
Uh... what exactly made you change your mind?
In my opinion, Miguel was just avoiding answering the real issue:
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
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.
Mondrian for .NET (Score:4, Informative)
Here's a blurb from Dr. Dobbs:
Mondrian is a modern, purely functional language specifically designed to leverage the possibilities of the
Re:Mondrian for .NET (Score:2)
Re:Mondrian for .NET (Score:2)
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/pape
The one caveat is that you need to be able to pass unboxed values around at the vm level. I seem to recall CLI does this.
Who thought this? (Score:2, 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
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? (Score:3, Informative)
For example, scheme is hard to compile towards the JVM or standard C because both lack proper tail call implementation (poping the parameters in the stack before calling a function in tail position).
You can of course circumvent this because as you say the target language is Turing complete, but you lose a lot on performance if the target isn't tailored to this particular use.
Re:Who thought this? (Score:2, Informative)
Yes, the problems seem similar to the attempts to compile functional languages (e.g. Haskell or ML) to the JVM.
Functional languages have a lot of very short lived objects (functions that are evaluated) without identity and local storage.
The JVM (and
It's this mismatch that makes it hard to use functional languages *efficiently* with
Anywat, I really love to see the people at MS addressing this problem. But after all, GHC, *the* Haskell compiler is being developed at MS research.
Re:Who thought this? (Score:3, Interesting)
Re:Who thought this? (Score:3)
Re:Who thought this? (Score:2, Insightful)
The question has to do with getting the language to run well, and correctly, on a stack-based VM.
There is no such thing as "Turing complete" (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.
Re:Who thought this? (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? (Score:4, Insightful)
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
What about speed? (Score:5, Interesting)
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
Also, is there any overhead for languages that aleady use a VM (eg, python, perl) if they switch to
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? (Score:2, Informative)
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? (Score:3, Interesting)
Disclaimer: my position on
Re:What about speed? (Score:3, Interesting)
JIT is short for Just In Time *Compiler*. A JIT compiles Java bytecode to native code prior to running it. It is in fact this compilation which lead to the slow startup time visible under Java 1.1 and 1.2 (without HotSpot), because the JIT could not interpret code. It had to compile *everything*, even if it was just initialization code which would only run once.
HotSpot, the next generation of VM technology which is integral to Java 1.3 and 1.4, features an interpreter which is used initially. This gives HotSpot very fast startup time, because it initially does no compilation. As HotSpot decides that a particular method needs to be compiled, it does so in a background thread while continuing to run the interpreter. When the compilation is finished, it swaps in the native version (the current version can do this even if it is in the middle of running the interpreted version). This gives HotSpot two big speedups: firstly, because it uses the interpreter initially, startup is faster, and secondly because it compiles fewer methods (IOW, only ones which actually benefit from compilation) it can spend more time optimizing each method.
HotSpot beats Visual C++ in most benchmarks. It is damned cool technology, and most people that claim Java is slow haven't played around with it in a long time. Java 1.4 is ripping fast.
Re:What about speed? (Score:2)
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
http://slashdot.org/article.pl?sid=00/03/23/106
Re:What about speed? (Score:2)
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 [javalobby.org], the IBM JVM beat VC++ in a variety of standard benchmarks. These aren't artificial "allocate a million objects" benchmarks; they're things like neural nets and FFTs which are actually done in real life. Go read the report.
It's worth noting that the Intel C++ compiler did a lot better, but the fact is that if Java is better than Visual C++, it's good enough for the masses considering that the masses are happy with Visual C++. (Remember that GCC sucks ass performance-wise, and most Linux fans are perfectly happy with it).
Re:What about speed? (Score:2)
tar zxf someprogram.tar.gz
cd someprogram
./configure
make ; make install
Re:What about speed? (Score:2)
A) average users could never do that
B) it doesn't allow for seamless installations
C) it takes forever
and,
D) it frequently doesn't work on the first try
Try out Java Web Start if you want to see how applications should be installed.
Re:What about speed? (Score:4, Interesting)
Okay, running IIS5, WIn2000, Visual STudio
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
Re:What about speed? (Score:2)
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.
Yup... (Score:2)
I could go on and on, but I will just contain the rant.
Initialization speed and bytecode verification (Score:3, Informative)
Re:What about speed? (Score:2, Informative)
Java (IBM 1.3) 4496 ms
C 4716 ms
C# 8582 ms
boy, good thing (Score:3, Funny)
nice solution to a non-issue.
Re:boy, good thing (Score:2, Informative)
think.
http://www.franz.com/success/
Here, I included a few of them....
Pro/ENGINEER
Ascent Technology, Inc.
Application: ARIS
PricewaterhouseCoopers
Application: Comet and Planet
NASA
Application: Mars Pathfinder Mission's Planning System
Space Telescope Institute
Application: Spike: Hubble Telescope Scheduling System
Square USA Inc.
Application: Phantom
What's to change (Score:2)
The real problem is Microsoft. It might be a cool technology, but Microsoft wont think twice before taking their ball and going home with it.
Mark my words: If it happens, it'll all end in tears.
Could work out well for the KDE guys though
Standard ML and Haskell implementations (Score:3, Insightful)
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 (Score:3, Interesting)
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 (Score:4, Interesting)
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
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 (Score:2)
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
True, but largely irrelevant over time (Score:2, Insightful)
Re:True, but largely irrelevant over time (Score:2)
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.
Tail calls and dynamic typing (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?
well, not quite (Score:2)
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.
Think maybe better not (Score:2, Interesting)
Why?
It solves problems. Let's assume it solves problems. Such as, you can write in different languages. Even use objects as objects (!) in different languages. To some extent. That is the impressive part.
There is also a virtual layer. It has been compared to the JVM. I am not going to compare it to the JVM. I am not even calling it a virtual machine. That is not to disparage the effort -- but .NET is much bigger than just a virtual machine. One could also convincingly argue that a virtual machine is not, ultimately, the most interesting part about efforts such as .NET.
Efforts such as .NET. What kind of efforts are there that are like .NET? What is .NET? Nobody seems to know, really.
It is good to see that the .NET APIs and interfaces are being picked up. This is most certainly where a lot of .NET value is. Perhaps even most of the value. Who knows? Of course there is a lot of geewhiz computer science in .NET that you could also point out as desirable. The Python and Eiffel crowds will know. But personally; I believe a good solid API is worth a lot of, um, computer science.
Just to indicate how broad .NET really is. There is something there to please everyone. It's "virtual", but in a comfortably ill-defined myriad of senses, and it's great computer science, but it also means business.
If it succeeds, it might almost bring Microsoft in line with the rest of the computing world (UNIX). That is, peer review, sane architecture, sane libraries.
Right. So what is wrong with GNOME that can't be fixed without first creating, then resorting to Mono? Well, we don't have all the language bindings that .NET would offer. We would get a uniform API across languages for many things. Well, actually of course we would get excellent integration for oft-used languages, and languishing thesis project kind of support for lesser used languages.
Which is pretty much the way it is now. If you want to do text, you use Perl. If you want to do anything else, you use C. If you want to get virtual and a headache, you use Java. If you want to do computer science, you use Python.
Does anybody really believe that this will be any different under .NET? And when? How long will it take before we even reach that point? Would that time not be better spent making GNOME even better than it already is? How about writing some more documentation? If writing hundred lines of documentation fixes 400 potential errors now, versus .NET fixing thousands of potential errors in two, three years time -- what constitutes the better investment in our freedom?
Think strategy, not technology (Score:3, Offtopic)
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
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
That's why I despair when I hear people in the Open Source community talk about implenting stuff in
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 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 (Score:2)
It's an ECMA standard. (Score:2)
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. (Score:2)
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. (Score:2)
The core stuff, the CLR and the language, are covered by the ECMA standard.
- Steve
Re:Think strategy, not technology (Score:2)
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 (Score:2)
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
So microsoft pulls out the rug from underneath us and somehow prevents further interoperability with future
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 (Score:2)
> 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
> 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 (Score:2)
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:hmm... do me a favor (Score:2)
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 (Score:2)
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.
Re:Think strategy, not technology (Score:2)
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.
.NET is a quagmire (Score:4, Insightful)
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
Re:.NET is a quagmire (Score:2)
And TCP/IP makes a terrible 3D graphic API.
- Steve
Re:.NET is a quagmire (Score:2)
" 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
It's the API's stupid. (Score:2)
But the API's
I'm singularly unimpressed by claims that the
What the
But the patent stuff
They'll need to carry a patent notice (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 [inventorfraud.com] on every single copy of Windows, or perhaps even require every developer that uses VB.NET to put patent notices on their software.
Re:No its Bill Gates that is Stupid (Score:2)
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
And prior to
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.
it really doesn't matter (Score:5, Insightful)
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.
Re:Biggest oxymoron? (Score:3, Interesting)
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? (Score:2)
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? (Score:2)
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? (Score:2)
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//
Microsoft Haskell Press Release (Score:2)
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
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)
Efficiency and convenience (Score:3, Insightful)
To take one example, in Lisp you can pass nameless functions quite easily. So you might have a library that has a function to create a new button. One of the arguments to the function is a function that the library will execute when the button is pressed. In Lisp this is a trivial thing, you just create a function and pass it as the argument. But if nameless functions are not supported by the virtual machine, then this operation becomes very problematic.
What if the nameless function is created dynamically by the program? How can the virtual machine compile this nameless function to native code before running the program? Unless the virtual machine knows how to compile Lisp code, it cannot. It may be that the Lisp library must be changed to accept some other form of argument for the callback for efficiency reasons. If most of the work you do is just calling libraries and putting things together, you just lost one of the biggest features of Lisp. You have to trade off efficiency and convenience. If you use a native Lisp virtual machine, you have both efficiency and convenience.
Haskell (Score:5, Informative)
I took a look around and found this link to a guy called Don Syme [microsoft.com] at Microsoft Research who appears to be working on just this.
There's also the Mondrian [mondrian-script.org] project, which implements Haskell.
Re:Haskell (Score:2)
What a major Lisp vendor says: (Score:2, Informative)
See http://groups.google.com/groups?hl=en&frame=right
Obviously, the vendor may have reconsidered their point of view. (I have no association with this company)
Excerpt:
"
rcena@epcor.ca (Resty Cena) writes:
> Is anybody working on a Lisp port to the
> that Microsoft
> shops.
We at Franz looked at it, and rejected it. The major reasons for
us deciding not to proceed were
1. It would slow our lisp down tremendously. I don't rememeber the
exact estimates, but I would guess and wouldn't be surprised if
the slowdown would have been on the order of 10x.
2. More than a hardware emulation, where the "hardware" provides
primitive functionality and we language vendors are able to use
this functionality however we see fit,
software is constrained to conform. Thus, we would have to change
our calling sequence, object, typing, and gc architectures to
conform to
3. The result would be MS specific, and not portable to other systems.
This point is weak, because it is conceivable that
is being ported to other operating systems, but at the time we
looked at it, it had no buy-in from any other operating-system
vendors.
SML.NET (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/ [microsoft.com]
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 [slashdot.org]
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 [sourceforge.net]
SML vs O'Caml (Score:2)
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..
Might as well use lisp/scheme (yes really) (Score:2)
.NET And Multipule Languages (Score:2, Informative)
language will get the same level of support under
COM (Score:3, Interesting)
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
It's not going to be portable, folks (Score:3, Insightful)
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
Prolog... (Score:2)
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
Why Functional Programming Matters (Score:5, Interesting)
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.
Beg to differ! (Score:2)
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
Re:Beg to differ! (Score:2)
Jumping to make yourself look smart generally results in the opposite.
Re:Beg to differ! (Score:2)
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//
Slashdotted Slashdot? (Score:2)
Can slashdot be slashdotted?
Re:the promise of functional programming... (Score:2)
That's Because... (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.
.net will help (Score:2)
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.
Re:Real information (Score:2)
Could you say more about this? Discussion on comp.lang.scheme [google.com] said that the CLR does support tail calls, though support for continuations is not there.
Re:Lisp is also object-oriented (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. :-)
Re:Terrarium (Score:2)
Don't try the "NakedBabe" option though, you'll just get surrounded by hungry carivores...
Re:cool but... why? (Score:2)
No, not really at all.
Re:Continuations & Scheme (Score:2, Informative)