One great thing about programming languages is that there is such diversity that you can choose the best one to solve any given problem. But sometimes the worst thing can be when projects take advantage of this and build applications or systems of applications that require domain knowledge of many different languages. When this happens, it can be difficult for everyone, or even anyone, to fully understand the scope of the project.
Sometimes language diversity is fairly minor: a web application like the Drupal site powering Opensource.com is primarily PHP on the back end, with a few SQL queries to power database interactions, a JavaScript frontend, and HTML and CSS for markup.
But when you start thinking about the entire application stack, it gets more complex. What if you also need to debug the web server itself? The database server? The proxy server? The configuration scripts you used to set the whole thing up? The Bash scripts that you added to cron to do a few other tasks? The Python script you set up to pull out some key data for analysis? Pretty soon, even a fairly simple web application can get very complex.
And that's just a single application. In the enterprise, it's not uncommon to have dozens or even hundreds of related applications running concurrently, each sharing data back and forth to power all of the things that go into a modern organization. After all, that's the whole idea between microservices: breaking large monolithic applications down into smaller, more digestible chunks for better scalability, resilience, and easier management.
How many is too many? Let us know what you think, and if you starting to feel overwhelmed by the number of languages in use at your organization, take a look at today's article from Bart Copeland on How to use multiple programming languages without losing your mind.
2 Comments