Wednesday, 22 November 2017

Programming Microservices - part 2

Ramayana, India’s aadi kavya or first (grand) poem, written in Sanskrit around 1000 – 500 BC; is a book of epic significance in the sub-continent. Although the story of Rama, the eponymous hero of this book is well known across India ever since; the book in any of the Dravidian languages – the language of the people in the South of India, was not available till the 12th century, almost 2000 years later. The book being available in the language of the common people had a lot of cultural and social significance. To quote Wikipedia, “Ramayana is not just a story: it presents the teachings of ancient Hindu sages in narrative allegory, interspersing philosophical and ethical elements”. Till that time, only the elite few belonging to the royalty or the upper castes could learn Sanskrit and understand the philosophy of this epic. Ramayana in local language democratized this knowledge.




Thunchath Ramanujan Ezhuthachan (popularly known by his surname) wrote Ramayana in the Malayalam language. He faced an interesting challenge when he started to write it. The Malayalam script at that time had only 30 characters and was not enough to represent words from Sanskrit, which has 52 characters. To solve this, he created a new script with 51 characters which is used even today as the modern Malayalam script. Using this new script, he could express the philosophy of the Sanskrit text clearly in Malayalam.

In my last blog about programming microservices, we discussed about three characteristics which developers find tough to get it always right. Functional Composition, where we compose higher level functions from first order functions, is one of them. Programmers are used to the more conventional way of composing structurally. Structural composition usually creates more dependencies, which don’t go very well with microservices.

Functional composition can be expressed better with a programming language which is not procedural/imperative. The most popular programming languages – C, C++ & Java are conventionally imperative. A functional programming language is very suitable, yet some may find its demanding paradigm shift a bit too much. A multi-paradigm language may be a better go-between option. 

There are some more features of some programming languages that the developer may use to express functionally. The function closure in javascript simplifies the data exchange between functions, as against the block closure found in most programming languages.
//records A, B & C available in this scope
function someFunction () {
               function innerFunction () {
               //access records A & B
               //update records A & B
               };
//access record C
//update record C
};

In the example given above, inner functions can access & modify data from the outer functions without explicitly passing them as parameters. In imperative languages, this is usually achieved by parameter passing, often creating the need for many data structures. Other conventional alternatives are using global or class variables.

Functional composition often requires the functions to be passed as parameters/objects to other functions. Most programming languages support this through various techniques like function pointers, call-backs, OOPS or dynamic types. Support for lambdas or anonymous functions (with a fair share of syntactic sugar) can be a big plus for expressing better in this case.

function sumOfPowers (a, b, fn)  {
return fn(a) + fn(b);
};
var sumOfSquares = sumOfPowers(x, y, x=>x*x);
var sumOfCubes = sumOfPowers(x, y, x=>x*x*x);

C, C++ (till version 10) and Java (till version 7) don’t support lambdas. Multi-paradigm languages like JavaScript, python and all functional programming languages support lambda.

While statically typed languages offer better type safety, dynamically typedlanguages can help us to express concisely. C, C++ & Java are statically typed and JavaScript & python are dynamically typed. Spartan programmers would appreciate this feature.

Languages allowing literal notations of their data structures allow better expressions. JSON is an example of how effective literal notations are.

Programmers may consider these features when choosing a programming language for functional composition. Those who don’t, may end up with an application composed structurally and with more dependencies than originally thought.

No comments:

Post a Comment