Functional Programming Rules

Mathematical functions are actually sets that are mapped to other sets.

We need to borrow some of the spirit of that into programming through a set of rules. People call functions that behave according these rules pure (then name is not perfect because it gives the idea that it is superior to others), but it is an engineering decision so no good or bad, only tradeoffs.

Rules

Look at input produce output

• Only look at input (parameters) and produce an output (return)
  • implies No changing anything, no side effects
    • ex:
      • no changing the 4rth element of your array
      • no deleting the file
      • no updating the database
  • So just look at the parameters and produce some output

No Side Effect

We make this so that our programs are easier to understand easier to write: That is the ONLY reason. It is not a good/bad duality, it is just done in the hope that it will make our program easier.

Will it actually be easier to understand

x = ['a', 'b', 'c', ]
y = f(x)
x = ? // is still the same!!! So good

Immutable

Once you create a hash or a map, you cannot change it. So instead of changing we as "give me a copy of yourself, except it is a little different.

Problem: we have too many copies now Solution: Persistent Data Structures

Persistent Data Structure

Persistent Data Structures are versions of the common data structures we know like: Arrays, Hashes, Lists, Trees, etc. They have two key characteristics:

1. Immutable
2. Very efficient at "copy on modification" without a lot of copying

The way it works is: it represents for example an array as a tree, where each node has 3 slots and these 3 slots point either to another pointer node or to the data itself. So whenever we want to modify an element, we just need to copy the 3 element data-node that contains the data we want to change and the pointer-node that points to it. But all the other nodes that are not changing are reused from the original. What if the underlying original changes? It NEVER changes, it is IMMUTABLE. Actually it is 32 and not 3 in reality.

Side effects

If we remove side effects, then we are out of job... All what customers pay us to program is to actually do some side effects. The bank does not care that the Accounting software is pure. It just cares that the database is updated, that the transactions are written etc. So it cares about the side effects.

What we need is a bridge from functional code to the real world of messy effects.

In closure they are called Atoms or Agents/Actors (using queues)