At my place of employment, we use Python for everything by default because "everyone knows Python" (which hasn't really been true of our small team where multiple members have far more experience in other languages than Python).

It grows, in my opinion, out of a desire for programmers to be interchangeable code extruders. The idea that a company might have to train anyone, or that a new hire might have to gradually adjust to a team's chosen languages and idioms, is antithetical to the dream of programmers as cheaply replaceable cogs in the machine.

This is a chicken-and-egg problem, and I suspect it can only really be solved when the labor market for programmers heavily favors workers. It's only then that large numbers of professional programmers significantly weigh aesthetics of language in their choices of job. It's also then that startups, which might have cultures that are more opinionated and/or less risk averse when it comes to language choice, are abundant and thriving. The rise of Python at Google worked on that same basis, didn't it?

I don't know that anyone can control the fate of a programming language like this. Maybe all you can do is make sure it's a lovely, useful language and the rest is up to fate.

▲

snek_case 4 hours ago | parent [-]

I would argue that there's obviously value in having your company/team use well-known languages and tools if they do the job well. Same as using open standards and well-known design patterns. If you choose a lesser known language, there better be a clear reason why.

	▲	pxc 4 hours ago \| parent [-]
		> there's obviously value in having your company/team use well-known languages and tools Sure. I never said this desire on the part of management is generally irrational. It's just that this (often rational) preference for "safe bets" leads to ossification and repetition. It's self-reinforcing and eventually becomes disconnected from the inherent virtues or vices involved in the thing chosen. If you enjoy participating in this network effect as a hiring manager or tech lead or whatever, or feel it's part of your duty as an ROI-maximizer, that's fine. You're probably right. It just seems clear that when such feedback loops are strong and risk aversion is high, it leaves little room for new languages to break into the "market" by competing on their intrinsic merits. So when that happens, it'll coincide with times and places of relatively high industry optimism and developer freedom. > Same as using open standards Open standards are about interoperability and user freedom, and don't really have anything to do with novelty or popularity. > Same as using [...] well-known design patterns A common pattern in designs of solutions for common problems that is counterproductive, or even just not very effective, is called an "anti-pattern". The honorific "design pattern" is reserved for patterns that are Actually Good™ in some way that would hold true even if no one knew them. Consequently, "this design pattern isn't well known" just means "this solution is highly effective for addressing a common problem, but isn't very famous". "Use well-known design patterns" is at least as much about choosing things because they're elegant, composable, flexible, performant, etc., as it is about choosing them because they're famous— hopefully much more so.