Table of contents:

[TOC]
Functional Programming
===================
Why are we so fussed about Functional Programming? Is it really better than Object Oriented programming? Can it solve our problems?

If you are like me you'll have heard a lot of buzz about functional programming these last few years you might be wondering how this "functional programming" fits into your day to day work and how it affects your code.

The answer is quite simple, yes, functional programming will make you a better programmer. Yes, functional programming will solve a lot of problems arising from complexity; but most of all functional programming is the only way to leverage the power of multi-core chip-sets.

----------

## What is Functional Programming (FP)
There are a lot of definitions about FP buzzing around the internet. Some definitions are more chaotic than others and some definitions are bias. For example, Uncle Bob would have everyone believe that functional programming is about state and that Object Oriented Programming (OOP) can be stateless and thus have the same power as FP. FP is not about state, state is an effect of writing mathematical functions. Working with mathematical functions is at the center of FP. What does that mean? Mathematics is not a part of my day job right?

Wrong, everything about software and hardware is bound to mathematics, just like everything else is. Bridges suspend because of math savvy engineers; even colors are calculated using mathematical equations to make them aesthetically appealing. So, to write a blog post about programming without any math would be to deny it's importance and I would not deprive people of that. Now to nuance this, you do not need a maths degree but you need to know what it is about. You need to be able to read their *syntax* and you need to be able to follow *logical proofs*. To be honest, you should already be able to do that as a professional programmer, *logical proofs* are what code is all about and lets not get started about syntax. What I want to achieve with this blog series is to awaken a curiosity and raise the level of awareness about the power of programming, in my opinion this can only be done through functional programming!

So, to reiterate, functional programming is about writing code using mathematical functions. Math is a part of programming which we as a profession have denied for too long and you need to have a firm grasp of the *syntax* and how to form *logical proofs*.

## What is this function thou speaketh of?
In OOP we confuse static methods for mathematical functions. A static method in most languages is the same as method with a **this** parameter as first parameter. So imagine the following method:

```
public class Person {
	private string name = "Peter Pan";
	public string GetName() {
	    return this.name;
	}
}

// call
var person = new Person();
Console.WriteLine(person.GetName());
```
We could rewrite this function as:
```
public class Methods {
	public static string sGetName(Person this) {
		return this.name;
	}
}

// call
var person = new Person();
Console.WriteLine(
	Methods.sGetName(person));
```
Here we can see that the *insides* of the methods `GetName` and `sGetName` haven't changed we have just created a parameter *this* which contains the data.

> **Note:**
> Maybe we shouldn't call the parameter *this*. *this* just doesn't say anything. *data* would be better. Within the class the *this* might be better served by calling it *self*.

Pure mathematical functions are different, first let's look at the same functionality but now written in F#:

```
type Person = { name : string }
let getName data = data.name

let person = { name = "Peter Pan" }
printf "%s" (getName person)
```

A few things should stand out:
  * There is no class keyword.
  * The type definition, the data and the behavior are separated.
  *  There are no access modifiers.

Before we get into why these differences are there we will need to look at what it is what pure mathematical functions want to achieve. Let's start by looking at what an operator is:

> An **operator** is a symbol or function denoting an operation.

This is the mathematical description of what an operator is. So we can have a symbol or a function, this is odd. In general programming symbols tend to be thought of as different *things* than functions; but in mathematics we can think of both of these things as *morphisms*.

> A **morphism** is a structure preserving map from one mathematical structure to another.

Ah, now we're getting somewhere, *maps*, I can deal with maps! In C# we can use the `Select` function in `Linq` to achieve a map:

```
// people is of type IEnumerable<string>
var people = ["Bianca", "Trish", "Paula", "Michelle"];

// nameLengths is of type IEnumerable<int>
var nameLengths = people.Select(p => p.Length);
```

Somehow this magic select function has turned an `IEnumerable<string>` to an `IEnumerable<int>`. Does this comply with the definition of a *morphism* I just gave? Well, that depends on what a *mathematical structure* is. So let's dive into mathematical structures.

> A **mathematical structure** is a *structure on a set* which describes a relationship between objects in that set.

Another way of thinking about a structure is that a structure gives a subset of the set meaning. This comes really close to how we as programmers think about types! There can be multiple objects which fall into a type definition. For example, `1 2 3 4 5 6 7` are all of type `Integer`. So for the sake of this article I will treat *mathematical structures* as types. And while we're at it; I'll treat the programming language as a *container* of all of these types. This container in mathematics could be called a **category**.

