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.↩
ECMAScript 6 has sane variable scoping keywords, Java 8 added lambda functions, PHP 5 introduced namespaces, etc.↩
Or a paraphrase.↩
This is an important article related to Natural Langauges as well as Artificial Lan∆gauges.
Q: From whence emerges this intriguing “Footnote” on-hover property? Is this a Disqus feature, or a special template You’ve chosen, or a fragment of code You’ve specially engineered for the Purpose of enhanced, in-line footnote look-up? It’s a wonderful characteristic of hypertext that this sort of media interface is possible, and it’s missing, i believe, from the feature set in all blogs i’ve started writing in the past.
My apologies… just found it in the Colophon Section…
The footnotes feature comes from Bigfoot (http://www.bigfootjs.com), and there’s a fine plugin available in WordPress.
RE: Natural langauges, the Babbelfish is particular is going to have a Profound Impact on how We cooperate across langs and lan∆s, and embracing langauge diverseity is going to be key to any motion toward “United 中” Patterns in Reconstituting any Republic as “Medically and Nomically Invitational”.
And We’re about 10s away from the Babbelfish..
Thanks for this thoughtful post Allen. I recognize and celebrate the overall diversity of languages, libraries, tools, tech, etc out there. People are working hard to solve real problems they face, and throwing off great tech that other people can use via open-source. All that is wonderful.
A corporation, or a non-profit, or a band of developers with shared goals + leadership structure, etc – an “org” – is a set of people who have come together to take advantage of the power of acting as a group. In a group, one person doesn’t have to do everything: you take advantage of specialization. As people in specialized roles solve problems, the entire group benefits – this can be phrased various ways – as collective action, realizing economies of scale, policymaking, leverage. There’s little sense in creating any sort of organization if you’re not taking advantage of both specialization and collective action/leverage/reuse.
Diversity drives the quality of the specialized areas of an org. When it comes to hiring: maybe I want PhDs working on certain problems, business analysts working on others, folks who have been through the school of hard knocks running large production systems in other areas. This is where the analogy to cultural diversity in hiring works: we intentionally strive to hire people from a range of backgrounds, in part, in order to raise the bar of what an org is capable of, in any given specialty.
Injecting diversity into the collective action conversation is a little strange. Those concepts are obviously opposed. I imagine someone walking into a construction project halfway through and proposing that the project add parts and tool based on the metric system, under the mantle of diversity – it just doesn’t make any sense.
What is so odd about language choice is how different we treat it from other areas where we’re comfortable with hewing to a common policy. You call out that language choice fraught with religious feeling – it certainly is. Your reaction is to take this one area (language choice) and compromise.
The challenge, as I see it, is get a handle on this religion thing. We accept use of a Mac, or MySQL, or Linux, or whatever the local message broker is, even though they’re the ideal tool at most 90% of the time. I just don’t accept that an org should roll over and throw away some of the advantage it has, an important part of the reason for its existence, on this one odd little subject. Back to the construction analogy: as strongly as some may feel about the metric system, and as much as you yourself might be in agreement, if you’re running the show you’re not going to derail the effort by introducing it right in the middle.
This is a straightforward point to make, a potentially straightforward conversation to have, but I observe that these days it’s becoming harder and harder to even start to talk about language (and frameworks, to some extent) without software engineers feeling like they need to defend something sacred, and personalize the issue (we allow words like “happiness” and “coercion” in, and willingly allow a rational discussion to be framed in terms of physical or emotional attack).
And language isn’t the point, it’s not an end. This is put well here: http://learnpythonthehardway.org/book/advice.html
I also would just like to say for the record that Allen and I’s previous conversations about this had nothing to do with hiring diversity – this is this first time that’s been brought up. On the off chance that Allen has left the reader with the idea that I’m somehow opposed to hiring diversity initiatives, I just want to clarify I fully recognize the problem that exists in the tech world in this regard, and personally am in favor of various efforts being made out there by hard-working, committed people to address the problem.
Also that’s not my picture – what’s up disqus?
🙂