A few weeks ago I was able to attend the “Haskell eXchange” conference in London. In this post, I’d like to introduce readers to functional programming and briefly highlight the advantages and techniques of functional programming which I learned from a talk by Don Stewart, the author of the book “Real World Haskell”. Then I’ll share some thoughts about how companies might start to integrate functional programming into their tech stack.

## Introduction to functional programming

What is functional programming?
A style of building programs using mathematical functions.

What is mathematical function?
A relation exists between a set of inputs and a set of outputs; each with the property that each input is related to exactly one output.

Let me give an example:

``````var x = 1;

function impure(y) {
x = x + y;
return x;
}

function pure(x) {
return x + 1;
}

console.log(impure(3)); // 4
console.log(impure(3)); // 7

console.log(pure(3)); // 4
console.log(pure(3)); // 4``````

Impure functions return different result for the same input (number `3`). In other words − impure functions have side-effects.

Because you lose modularity and it is harder to think about functions with side-effects.

On the other hand, it’s really easy to compose pure functions:

``````function compose(f,g) {
return function(x) {
return f(g(x));
}
}

function plusOne(x) {
return x + 1;
}

var plusTwo = compose(plusOne, plusOne);
var plusThree = compose(plusTwo, plusOne);

console.log(plusOne(1)); // 2
console.log(plusTwo(1)); // 3
console.log(plusThree(1)); // 4``````

It’s like lego games; by having a set of pure functions you can easily build your own galaxy.

Why aren’t pure functions used all the time?
Pure functions are awesome but the real life programs have a bunch of side-effects. Getting a response from the server, reading from the file, printing to the screen − all these operations have side-effects. You can’t build a truly useful program just on top of pure functions − you need functions with side-effects as well.

## Don Stewart’s talk

Haskell has a smart way to distinguish between pure and impure functions. It is common in the Haskell community to write function types for the functions.

``````makeApple :: Seed → IO Apple
makeJuice :: Apple → Juice``````

If you see `IO` (it’s a Monad) somewhere in type signature, it means the function is impure.
As well, Haskell has strong static typing. Before running a program, compiler should correctly type check a program (and compiler can catch a dozens of errors!).
Now, let me highlight some parts from Don Stewart’s talk. Don Stewart leads the Haskell teams in the financial sector. In his talk, he shared how to control complexity of applications with more than 3 million lines of code.

Here are a few tips from him:

• Types help to control complexity.

• Compare 2 pricing functions:

``````f :: Double → Double → String → Double
g :: Rate Libor → Spot SGD → Date → Rate SIBOR``````

`g` has more expressive types. In other words, you can say more about the function by looking in function type assuming you know financial domain.

• Remove unclear types.

• No side effects. Instead, try to write pure functions as many as possible.

• Make things simpler by controlling `IO` and new types.

• Types are for keeping code maintainable and self-documented.

• Use “new types” and “data” to distinguish unique entities in the system.

• Using Phantom types, you can tag the things. Make it impossible to mix up or combine values in nonsense ways.

• As opposed to `Stings` and `Double` types have too many valid values for most use cases, `Bool` often has too little information.
Instead of `authenticate :: String -> String -> Bool`
write `authenticate :: Privileges p => User -> Password -> IO (AuthUser p)`

• Lift errors into types (using `Maybe` and `Either`) for  making functions modular.

• Move partial functions to the edges and write total functions as a core of program.

• Types − in order to minimize complexity; it helps to deliver faster. Reuse is extremely cheap.

Of course, for the reader unfamiliar with Haskell, these tips don’t tell much, but let me repeat once more. Basically, the main idea is that you need to use meaningful types as much as possible. In such a way you give a compiler more information about a program and consequently, the compiler helps to catch a lot of errors and hopefully optimize the code. Other simple ideas are to use total functions, move side-effects to the edges of a program. That’s it!