One of the important themes in programming languages over recent years has been a move to embrace ideas from functional programming.
Language features such as lambda expressions in C# and generics in .NET 2.0 have roots in functional languages, and LINQ is directly based on functional programming techniques. Through LINQ and Parallel FX, ideas from functional languages are helping us address some of the biggest challenges facing the industry today, from the impedance mismatch between data and objects to the challenges of the multi-core and parallel computing space.
Several of these key technologies have started out as projects in Microsoft Research. One of the really promising current projects from MSR is the F# programming language, spearheaded by Don Syme. F# stems from the functional programming tradition (hence the ‘F’) and has strong roots in the ML family of languages, though also draws from C#, LINQ and Haskell. F# is designed from the outset to be a first class citizen on .NET. This means that F# runs on the CLR, embraces object-oriented programming, and has features to ensure a smooth integration with the .NET Framework.
I am a big fan of technology transfer between a research organization and a product development organization so that we can “productize” the great research ideas and deliver to customers in a timely manner. This is one of the best things that has happened at Microsoft ever since we created Microsoft Research over 15 years ago. Here is another great example of technology transfer at work. We will be partnering with Don Syme and others in Microsoft Research to fully integrate the F# language into Visual Studio and continue innovating and evolving F#. In my mind, F# is another first-class programming language on the CLR.
Our interest in F# is motivated by several factors. As I mentioned above, we aim to continue the flow of good ideas from functional programming world into mainstream development. Furthermore, the somewhat mathematical slant of functional programming just seems naturally appealing to professionals whose primary domain is described with mathematical notation - domains such as financial, scientific and technical computing. On top of the syntactic appeal, the strong type system yields the sort of guarantees which are often crucial in these domains, and enables a superb tooling experience through Visual Studio.
Another motivation is to continue to invest in making the .NET Framework a great choice in academia. Many computer science departments around the world teach functional programming languages today. We believe that through F# and languages such as IronPython and IronRuby we can help offer students and educators choices beyond the current mainstream and enable the use of these languages across the curriculum. This helps educators have the option to use Visual Studio as a consistent tool set from course to course.
You can find out more about F# in Don Syme’s blog, and at http://research.microsoft.com/fsharp.
Namaste!
PingBack from http://www.artofbam.com/wordpress/?p=9494
The F# license still requires me to statically link the F# libraries for any commercial purpose:
http://research.microsoft.com/fsharp/fsharp-license.txt
Which means, that any F# type, like Tuple<A,B>, will in fact be two different types when you link two F#-compiled assemblies. Not a very workable procedure. If you're serious about making F# a first class .net language, I'd start with a fix to that license.
Otherwise, this is fascinating stuff!
Actually, I have tried to play with F# a year (or two?) ago but that wasn't ready to be played with :)
Ability to combine .NET imperative languages based projects (for UI and part of the business logic) with functional language based ones lokks bery promising. That would be really great.
Does F# allow such combination? Can I for example incapsulate all my scientific calculations logic into F# project and then use its output dll in my C# UI project?
Dmitry: yes. The way ML constructs are mapped to CLR types is pretty clean, with good use of generics.
Thanks for the answer. Will try F# again to create working application in combination with C#.
This looks like Microsoft's solution to Python.
Somasegar, the head of the Developer Division at Microsoft, has announced the productization of F#. Read...
Somasegar Announces Productization of F#
Very cool. I'd say the idea of using F# for real projects is getting closer to a pragmatic reality
Finally. I hope that MS embrace the communities of other popular functional languages like Haskell to
Having bought and worked through half of the F# book, my opinion is that this language will never gain mainstream acceptance. Unlike other functional languages such as Nemerle, the author thought it important to stick closely to the OCaml method of expression. The reason that I walked away from the book and the language is that I found the syntax a huge obstacle to understanding the fundamental concepts. Realize that I am always experimenting with new languages - it is like a hobby of mine (I am currently looking into Erlang). For someone like me to disparage F# means that the likelihood of the average .Net programmer picking up this language is vanishingly remote.
My brother Peter Plamondon and I started Project 7 at Microsoft, which was the code-name for an effort to (a) get the .NET & Visual Studio.NET products opened up to non-Microsoft languages and (b) get non-Microsoft languages implemented on .NET.
You might think that this was "obviously" the right thing to do -- we certainly did! -- but at the time (1998-99), we had to fight all the way up to the #3 guy at Microsoft, Paul Maritz, to get approval and funding for the project (thanks, Paul!).
There was a LOT of resistance. Microsoft had just been burned by a non-Microsoft language -- Java -- and there were those who felt that Microsoft should be actively suppressing the emergence of new languages, not facilitating it. Fortunately, Paul recignized that the emergence of Java proved that Microsoft could not suppress the emergence of new languages...and that it shouldn't WANT to do so. Better to encourage their emergence, and to make it super-easy for them to emerge first, best, and only on Windows. This is what's happening now with languages such as F#.
In Project 7, Peter handled the commercial languages; I handled the academic languages.
One of the main reasons I wanted to open up .NET and VS.NET this way was to facilitate the miscegenation of programming languages -- the mixing together of ideas and features that can only happen on top of a platform (the CLR) that provides a simple, open, flexible DNA for programming languages). "Miscegenation" is a term previously applied by racists to the "horror" of inter-racial mixing. I use it advisedly in the context of programming languages, which are often approached with equally-strong biases favoring language purity, which I believe to be equally wrong.
The next step after mixing & matching features, I think, is a wholesale re-engineering of programming languages. If one can mix and match ideas and features freely within languages, then why not modularize these features? The history of programming languages has been the history of a succession of single, dominant, monolithic programming languages that each were the de facto standards of their day. A new language would bursting onto the scene with initial promise of advancing the state of the art, then become a drag on progress as the state of the art advanced beyond the current domiant language's central paradigm. A great example is C++, which became so dominant that the great ideas in other langauges -- such as Eiffel's use of contracts -- languished. A more modular approach to programming languages would facilitate the miscegenation of language features, allowing things like contracts to find their way into the mainstream much more efficiently.
Then, programmers would chose the best language to write each piece of a coding task, just as a carpenter uses a hammer for one task and a saw for another.
This modular approach to language functionality would (a) allow the more-rapid evolution of programming language functionality, and (b) be available first, best, and perhaps only on Windows, because no other platform has the necessary infrastructure (and presumably Microsoft has patented the holy shit out of the CLR and VS.NET).
If, at the same time, Microsoft were to aggressively support the use of VS.NET as a cross-platform development tool, implementing redistributable .NET equivalents ("the .NET Platform") on other operating systems, then this would de-commoditize programming, establishing Windows as the most efficient platform for developing applications for the .NET Platform (and thereby all other OS'), thereby ensuring that the best applications were developed first, best, and perhaps only for Windows. This could make it possible for Microsoft to regain the Cool Factor Cup than Linux et al. have recently captured.
Of course, this de-commoditization only happens if VS.NET, the CLR, and the novel re-engineering of programming languages allows such a big jump in programmer efficiency that programers who don't use it are outcompeted in the marketplace. That's what de-commoditization MEANS.
My two cents of free advice. :-)
James Plamondon
Microsoft, 1992-2000
now CEO, Thumtronics Inc
The New Shape of Music(tm)
www.thummer.com
Austin, TX
Soma announced some exciting news this morning. Developer Division--the people at Microsoft who make
Soma - Does this mean we will see F# ship with Visual Studio 2008 or Visual Studio 2008+1?
Thanks - Jordan