4 ms·

My experience is that mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce t

My experience is that mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature. I have been working for two companies that adopted Clojure and Scala early on. They all have, within a period of two to three years, enforced a Java only monoculture with no new projects being written in the aforementioned languages. The reasons were key engineers leaving for greener pastures and experiencing difficulties with staffing: Not being able to find (cheap) experienced developers, or failing to do in house training due to the lack of interest. This might be hard to believe, considering that the average HN user would jump of excitement at the chance to learn something new, but then again, those languages were introduced with the JVM as the main selling point, meaning working mostly with Java developers, who are notorious for their resistance to learn _anything_.

jcadam 7y ago
> mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature. Yea, that would be my cue to leave.
- hhas01 7y ago
  Indeed. Pick the right tool for the job. Picking the tool just because it gets you lots of cheap disposable developers simply means you end up with lots of cheap disposable code. Good for the current quarter’s C-suite bonuses, no doubt; maybe not so much for long-term business continuity when that code is critical to continuing business operations. Something something price of everything and value of nothing.
slaymaker1907 7y ago
That has not been my experience. Companies can and should develop a set of technologies that they as an organization feel comfortable with, but this list should be dynamic and should have some diversity in it. Don’t allow every technology under the sun without any vetting, but also don’t force everyone to use the one true programming language, Java.
- TurboHaskal 7y ago
  But that's what I meant by top-down controlling of the language stack: Which in the context of the blog post, would be the contrary of "valuing choice and freedom over rules and processes." It doesn't have to be a single language, of course. The typical "use / ask / forbidden" matrix for new projects would suffice. I don't have a problem with that, personally. It is only when programming languages are _exclusively_ being chosen out of non technical reasons that the fun ends and I'm out. Sadly, it happens too often.
