State of affairs and possibilities

Have you ever wondered why at all do we write code? To craft software or to solve a problem? Often in the urge to survive as developers, we miss reminding ourselves of this very question. The practical realities force us to look at the immediate next step. That being ship a release. Thus, we force ourselves into believing we write code to craft software. Just by itself, this state of mind is not a pressing problem for us to worry about. At least not yet. The floodgates of problems break open when we brand ourselves as Java developers, C# developers or Python developers. Such a branding of skill is not only limiting in nature but it often hinders our ability to solve a problem.

Poly-paradigm programming is the answer to keeping our eyes on the prize. This is not being polyglot; it is about choosing the right paradigm for the purpose. That is, it helps us stay focused on the solution and is not merely limited to crafting software.

Paradigms

The craft of creating software is centred on solving real-world problems. Often the first step in doing this is to model the real world. This leads to paradigms – Object-oriented, Pure functions, Aspect-oriented, and Procedural paradigms are few popular ones you must have practised. Many of the programming languages have been born out of these paradigms. C language was born out of procedural paradigms. C++ language was born out of object orientation. Java and C# address a few shortcomings that C++ had. Memory management was a burning issue stemming from C++ back then. Similarly, Clojure, Lisp, Erlang, or F# are all taking a stab at the functional paradigms.

The curtain raiser

Do you often see systems built using many different programming languages? We bet 100% of you must say Yes! Let me help in case you are confused. Any application web, mobile or console would typically have C# or Java for the binary but almost always packages configuration as XML, JSON, or YAML. Isn’t that itself a plurality of programming languages? Would you not call that being polyglot? We would for sure. Now don’t even think of starting an argument with us; saying XML or JSON are not a programming language. We will only concede to a statement that it is not generally perceived as a programming language. The sad and unfortunate truth!

If any of you are young developers starting your career and wondering why we were so guarded on that line, we will throw you folks a hint. When you write code in C# it is eventually read by a virtual machine known as CLR and carries out the tasks as instructed. With the XML file, the story is the same except that instead of a virtual machine it is read and understood by your application. However, the fad has it; C# is a programming language whereas XML is not.

The problem

For a hammerhead, every problem is a nail that must be hammered to solve. There are tools, other than hammers. But if we use all of them as a hammer, we miss the mark in solving the problem. In other words, if we model every real-world topic as an object, we miss the mark to solve the problem. We had in the past yielded to this notion and allowed to sprout polyglot programming. Take the C# code and XML we mentioned a while ago. But if you consider the fad that co-existence probably survived because XML or JSON was never considered as a programming language.

The solution

The solution is not elusive or difficult to find. The solution is to build a system or software with the best language that helps model the real world. This will lead to polyglot programming at a higher scale.

The perceived challenge in the past

What stops us from deploying this solution? It must be the customs or rituals; isn’t it? The custom of using one framework and programming language to offer a solution. There is some merit to that perception. Instead of getting carried away let us de-construct the logic in identifying the barriers.

Sending data over the network was costlier

We are not talking about the internet penetration in a populace. We are talking about the network bandwidth between data centres. This is relevant in a worst-case scenario when a component of the system is separated from another by a data centre. A decade ago, the P50 for internet bandwidth was about 20 Mbps. Now it is at 270 Mbps. Back then it was prudent to avoid putting any data on the network until absolutely required. But now one can afford to build what is called chatty components. Don’t get us wrong we are not encouraging to stuff the network with a lot of data. We are merely presenting the availability of a network to carry more data which when used responsibly could be the reference to a well-crafted system. Polyglot programming had this as a detractor to adoption for many years. Since Java code cannot access the value of a variable in PHP’s interpreter. For them to talk we needed to put the data in the network. 

In the present time with a 100x growth in the bandwidth a carefully selected architecture could balance between a chatty component and the component that contributes to a solution.

The way developers market their skills

A decade ago, you would not have come across the talent requirement of a full-stack developer. Developers too marketed themselves as Java developer or .NET developer. This was not the case when the software market was incubating. Back then you were a programmer that is it. Back then you would also write code in Assembly, C and C++ and if required exercise your acumen in electronics too. Things changed slowly to have Mainframe programmers and that just seeped through time and culture. 

In the present time for good, we are finding terms like full-stack developers popping in the culture. Now developers market themselves as kind of problem solvers with expertise in a few programming languages.

Birth of containers

Server hardware plays a crucial role in building the system. Bare metal hosting made it difficult to incubate different runtimes all at the same time. Say JVM and CLR running together serving a common need of the system. Virtualisation made it a bit easier as time went by. However, the entry of containers in this market changed the landscape forever. Bare metals did not vanish. Instead, they became more agile. 

Now containers within a singular bare metal server can serve JVM and CLR together efficiently. Today, one can have a micro-service built in C# running in the same server as another micro-service built in Java.

The best practices panacea

Given talent marketed themselves as an expert in one and only one programming language, getting talent who could write maintainable code was an offshoot branch of the challenge. Thus, to keep the code base of the system maintainable decades of effort were poured into making industrial procedures popularised as best practices on how the code must be written. As with any industrial procedure variability was frowned upon and often positioned as an efficiency killer. However, decades later maintainability is still a challenge to many systems. Does that not prompt you to say probably the way best practices were disseminated was not efficient? Instead of applying best practices to a language or framework, we must look at applying them to the context of the problem. In contemporary times words like architecture centre and well-defined architecture are finding more traction along with design patterns and best practices.

Maintainability can still be achieved by components of the system that are written in different languages and frameworks. It is not an antithesis of practising the best practice.

Advent of GenAI

Generative AI technologies can generate code in many different languages and also aid in modelling the real world in the said paradigm of object or function. This could address some of the skill gaps in knowing many languages. However, it comes in handy by introducing another paradigm where the programming language itself could be the language that humans use to communicate. Be it English, Hindi, Tamil or Bengali.

GenAI could make the decision of choosing a language to write code itself redundant whereas a GenAI assistant with plugins could be the system by itself.

We would give our readers to ponder on the last thought about the possibilities. In a future dispatch, we will pick this up again and build upon the thoughts put forward here