So, we now have a *programming language* which has *objects* of a *type* and which has *morphisms* over these objects. One thing to note is that these morphisms can be completely random, there is no reason why there should be a pure mapping between two mathematical structures. This might be the most fundamental difference between **Category Theory** and **Algebra**. In Category Theory you have Objects and Morphisms of a Category. In Algebra you always define the context, on which you define your Algebraic types.

Now, let's think about these morphisms for a little bit, I could write something like: `f:: x -> y` where `y` can also be written as `f(x)` so you get `f(x) = y` which might seem more familiar to some. Now `f(x)` in functional programming languages is usually written as `f x` which gives the idea of multiplication and because of this *association with multiplication* is exactly why it is written that way.

##Monoids
Let us think about the positive whole numbers:

$\mathbb{N} = { 1, 2, 3, 4, 5, .. }$

Now imagine an operation $\oplus{}$ which can be applied to two of these elements from the collection $\mathbb{N}$. We can now define $\oplus{}$ as:

$$
Given\;a,b,c,id\; where\; a,b,c,id\;\in\;\mathbb{N}\\
\\There\;exits\;an\;operation\;\oplus\;so\;that:
\\(\;a\;\oplus\;b\;)\;\oplus\;c\;=\;a\;\oplus\;(\;b\;\oplus\;c\;)\quad and\;that:
\\a\;\oplus\;id\;=\;a\quad and \quad id\oplus\;a\;=\;a
$$

We can now say that $\mathbb{N}$ is a **monoid** under operation $\oplus$.

What could be a valid operation for $\oplus$? Well, multiplication seems reasonable. Multiplication is associative (the first rule of a monoid) and $1$ seems to satisfy the $identity$ rule. So the natural numbers ($\mathbb{N}$) is a $monoid$ under multiplication.

Why is this important? This is important because instead of the $\mathbb{N}$ we can look at the objects of a type, for example the type $'a$ and as the operation $\oplus$ we can think of $function \; composition$.

Imagine the following functions:

$$
f\;::\;'a\rightarrow\;'a\\
g\;::\;'a\rightarrow\;'a\\
h\;::\;'a\rightarrow\;'a
$$

Now we can say that the $'a$ is a $monoid$ under $function \; composition$ because we can say something like:

$$
f  \oplus  ( \; g \oplus h \; ) \; = \; (\;  f  \oplus g \; ) \oplus h
$$

I am not giving any proofs, they would not give any extra information and would cloud the explanation. If you really want to have proofs, I applaud you and I'm sure you will find that the internet is littered with proofs about function composition being associative.

##Back to reality
So, now that we've seen that function composition on a generic type $'a$ is a *monoid* we might start to wonder how this affects our daily job. I'll bet you that you've never written a web site with a database backend and thought about *monoids*. Now, you might be right. There seems to be really little use you can get out of these mathematical definitions; but you couldn't be further from the truth. We can now say with absolute certainty that if for example $'a$ is for example the type $Person$ and we have three functions:

$$
create\;::\;Person\rightarrow\;Person\\
save\;::\;Person\rightarrow\;Person\\
log\;::\;Person\rightarrow\;Person
$$

That:
$$
create \; ( \; save \; ( \; log \; ( \; new \; Person \; () \; ) \; ) \; ) ;
$$

Can never, ever fall out of the type definition. This knowledge, this security is huge! But, and this is a big *but*, this presumes that the programming you do is using *pure mathematical functions*. If you use for example *C#* you can always `thow new Exception("Oh nooes!");` and circumvent the type safety of our *monoid*.  Also, `out` parameters mess up our system as well. *Exceptions* and *out parameters* are added functionality. There was absolutely no reason to add these *features* to the language. Because of something like exceptions we will have to rewrite our simple function composition for a language like C#:

```
var person = new Person();
try {
	person = create(person);
} catch (Exception ex) {
	// do something...or not...
}

try {
	person = save(person);
} catch (Exception ex) {
	// do something...or not...
}

try {
	person = log(person);
} catch (Exception ex) {
	// do something...or not...
}
```

Apart from the incredulously long windedness of this code it is also too specific. I haven't even caught all the specific exceptions each function can throw. To be honest, this is just silly. There should be no reason why we would write code like that. Any other way of rewriting, for example one bit try an catch around the entire set of functions would be sillier because you lose specificity.

In F# we would simply write:

```
new Person() |> create |> save |> log
```

if we wanted to go all out we could compose the functions like so:

```
let useCase_01 = create >> save >> log
let p = useCase_01 (new Person())
```

We should start to feel excited right about now.