Skip to main content

Things They Didn’t Teach Me in School: Polyglot

Over the years, you’ve probably spent a lot of time reading and studying computer topics. I have attended many classes and even taught a few and never came across the topics of polyglot persistence and programming. If somebody taught me about polyglot anything, I am sure that I would have remembered it. These are topics, polyglot persistence and programming, discussed by IT practitioners and opinions are on both sides—good idea and not so good—let me explain.

Polyglot Persistence

The idea of polyglot persistence is this: the programmer should actively choose the best data solution to meet the needs of the application. That could be a database, file system or some other solution like virtualized data, depending mainly on the best fit. This approach challenges the standard in some IT departments that all important data should reside in a database with some departments going as far as prescribing the specific database product. It makes sense that IT organizations want to manage risk and control expenses and by specifying the use of a specific database management system (DBMS), this helps to achieve that goal.

The problem is that use of a DBMS is overkill for some situations—too much function that’s not needed. Often, a file system is an adequate choice. For select high-performance situations, a commercial DBMS is too slow and projecting a data set in virtual memory is a better high-performance alternative. The pros and cons of polyglot persistence focus on speed and scalability versus skills and testing.

Polyglot Programming

The idea of polyglot programming is this: the programmer should use the programming language that is best for the needs of the application. “Best” is an interesting term because context is everything. If a reporting program is needed, COBOL might be best if that is the dominant organizational skill, and COBOL has strong reporting capabilities. Java might be “best” when distributed database access is required as the JDBC API can access any kind of tabular data, especially data stored in a relational database.

To implement this idea, many IT departments have developed guidance to help with decision-making (e.g., when you have this situation consider this language solution). As you can imagine, with the huge number of language alternatives available, chaos might result without some well thought out alternatives and guidelines. If you don’t currently have advice for programmers, there are plenty of thoughtful suggestions that can be used focused on ease of learning, ease of understanding, speed of development, help with enforcement of correct code, performance of compiled code, supported platform environments, portability and fit-for-purpose. This list of guidelines are suggestions from author Chris Britton.

Next Week

Next week, I want to explore something else they didn’t teach me in school—two styles of design and development—pseudo conversational and RESTful web services. Both are useful and interesting to embrace in today’s world of design and development of computer transactions.