There is a lot of hype around the latest functional programming language F# from Microsoft. In real life - where (in what kind of scenarios) can F# most likely save time and money?
F# is especially useful for financial and scientific applications where its syntax is well suited to symbolic analysis and enables you to write applications to get stuff done quicker than other languages can. Since time = money it helps save both :-)
There is no reason to use F# aside from personal reasons. There may come a day where it becomes a preferred financial language, but it doesn't do anything you can't do in C# (albeit maybe with more lines of code in C#).
F#, like all functional languages, are especially good at stateless programming, since you are typically working with immutable data, its especially difficult to use functional programming in a heavy IO application.
Well you could argue that there's no reason to use C# or VB.net aside from 'personal reasons', they don't do anything you can't do in F#. In fact I could go further and say why not just program in CIL? That is just as capable a language!!
So other factors matter - i.e. how long it takes to write a program, available tools for that language, community support for the language, etc. - F# can help you write certain classes of program more efficiently with less lines of code, so it can be of very real benefit for a company, for example if it took 10 times less time to write a program in F# compared to C# that would be more than a 'personal reason' to use it.
The most well know uses of F# are in finance right now. But it will prove its worth in any application where you need to be able to express complicated math or algorithms easilly. 3d rendering or simulation would be suitable too. You can express concepts like sets or tuples very elegantly in F#.
The argument that anything that can be done in F# can be done in C# is of course true but completely useless. Anything that you can do in C# can be done in machine language. But there are more compelling reasons for higher level languages than the posibilities of the language alone.
@Jonathan Holland: F# is in no way "stateless." Like all languages in the ML family, it has mutable references. I think you have it mixed up with Haskell.
Asynchrous workflows in F# appear to provide a pretty simple and powerful way to correctly use completion ports and interact with the thread pool.
re @Jonathan Holland:
"its especially difficult to use functional programming in a heavy IO application."
and Chris Conway:
@Jonathan Holland: F# is in no way "stateless." Like all languages in the ML family, it has mutable references. I think you have it mixed up with Haskell.
Just backing up what Chris has said. Jonathan misunderstands F# and does it an ignorant disservice here.
His comments probably reflect an opinion about a 'pure' functional programming language (such as Haskell) but they're completely out of place with regards to F#.
Simon Peyton Jones actually has a very good explanation of functional programming in this podcast: http://www.se-radio.net/podcast/2008-08/episode-108-simon-peyton-jones-functional-programming-and-haskell
One of the things he stated that hit home with me was testability, since you have controlled side effects it is a lot easier to test. Hurry up and listen to the podcast :-)
It is often easy to replace code in OO style by code in a FP style that is much simpler and provides the same functionality. In this blog post (Dimensional units and programmers' productivity) I give such an example. (Pardon the self-advertising)
You should check out the new Units of Measure feature in the CTP. This in itself is a killer feature for any code which relates to the physical world. And no you CAN'T do it in C#.
Briefly, it allows you to define units of measure, and then use these as type qualifiers on floats (and decimals, I believe):
So, for example:
[<Measure>] type kg //define a unit of measure
let myMass = 80.0<kg> //define a mass in kg
[<Measure>] type m //define a unit of measure
[<Measure>] type s //define a unit of measure
let g = 9.8<m/s^2> //define gravitational acceleration (with units)
let myWeight = myMass * g // result is 784.0<kg m/s ^ 2>
//ERROR: The unit of measure 'm' does not match the unit of measure 'kg m/s ^ 2'
let stupidError = myWeight + myMass
The beauty of this is that it is 100% design-time. The compiler checks for you, but the code is compiled back down to normal floats.
I think that an important point in this kind of comparison is not only "what can I solve", but also "how can I express it".
Rather than studying a formula to figure out an algorithm for it, F# allows you to express it in a format and discipline, which is much closer to the way in which they are commonly expressed by the resource material.
Especially in focused class libraries, I see many uses for F#.
The Halo 3 guys use F# for their TrueSkill Matchmaking system, as outlined in DotNetRocks #293. Basically functional programming seems to be good for everything involving complex math.
We have had great success using F# in industry for everything from web analytics to scientific computing and visualization. F# really pays dividends when your code is dealing with complicated data structures and algorithms. Most notably, manipulating trees and tree-based data structures is a breeze with F# thanks to pattern matching over variant types and active patterns.
It looks like F# will be useful as a script replacement eg
- Where you would use perl , batch files , python etc eg
- Mathematical or AI scripts etc
- Screen / Web scraping
- Project control ( daily builds etc)
Though this is extended to quick and dirty data forms . This is something C# lacks , you cant write a script in C# in the same time as you can Python or Perl.
Libs and frameworks are better written in C#. Utilities and frequently changin scrips are better written in F#.