Polyglot Programming and the Database Developer

A database development concept in circulation for several years holds that developers should be able to pick and choose the best tool for a specific job.

The theory, known as polyglot programming, was reintroduced by Neil Ford, with others, namely Martin Fowler, picking up the idea.

Is the approach valid or useful in the enterprise database development environment? Opinions vary widely, but these vastly divided opinions offer database professionals ideas they can apply in their own organizations. I’d like to offer some views as these concepts might or might not relate to the “enterprise” database environment.

Right Tools for the Job

Ford, author of Functional Thinking and The Productive Programmer, originally wrote a blog post on the concept in December 2006. At the time, the number of programming languages was growing exponentially. Where IT professionals once had to profess expertise in a single language or framework, they were increasingly required to marry and blend different tools to create useful applications. For example, java might have been the single focus of a developer and that’s all the developer needed to know. It was the single choice for any solution but not always the “best” choice. As development languages in the JVM evolved and developers began to try different approaches we began to see changes in the way languages were used instead of just java, for example. Thus the concept of polyglot programming.

At its essence, polyglot programming is “the use of different programming languages, frameworks, services and databases for developing individual applications.” Developers need to be able to use different languages in order to avail themselves of the best tool for the job, Ford contends.

Mix and Match

In revisiting the concept for an O’Reilly podcast in late 2013, Ford says the polyglot programming concept remains important. The approach is “much more common than not” among today’s programmers. There are now so many new languages available that it’s become increasingly common to mix and match them on the same platform rather than to force all the programming into Java or C#, says Ford.

The main advantage to adopting such an approach is that a developer can stop trying to invent a whole new framework to solve a problem. As Ford notes, the developer can, instead, use “a tool more keenly shaped to the job you’re trying to perform.”

The idea is to use the strengths of each different language to craft a solution rather than trying to accomplish a task in a framework for which it is ill suited. One such example is trying to build a user interface in Java, when Ruby-based languages and tools are better designed for such a task.

Problems in Practice

As Datavail’s Executive VP & Chief Operating Officer, Keenan Phelan observes, the practice doesn’t always work in enterprise applications:

According to MSDN Magazine, developers also must understand how the different languages they intend to use map to the underlying platform and to each other. Without this, problems arise and can be compounded. Another problem is that debugging, already a challenge, can be a more difficult task when dealing with more than one language.

Adds Phelan:

Necessity of Integration

In the past, as databases and data use evolved, says Phelan, it became important for the sales group to see manufacturing data, for example, and for the financial group to see data from the sales group. The advent of relational databases allowed data to be integrated and available in a single location accessible to people across an organization. That, he says “was more important than the technical niceties of having a database for every application.” He adds, “You naturally have to get down to some finite amount of platforms for you to be commercially viable and for it to be pragmatic for large enterprises to use the technology.”

Ford says using polyglot programming does not automatically make things better. In adopting the approach, a developer is “adding purposeful complexity” to the code base “so there has to be a good justification for doing that.”

Fundamental Issue

Why is this issue important? In this era of Big Data, both developers and database administrators, must hash out issues fundamental to making Big Data work effectively and efficiently in the enterprise. Using NoSQL databases for JSON data or document storage makes sense but then keeping relational data in its proper structure makes sense as well. How do you determine what direction to take and when for your enterprise solution? Big Data is termed exactly that because it is a “Big” problem that needs a solution. And the old paths might not always be the right paths. What tools do we use to plan, to implement, to debug? How do we take all the theory into our enterprise environments and make the business better? Phelan concludes:

Here at Datavail, we can help you find “the right tool for the job.” Get in touch and see what our experts have to say.

Image by photka/123RF.