Jach 7y ago
I don't really agree that it's a matter of time. There's a pressure, sure, but a stronger counter-pressure is simply having wider product categories and to a lesser extent enough employees to allow for some specialization. The moment you do web application development, chances are you're using at least two languages if not more. There are some all-JS web companies, there are also some all-Clojure/ClojureScript companies, but neither are very common. Add a database, you might have another language (or not). Add a mobile application, and you're looking at potentially 6 languages just for that product category depending on how you set it up. DevOps? Take your pick, probably at least two used at the typical company that has such specific roles. Survive long enough (many companies don't even last a decade) and maybe make some acquisitions, now you've got acquired product X in some other language -- do you do a rewrite? Another aspect of surviving long enough is the language you picked might have changed a lot. Modern Java, JS, Python, and C++ are all significantly different now than they were not too long ago. Companies with big code bases can't afford a rewrite or mass update, so they have a mix, and developers need to be aware of the conventions of the old versions that may as well be called old languages. Of course some companies will insist on banning the modern styles and idioms even if they begrudgingly update the tooling, for much the same reasons they ban different languages. Some companies do end up being long-lived and monolanguage though. And where I would agree with you is that individual products will tend to single language policies even if technically they can intermingle (i.e. all the JVM mingling). (Edit: and seeing your other clarifying comment, yeah, top-down control over letting teams make most of their own decisions probably is inevitable with time, this expands far beyond just language choice though.) Sometimes that language is Common Lisp! There are things that can be done to influence what it's likely to be, if it is to be. The "simplest" is probably just having a big enough, complex enough, and important enough product that no one's going to authorize a rewrite for even if the will and expertise to do so appeared. Then the monolanguage will be that language -- whatever a company starts with has a good chance of becoming The Language, but if you're starting with a not so popular language you're in danger of having it changed at some point and will need to protect against that if you care. (This to me explains Reddit's rewrite off of Lisp early on, the code that was written wasn't that big or complex yet, and also explains Facebook's lack of move off PHP and herculean efforts with Hack to compensate. But as companies Reddit seems much closer to the monolanguage endpoint than Facebook -- Facebook simply has way more engineers and a lot more projects going on.) Another driver is what you highlighted, lack of interest, or indifference, and is probably the main one until you reach a "too big to change" tipping point. You need to have someone who loves the particular stack, or (also?) who hates the alternative stacks, because if you don't someone else will eventually come along with enough ambition and motivation (either from hatred of current stack or love for a new/alternate/more familiar stack) and the stronger passions will win the day with the indifferent employees just going along with it.

jcadam 7y ago

> mono-language policies (or similar tight, top-down controlling of the language stack) are simply a matter of time. All companies enforce that as they mature. Yea, that would be my cue to leave.

hhas01 7y ago
Indeed. Pick the right tool for the job. Picking the tool just because it gets you lots of cheap disposable developers simply means you end up with lots of cheap disposable code. Good for the current quarter’s C-suite bonuses, no doubt; maybe not so much for long-term business continuity when that code is critical to continuing business operations. Something something price of everything and value of nothing.

slaymaker1907 7y ago

That has not been my experience. Companies can and should develop a set of technologies that they as an organization feel comfortable with, but this list should be dynamic and should have some diversity in it. Don’t allow every technology under the sun without any vetting, but also don’t force everyone to use the one true programming language, Java.

TurboHaskal 7y ago
But that's what I meant by top-down controlling of the language stack: Which in the context of the blog post, would be the contrary of "valuing choice and freedom over rules and processes." It doesn't have to be a single language, of course. The typical "use / ask / forbidden" matrix for new projects would suffice. I don't have a problem with that, personally. It is only when programming languages are _exclusively_ being chosen out of non technical reasons that the fun ends and I'm out. Sadly, it happens too often.

Jach 7y ago

I don't really agree that it's a matter of time. There's a pressure, sure, but a stronger counter-pressure is simply having wider product categories and to a lesser extent enough employees to allow for some specialization. The moment you do web application development, chances are you're using at least two languages if not more. There are some all-JS web companies, there are also some all-Clojure/ClojureScript companies, but neither are very common. Add a database, you might have another language (or not). Add a mobile application, and you're looking at potentially 6 languages just for that product category depending on how you set it up. DevOps? Take your pick, probably at least two used at the typical company that has such specific roles. Survive long enough (many companies don't even last a decade) and maybe make some acquisitions, now you've got acquired product X in some other language -- do you do a rewrite? Another aspect of surviving long enough is the language you picked might have changed a lot. Modern Java, JS, Python, and C++ are all significantly different now than they were not too long ago. Companies with big code bases can't afford a rewrite or mass update, so they have a mix, and developers need to be aware of the conventions of the old versions that may as well be called old languages. Of course some companies will insist on banning the modern styles and idioms even if they begrudgingly update the tooling, for much the same reasons they ban different languages. Some companies do end up being long-lived and monolanguage though. And where I would agree with you is that individual products will tend to single language policies even if technically they can intermingle (i.e. all the JVM mingling). (Edit: and seeing your other clarifying comment, yeah, top-down control over letting teams make most of their own decisions probably is inevitable with time, this expands far beyond just language choice though.) Sometimes that language is Common Lisp! There are things that can be done to influence what it's likely to be, if it is to be. The "simplest" is probably just having a big enough, complex enough, and important enough product that no one's going to authorize a rewrite for even if the will and expertise to do so appeared. Then the monolanguage will be that language -- whatever a company starts with has a good chance of becoming The Language, but if you're starting with a not so popular language you're in danger of having it changed at some point and will need to protect against that if you care. (This to me explains Reddit's rewrite off of Lisp early on, the code that was written wasn't that big or complex yet, and also explains Facebook's lack of move off PHP and herculean efforts with Hack to compensate. But as companies Reddit seems much closer to the monolanguage endpoint than Facebook -- Facebook simply has way more engineers and a lot more projects going on.) Another driver is what you highlighted, lack of interest, or indifference, and is probably the main one until you reach a "too big to change" tipping point. You need to have someone who loves the particular stack, or (also?) who hates the alternative stacks, because if you don't someone else will eventually come along with enough ambition and motivation (either from hatred of current stack or love for a new/alternate/more familiar stack) and the stronger passions will win the day with the indifferent employees just going along with it.