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

Answer 1

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: http://github.com/jaredpar/VsVim
• VsVim on Visual Studio Gallery

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.

Answer 2

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.

Answer 3

We wrote a custom rules engine language using the Lex-Yacc implementation in F#

EDIT to include comment reply

There was no lex/yacc implementation in C#. (as far as we were aware, and the F# one was)

It would have been possible, but a downright pain to build the parsing ourselves.

This topic shows some other suggestions, such as external libraries, but our lead architect is an old hand at functional languages, so the choice to use F# was a no-brainer.

Answer 4

I have written an application to balance the national power generation schedule for a portfolio of power stations to a trading position for an energy company. The client and server components were in C# but the calculation engine was written in F#.

The use of F# to address the complexity at the heart of this application clearly demonstrates a sweet spot for the language within enterprise software, namely algorithmically complex analysis of large data sets. My experience has been a very positive one. In particular:

Units of measure The industry I work in is littered with units. The equations I implemented (often of a geometric nature) dealt with units of time, power and energy. Having the type system verify the correctness of the units of the inputs and outputs of functions is a huge time saver, both in terms of testing and reading/understanding the code. It eradicates a whole class of errors that previous systems were prone to.

Exploratory programming Working with script files and the REPL (F# Interactive) allowed me to explore the solution space more effectively before committing to an implementation than the more traditional edit/compile/run/test loop. It is a very natural way for a programmer to build their understanding of the problem and the design tensions in play.

Unit testing Code written using non-side effecting functions and immutable data structures is a joy to test. There are no complex time-dependent interactions to screw things up or large sets of dependencies to be mocked.

Interoperation I defined the interface to the calculation engine in C# and implemented the calculation in F#. The calculation engine could then be injected into any C# module that needed to use it without any concerns at all about interoperability. Seamless. The C# programmer need never know.

Code reduction Much of the data fed into the calculation engine was in the form of vectors and matrices. Higher order functions eat these for breakfast with minimal fuss, minimal code. Beautiful.

Lack of bugs Functional programming can feel strange. I can be working on an algorithm, trying hard to get the code to pass the type checker but once the type checker is satisfied thats it, it works. Its almost binary, either it wont compile or its correct. Weird edge case errors are minimised, recursion and higher order functions remove a lot of book-keeping code that introduces edge case errors.

Parallelism The functional purity of the resulting implementation makes it ripe for exploiting the inherent parallelism in processing vectors of data. Maybe this is where I will go next now that .NET 4 is out.

Answer 5

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

http://research.microsoft.com/en-us/events/techvista2010/demolist.aspx#ThePathofGo

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.)

Answer 6

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#).