F# is the only language to be added to Visual Studio for a very long time. What makes it so special?

There is a growing trend to include elements of functional programming in “mainstream” languages such as C#. If functional programming is so good this raises the question of why we don’t just move to a functional language.

After all, there is an ideal candidate, F# which is a true .NET based language.

So, is F# very different?

Let’s find out.

What is functional programming?

It’s almost too easy to say that functional programming is all about using functions but there are many ways of doing this.

Functional programming attempts to make programming more like mathematics by making programming functions more like mathematical functions.

In maths a function is a set of rules that given an input set of values produces a single result – the value of the function. This initially sounds very much like the sort of function we use in programming, but there are some important differences.

For example a mathematical function doesn’t change any of its input values and certainly doesn’t change any value that isn’t part of the function.

This is usually expressed by stating that  mathematical functions don’t have side effects whereas programming functions often do. A typical programmed function might well change its input parameters and pass them back as secondary results and often changes variables, for example within the user interface, that are not really part of the function. In fact for many functions the side effects are what are important.

The key ideas in functional programming are “no side effects” and “immutability” – although many a keen functional programmer would be horrified by this oversimplification.

Immutability relates to the idea that once a function has been evaluated it shouldn’t change its value – mathematical functions don’t.

In many ways it is the requirement for immutability that is usually the most difficult to swallow by an experienced procedural programmer.

Consider the familiar statement:

 x=x+1;

which means take the current value stored in x, add one to it and store the result back in x. In functional programming you really should consider x to be a function and the value stored in it is the value of the function x. Hence by the requirement for immutability its value can’t change and so any instruction like x=x+1 is complete nonsense.

It is like writing:

 Sin(1.4)=Sin(1.4)+1

which is even more clearly nonsense.

The reason why this is so difficult for a traditional programmer to accept is that x=x+1 is the point where programming really diverges from mathematics. From the viewpoint most of us are familiar with, programming is about describing “procedure”, i.e. what happens, and it is perfectly normal to take the value stored in x, add one to it and store it back in x.

Most of what we have achieved has been via procedural programming even if we have been using functions. Functional programming is about non-procedural programming. It’s about static relationships and things that change as little as possible. If this sounds a little unpromising remember that a function can still be “active” in the sense that it “works out a result” – but with no side effects and once the result is derived it doesn’t change.

You might very well at this point be doubting that functional programming can work – how can it possibly banish procedure from programming?

I have to admit that in practice functional languages have to let a bit of “procedure” sneak in. Just as procedural languages such as C# have elements of functional programming, so function languages such as F# have elements of procedural programming.

What is important is to minimise their use and be aware of what you are doing. Many F# functions are used just for their side effects – usually called “imperative” programming. In practice working with F# is a mix of functional and imperative programming.

You might also find some of the mechanisms that functional programming languages “invent” contrived, and as much a transgression of the basic principles as a dropping back to procedural semantics, but it’s all an effort to keep the purity of the approach.

Added to this is the fact that F# is overtly a “mixed mode” language, attempting to fuse functional programming with other approaches. In this article the focus is on the functional as this is the least well-known of the approaches but lookout for others!

To understand the advantages on offer, you have to ask the question what exactly is wrong with a procedural approach that a functional approach fixes?

The simple answer is that if you don’t specify a procedure then the machine is free to decide exactly how to implement your code. In theory, functional programming makes threading, and parallelism in general, very easy and fairly safe.

A functional program is also supposed to be easier to prove correct, debug, and so on, than a procedural program and all of this is true – but this doesn’t mean that it is impossible to write a bad functional program.

<ASIN:1430224312>

<ASIN:0596153643>