The most artistic way of programming

When formal classes in computer science were started, the first thing taught 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 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 the complexity of software in the long run.

A system does three things - read, transform (processing data), write. In other words - 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 reading and writing, we make mathematics (the transform part) useful to the real world. Bringing the "transform" part fully inside the 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, the 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 an 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, to control complexity, rules should not be complex itself.

Thumb rules were rewritten for the functional paradigm:

Read-write and transformations(algorithms) should be separate.
Use immutable variables. Discourage the 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 that 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 the 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.

Source: HOB

Share This On

Previous Story Next Story

Latest News Feed