Following on from the Intro into Functional programming for the OO developer. Time to dive in...

Immutability

Before we start on this journey I must quickly touch on immutability. To say it is a cornerstone of functional programming is an understatement, if used throughout your code you will find whole classes of bugs fall away and as an added bonus you get fearless lock-less multi threading for free.

In functional languages immutability goes as deep as the following:

let x = 1
x = x + 1      ERROR cant change x

In C# this would be defining all variables as const:

const int x = 1;

That is all I want to say on immutability for now, we will revisit it later in more detail. I wanted to raise it at the very start such that you are mindful of it as you read through the series.

When used correctly in a language that supports it well immutability is so subtle that you forget that nothing is changing, you see the movement and transformations of data more clearly as the code focus is on what and not how.

Its all in the Types

I also want to give a quick overview on types in an equally abstract way to immutability so we have all the building blocks to really start from.

In functional programming all types are immutable, be they simple value types or compositions such as Tuples, Unions and Records

The standard types are easy enough: int, string etc.

For many OO programmers Tuples might be new, although C# has had them for years in various forms. The following is the older style C# Tuple and the form most common in OO languages.

var tuple = Tuple.Create(1, "Timmy");
var id = tuple.Item1; // = 1
var name = tuple.Item2; // = Timmy

// They can store more than 2 items
var anotherTuple = Tuple.Create(1, "Timmy", "Jones");

In most functional languages they require far less noisy syntax to create or use. F# syntax is as follows:

let tuple = (1, "Timmy")
let id = fst tuple
let name = snd tuple
let anotherTuple = (1, "Timmy", "Jones")

Discriminated Unions are where the fun begins though. These are like Enums on steroids where each value in the Enum can have different data associated with it. Here is a C# Enum with made up syntax to get the point across.

public enum LightbulbState
{
    Off,
    On,
    Dimmed(int percentage),
    WiFi(IP address, int percentage) 
}

The other way of looking at these with OO bias glasses is an inheritance tree with LightBulbState a pure abstract base with no functionality or values. The Enum values inherit from that and add custom properties.

Pattern matching is the powerful technique used to work with Union types that we will visit later on.

Record types can be thought of as immutable structs, in that they have a number of named fields but unlike structs they do not have instance methods. A good way to think of Record types is LINQ abstract types, such as the example below:

var typeInstance = 
    new 
    {
        Id = 10, 
        Name = "Woz, 
        Profession = "Code monkey"
    };

And now to introduce one final type, not even mentioned so far. It is the Functional Programming replacement for interfaces and any GOF pattern you an think of and is both flexible and composable..... Functions.

In the next part it is time to get less abstract and dive into functions. The first step will be to break your notion of functions and apply a load of rules which at first glance will make functions less useful. We will then explore how these rules provide a framework that will allow you to think and use functions in ways you might not have thought about before.

As always, happy to hear feedback on the series. Is it too slow, fast, abstract etc.

Part 2 is now ready :)