12 years back, when I started my formal classes in computer science, the first thing I learnt was “data” means “information”. A few days after that, we started conventional programming, where code and data were treated separately. For example, only data can be passed as the functional arguments. It was difficult for me to digest that “code, which is also information, is not treated as data”. I strongly felt that this will increase complexity of softwares in the long run.
A system does three things – read, transform (processing data), write. In other words – the mathematics (the transform part), and the effect of that in real life (the read/write part). The data transformation is indeed a mathematical concept, and with the help of read and write we make the mathematics (the transform part) useful to the real world. Bringing the “transform” part fully inside mathematical domain has its own benefit of using mathematics without fear (possible errors) for the analysis of the system, making the system more tractable mathematically. The catch is to treat both the elements of transformations, data and functions, equally.
Initially, code used to be bigger than the data, so sending data over the wire was feasible. But with time, data becoming huge, sending code to systems over the wire becomes the need, resting the data on the systems intact. With big data, the need of the hour is to treat the code as data, so that the code can be taken as argument to another meta function on a system having huge data which expects an algorithm for transformations.
Roughly speaking, codes are algorithms, algorithms are mathematical functions, functions are in turn actually look-up tables, i.e. data. Hence with this principle, all codes or functions are data.This is exactly the cornerstone of the functional paradigm. The functional programming is programming with functions, they treat functions and data likewise. Another principle I love, to control complexity, rules should not be complex itself.
Thumb rules rewritten for the functional paradigm:
Read-write and transformations(algorithms) should be separate.
Use immutable variables. Discourage use of reassignment statements.
Discourage side-effects (input/output or changing any variable in-place), every function should ONLY return its expected result.
Use referentially transparent functions (sometimes it is called pure functions) with no side effects, i.e. if x = y, f(x) and f(y) should be same forever.
Unit testing is a must for each function.
One of the main design patterns should be followed is to use expressions instead of instructions, i.e. it should be declarative in nature. Discourage use of loops like for/while – use recursive statements as shown above to calculate sum. Tell computers what needs to be done, not how to do it – it reduces error, especially edge cases.
With the need to control the complexity of the system and the advance design, the design pattern for the functional composition can be made to follow some basic algebraic structures, which in turn becomes more robust.
