When does it make sense to use F# over C# or VB.NET?

Question

Does anyone have any practical examples where F# would be a better choice than C# or VB.NET? Please can you demonstrate using source code?

Answer 1

Async computations and math are easier in F# but I wouldn't choose it to implement a complex UI.

Answer 2

Your question could be answered more broadly, since you're really asking when you should use a functional programming language versus a procedural language.

---

Functional languages (F#) are well suited for applications that need to run in parallel. Logic that is mathematically intensive are good fits. Also, any type of logic that involves matching and/or transforming data/patterns. Good examples of functional languages other than F# that you might be familiar with are SQL and XSL. These types of languages rely on stateless set operations over explicit procedure calls.

In metaphorical terms, the type of real world activity that resembles functional programming is working on a factory floor. While each station (function) has a sequential set of steps (procedures), the station itself must be unchanged by an item as it passes through. Also, an item cannot be operated on unless it matches the type of object that the station is designed for.

Note that the above metaphor isn't perfect, since the items will have their state changed by the station. It would be a better fit if the station received an item and then created a new item based on the original plus any work it did. Additionally, the items wouldn't travel on a linear assembly line, but would instead be constantly "matched" to a station after each previous station completes its work. Unfortunately, I can't think of a perfect real world metaphor, but with these modifications, you can imagine how it might look.

---

Procedural languages (C# and VB) are better for the type of logic that tends to be more workflow oriented, where multiple sequential steps are required to execute a workflow. If your logic requires building state from a single or multiple method calls, procedural languages are a more natural fit.

A methaphorical example of procedural programming is getting ready for work. From the moment you wake up until you get in your car, you are executing steps that contribute toward your end state. What you do may branch (and this is the key difference that I'll explain below) depending on conditions, for example if you run out of toothpaste, you open a new box).

---

The key difference is that functional programming limits procedural code to that which does not cause side-effects (state change). Instead, it relies on matching patterns to handle variations. Procedural programming, on the other hand, relies on branching and looping structures to manage variations.

Answer 3

F# is much closer to a pure functional language. It has constructs and features geared towards maximizing your productivity and capability when using a functional programming style. This include features like:

• enforced immutability of values
• pattern matching for function invocation
• concise syntax focusing on transformative operations
• structural concepts like tuples and mappings
• list and set manipulation syntax

Answer 4

Type inference does not suck. When you use lots of generics, the C# method signature is sometimes bigger than the method itself:

public static IEnumerable<U> Map<T,U>(Func<T,U> f, IEnumerable<T> e)
{
    foreach (var x in e)
    {
        yield return f(x);
    }
}

In F# it's just

let Map f e =
    seq {
        for x in e do
            yield f x 
    }

and I can see the inferred type by hovering my mouse over 'Map':

Map : ('a -> 'b) -> seq<'a> -> seq<'b>

This is a trivial example, but it shows off one thing I like about F#. In C# you're unlikely to write 'highly generic' code because you get swamped under by type annotations.

Answer 5

You might check out

How does functional programming affect the structure of your code?

which talks a little about how e.g. algebraic data types and pattern matching often mean you don't need the cumbersome Visitor design pattern for processing tree-structured data, (indeed many OO design patterns 'disappear' when functional programming is brought to bear).

One shorter code example (called out in the article above) is

http://weblogs.asp.net/esanchez/archive/2008/09/18/point-distance-imperative-vs-functional-style.aspx

which shows how a functional style contributes to succinctness (and often collaterally, correctness).

Answer 6

If you want to author an embedded DSL, you'll find F# superior to C# or VB for a number of reasons, including both language syntax (e.g. curried functions, function application through mere juxtaposition (no parens necessary), top-level naming/programming/scripting) and homoiconicity (through F# reflection).

Answer 7

If you're fond of scripting and you want to program interactively through a REPL, you can do that today using F# inside Visual Studio (but cannot with C# or VB in VS).

Answer 8

Split your project into several assemblies and try to write one or more of them with F#.

I started one project that consists of client and server component. Client application is WPF written in C#. Server component is divided into multiple assemblies. Two of them are F#, rest are C#.

Functionality in those two F# assemblies is divided like this:

1. message parsing and number crunching library
2. async tasks (reading data from multiple sources - http, ftp)

Some interesting resources to check:

1. Microsoft F# Developer Center
2. F# presentation by Luca Bolognese. It is really good and worth watching.
3. StackOverflow question: Learning F#