A polyglot is defined as one who is fluent in multiple languages. This is similar to how a multilinguist is ... uh ...fluent in multiple languages. (OK, who invented two words for the same concept?)
Well, it turns out polyglot applies not only to spoken languages, but to programming languages as well. Thus in the software world, a polyglot application is one built on multiple languages. The term also applies to developer tools that can manipulate such apps.
Why Add Complexity?
Adding languages increases complexity. You have to maintain proficiency in, or awareness of, the various syntaxes, tools, libraries, test strategies, thought processes, and talent pools for each (not to mention meetups and trade-shows to attend, rss feeds to subscribe to, blogs to read, test strategies, etc.).
There are good reasons to go with a single language to unify the required knowledge and dramatically reduce complexity and overhead.
So given their additional complexity and cost, why are polyglot applications rampant in enterprise software endeavors?
Using the Whole Toolbox
The best reason to use multiple languages is captured by the simple maxim: Use the right tool for the job. All languages are not created equal. Successful languages are successful for a reason, usually because of something they do well. But "when all you have is a hammer, everything looks like a nail," and not every software or business problem is a nail.
Consider some typical enterprise tasks:
- create a test suite, defining DSLs to orchestrate the tests
- build a secure, transactional, high-volume backend that sits behind REST
- validate and respond to user input in a browser
- manipulate registers and hardware in a limited-memory device
- rapidly prototype a traditional MVC web app
- build a sophisticated UI-heavy workflow management system
- frequently perform long-running data-manipulating batch jobs
The list of languages chosen for these tasks is as varied as the organizations that make such choices. Factors such as compatibilty with existing tools, customer requirements, legacy code, performance criteria, library availability, cost, support options, complexity, open source considerations, team experience and bias all influence the decision.
One thing is clear though: there is no "one language fits all." So polyglot apps are here, for the forseeable future anyway. As mentioned above, adding languages introduces complexity which especially impacts the deployment phase and hits multiple teams (dev, QA, release, IT).
Polyglot PaaS to the Rescue
With the advent of Platform as a Service, a solution is at hand. Instead of spending days or weeks and the efforts of multiple teams assembling stacks that supports each language, these stacks can be created automatically in minutes or seconds with a PaaS.
ActiveState's Stackato, a private PaaS, is well versed in a wide array of languages. It includes Ruby, Java, Python, Perl, Node.js, PHP, Clojure, Erlang, Scala... and the list is expanding. In fact, Stackato's extensive support for this wide range of languages elevates it to the status of a "hyperpolyglot", a term some linguists apply to a person who can speak six or more languages.
And not only languages. Stackato also supports the web and application frameworks that go with them (like Ruby on Rails, Spring, Django, Play!, backbone) and bundles common data services such as MySQL, RabbitMQ, Nginx, MongoDB, Redis.
So if you are constructing or maintaining apps with components built in disparate languages, take a few minutes to fire up Stackato. Those few minutes could save you the considerable time and effort of assembling the platforms yourself, and ultimately lead to a more cohesive deployment strategy.
Trackback URL for this post:
Share this post:
