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 centered 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 a few popular ones you must have practiced. 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 centers. This is relevant in a worst-case scenario when a component of the
system is separated from another by a data center. 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. Virtualization 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 on 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 is 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 practicing the best practice.
Advent of GenAI
Generative AI technologies can generate code in many different languages and also aid in modeling 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