In what areas might the use of F# be more appropriate than C#?

Over the last few years F# has evolved into one of Microsoft's fully supported languages employing many ideas incubated in OCaml, ML and Haskell.

Over the last several years C# has extended its general purpose features by introducing more and more functional language features: LINQ (list comprehension), Lambdas, Closures, Anonymous Delegates and more...

Given C#'s adoption of these functional features and F#'s taxonomy as an impure functional language (it allows YOU to access framework libraries or change shared state when a function is called if you want to) there is a strong similarity between the two languages although each has its own polar opposite primary emphasis.

I'm interested in any successful models employing these two languages in your production polyglot programs and also the areas within production software (web apps, client apps, server apps) you have written in F# in the past year or so that you would previously have written in C#.

Not personal experience, but you can listen to an episode of DNR (I think it's [this one][1]) where they talk to Microsoft folk about F#. They wrote most of Xbox Live scoring system, which was far from trivial, using F#. The system scaled massively across hundreds of machines and they were very satisfied with it.


[1]:

[To see links please register here]

During my internship at Microsoft Research, I worked on some parts of Visual Studio IntelliSense for F# (which is itself written in F#). I already had some experience with IntelliSense from earlier C# projects, so I think I can compare the two.

* Visual Studio Extensibility is still based on COM, so you need to deal with objects that are not very nice .NET objects (and definitely not functional), but I don't feel there is any major difference between C# and F# (it works smoothly from F#)

* The data structures used to represent program code in F# are mostly _discriminated unions_ (which are not supported in C# in any reasonable way) and this makes a **huge** difference for this kind of application (where you need to process tree structures, such as program code). Discriminated unions and pattern matching allows you to structure the code better (keep related functionality in one place rather than having it all over the place in virtual methods)

Earlier, I also worked on CodeDOM provider for F# (also written in F#). I actually did first experiments in C#, but then converted the code to F#.

* CodeDOM provider needs to traverse some structure represented using .NET objects, so there isn't much space for inventing your own representations of data (which is the area where F# can offer nice benefits).

* However, there were many small F# features that made the task easier. Since you need to produce a string, I defined custom operators for building strings (using `StringBuilder`) and implemented the code using them and higher-order functions (e.g. to format list of objects separated using the specified string etc.), which removed a lot of repetition (and tedious `foreach` loops).

These are two relatively specific examples, but both of them are related to working with representations of programs, or expressions, or more generally, complex tree-like data structures. I think that in this area, F# is definitely a good choice (regardless of the functional features in C#).

A lot of the unit tests for the F# Visual Studio components are written in F#. They run outside VS, mocking the various Visual Studio bits. The ability to cons up anonymous objects that implement interfaces is useful in place of a mocking framework/tool. I can just write

let owpe : string list ref = ref []
let vsOutputWindowPane =
{ new IVsOutputWindowPane with
member this.Activate () = err(__LINE__)
member this.Clear () = owpe := []; 0
member this.FlushToTaskList () = VSConstants.S_OK
member this.GetName(pbstrPaneName) = err(__LINE__)
member this.Hide () = err(__LINE__)
member this.OutputString(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
member this.OutputStringThreadSafe(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
member this.OutputTaskItemString(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText) = err(__LINE__)
member this.OutputTaskItemStringEx(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText, pszLookupKwd) = err(__LINE__)
member this.SetName(pszPaneName) = err(__LINE__)
}
DoSomethingThatNeedsA(vsOutputWindowPane)
assert( !owpe = expectedOutputStringList )

when I need an instance of e.g. an `IVsOutputWindowPane` to pass to some other component that will eventually be calling `OutputString` and `Clear`, and then inspect the `string list ref` object at the end of the test to see if the expected output was written.

I don't know if it's in production, but the AI for "The Path of Go" was written in F#:

[To see links please register here]

> The Path of Go: A Microsoft Research
> Game for Xbox 360
>
> This demo showcases an Xbox 360 game,
> based on the game of Go, produced
> in-house at Microsoft Research
> Cambridge. Go is one of the most
> famous board games in East Asia, it
> originated in China 4000 years ago.
> Behind the deceptive simplicity of the
> game hides great complexity. It only
> takes minutes to learn, but it takes a
> lifetime to master. Although computers
> have surpassed human skills at Chess,
> implementing a competitive AI for Go
> remains a research challenge. The game
> is powered by three technologies
> developed at Microsoft Research
> Cambridge: an AI capable of playing
> Go, the F# language, and TrueSkill™ to
> match online players. The AI is
> implemented in F# and meets the
> challenge of running efficiently in
> the .net compact framework on Xbox
> 360. This game places you in a number of visually stunning 3D scenes. It was
> fully developed in managed code using
> the XNA environment.

(Someone else mentioned "TrueSkill" already.)

Over the last 6 or so months, I've been working on a Vim emulation layer for Visual Studio 2010. It's a free product with all of the source it's freely available on github

- GitHub: [

[To see links please register here]

][1]
- VsVim on [Visual Studio Gallery][2]

The project is divide into 3 DLL's representing a distinct layer. Each layer has a corresponding unit test dll.

1. Vim Engine: F#
2. WPF layer for adornments and editor integration: C#
3. Visual Studio Integration layer: C#

This is the first major project I've ever done with F# and I have to say I love the language. In many ways I used this project as a method of learning F# (and this learning curve is very much evident if you look through the history of the project).

What I find the most amazing about F# is just how concise of a language it is. The Vim engine comprises the bulk of the logic yet it only comprises 30% of the overall code base.




[1]:

[To see links please register here]

[2]:

[To see links please register here]