Microsoft Open Sources F#
aabelro writes "Don Syme has announced the release of the F# compiler source code as a code drop under Apache 2.0. He wrote, 'The F# PowerPack now includes libraries, tools and the compiler/library source code drops. I'd like to take a moment to explain the F# team's approach to this. Firstly, the source for the F# compiler in our MSI/CTP releases has been available for some time, in the releases themselves, so in that sense there's not much new in this release. Secondly, we've always made sure we have a free download binary release of F# available, and will continue to do that, and that should still be the main way you "get" a release of F#. However, we've long discussed making compiler+library source available in a different way. After some discussion, we've decided to do this via a "code drop" model, where we make available versions of the compiler+library code logically matching each release of the F# language itself.'"
Almost seems like their thought process is:
"We aren't going to get more resources in-house to continue developing it. Maybe if we throw it over the wall we'll get something (for free) from the Community."
There's always a catch, in this case you'll stop using other development platforms and produce apps that will only run on dotNET ..
Does F# compile to a stand-alone executable on any platform, or does it need to be deployed on a .net framework?
Not to mention the projects on Codeplex, which is pretty much Windows only...
"This is a prelude to cancellation."
Too bad, if true. From a technical perspective its a good language, a respectable entry in the world of functional languages. Its one of the Microsoft-developed tools they appear to have gotten right, in my opinion.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
I'd say that for all practical purposes, at least in my limited testing, the performance you get from the code running on CLR is not appreciably worse from what you get with OCaml's native code, so I don't see any real benefit of OCaml's native code over code running on CLR. I've found plenty of cases where CLR outperforms OCaml by an order of magnitud -- basically as soon as you use OCaml to the fullest, plenty of POD stays boxed, and everything goes downhill from there.
A successful API design takes a mixture of software design and pedagogy.