# The building blocks of FP: pure functions, immutability, and Referential transparency -Part 1-

Wikipedia gives the following definition of Functional programming
“In computer sciencefunctional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data”.
We can extract 2 main concepts from this definition
1- Mathematical functions are the way to do computation (they are first class citizens)
2- Don’t use mutable states
Now coming from the OOP world (.Net) i tend to agree on the first part (although the mathematical part is tricky), and mutable state is at a best a bother and a waste of time .

Pure Functions
Now the definitions of FP cites Mathematical Functions, we can describe it as follows: for the same input you will always get the same output, nothings out of the ordinary right! well hold your horses, lets see an example of a function in the imperative way:

```var acc = 0
acc = acc + 1
acc
}
```

Running giveMeNumber() twice will return 2 different results, the culprit is the acc, the function is using a variable that exists outside of its scope, an external input that the function doesn’t know about .
It’ called a Side cause.
Now imagine if acc was an immutable variable each time we call the giveMeNumber() it will create it’s own copy of it, thus returning the same result, this is where immutability can help us satisfy the mathematical definition.

The same case can be made if our function was making an external call as we can see in the below code

```var acc = 0