Programming language debates are the religious wars of software development. Much like the xkcd comic on the futility of standardization, attempts to unify or consolidate our existing landscape of languages – and libraries and frameworks – usually just compound the diversity. For as long as software existed and exists, there are be programming languages featuring parts legacy, workhorse, academic, and popular. And occasionally functional.
I started discussing how language variety can affect engineering organizations with a colleague at Square. Our discussion started with this question1:
To summarize, Steve’s position is that companies and organizations should try to standardize on a handful of supported languages. An investment in a common core of languages ensure that enhancements – common components, libraries and operational fluency – enriches every team. My contrasting position is that companies should allow for language experimentation, and provide encouragement to teams if they’re able to successfully build systems beyond the organization’s status quo. In other words, organic adoption should be celebrated.
The major difference between homo and heterogeneity has always been in the tradeoff in immediate progress. With programming languages, mandating a single language per domain2 ignores the benefits of diversity, or at the very least severely delays its utility. Granted, languages add new features all the time, and new versions often contain ideas that other languages have popularized3. But, to work around a language’s deficiencies or to wait for its creators to eventually add the feature feels like self-inflicted chastity. As long as the APIs between systems is well-defined and implementable in the chosen language, and that it exhibits desired operational characteristics (e.g., it can survive production deploys and usage), then these systems uphold their abstractions agnostic of implementation language.
Additionally, engineering motivation and developer happiness are important factors to consider. Allowing experimentation in languages implies both a trust in the engineers’ verification of its efficacy, and an understanding that the team has to put in the extra effort to build the familiarity and tooling available with existent language choices. Teams which are firm in their convictions will have no problem rising to this challenge.
Seductive infrastructure: it’s a phrase4 that I heard mentioned from a former Amazon employee. It describes how Amazon’s infrastructure teams build their platforms to attract internal users – Amazon’s own product and application engineers – organically, without managerial coercion. The same ideal dynamic can be applied to language selection; each project and team figures out what languages and tools make sense for the job, with all the engineering support they need to make an informed decision.
I’ll note that the burst-driven, 140-character limited interaction model is horrible for making meaningful discussion.↩
Desktop, mobile, and web clients can usually only be built in specific languages and don’t offer much of a choice.↩
Or a paraphrase.↩