I don't feel like clojure stalled out. You have to realize the redmonk rankings are using very weak heuristics to get these results. I'd rather choose languages and tools by how much they match the problem space rather than how popular they are at any particular point in time.
If you trim out all the worthless SO questions/anwsers you'll get radically different rankings on redmonk. JavaScript could very easily drop from its first place doing just that.
I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.
>I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.
That's wrong. Every civic engineer I know, for example, would prefer standard, and lacking that, popular nuts, bolts, construction parts, materials etc, over niche ones, unless there's some very pressing reason not to. They are cheaper and available in greater volumes, you can find skilled workers easier, their properties are more studied, etc.
That's even more important in programming, where ecosystem, availability of libraries, continued support on the language and compiler, availability of skilled programmers, existing codebase support, etc, matter even more than pure language level issues.
Popularity in a language is crucial, to the point that other attributes, like expressiveness, or even speed, can be inconsequential compared to that.
And while engineering can be a pop culture (e.g. Mongo or the latest fad), popularity is important for aspects that are totally counter to pop culture too: namely, pragmatism.
Programming is not about using what's "best", it's about using "what's best given business constraints" (which is something else altogether).
Besides, the hipster figure who listens to obscure music because it's "best" is also a pop culture phenomenon -- not to dissimilar to certain programming cults.
Having worked in both huge teams using popular languages/libraries/frameworks and small teams using what works best I'll choose the later any day.
We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
If you hire developers for what they know right now, of course you'll limit yourself to only the popular languages/frameworks. Its much more lucrative to hire developers for their potential to learn and grow; these people will make the best of any language/library/situation.
Of course, like you said, economics come into play but my point is that the popular choices often lead you to a path where you end up with a lot of mediocre developers, terrible architectures and endless conceptual debt. At the end of the day this is much, much more costly and doesn't even yield quality software.
> We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
See, the problem is, you still need to use frameworks and libraries, you just end up rolling your own, and now you are responsible for supporting and documenting all the different use cases your developers have. If I have an issue with, say, React.js, I can tap into the pool of the thousands of Stack Overflow questions and discussions, whereas I can't do that with a home-grown framework. Unless I'm doing something really low-level, I'll take the thing that has had thousands of man hours poured into it and an entire ecosystem built around it over the thing that you made because you're "allergic" to open source. You're going to be debugging someone else's code anyway, but the time spent doing that with open source frameworks is offset by the time saved because you don't have to build everything from scratch.
I never said I'm allergic to open-source, I said I'm allergic to frameworks and the vast majority of libraries out there. That leaves the few gems like React.js but they're libraries, not frameworks.
I won't have to write my own framework by not using one, while it may be easier to use one, its far simpler not to use any. You spend so much time trying to fit your use-cases into the framework's paradigm that its usually much faster to just write from scratch. Every single framework I've seen so far had huge scalability issues, they're easy to get started with but you end up crippling your agility as the codebase scales.
As for rolling our own libraries, we can make them specifically for the use-case at hand without anything extra. What's the point of using a few dozen libraries when you only use a fraction of each and now your bundle is megabytes in size? And that's not even counting all the extra code required to wire them all together. There's a reason why we say the web is bloated.
I tend to think the other way - the more popular the language, the more mature it's open source libraries. For instance, there are amazing open source java libraries out that's been battle tested in the wild.
Also, isn't the alternative of debugging open-source libraries writing the functionalities you need yourself? Working with faulty open source library is tedious, but that work can be seen as way to contributing your time to make open source library better for everyone.
As much as I like to contribute to open-source, the reality is I have budgets and deadlines to meet.
Most libraries out there will do a LOT of things I couldn't care less about, making them harder to integrate and debug and reason about, on top of bloating your executable.
I do agree there are a lot of amazing libraries out there and we do use a lot of them. But that's after analyzing them and figuring out they solve our problems and actually will save us time. For the vast majority of libraries we look at, its usually faster and better to roll our own.
"I don't get why people chase popularity in programming languages"
I am forced to do this simply because I consult at companies where the managers do exactly this. They will not let me use a language unless it is a top language. If I say "Clojure would be excellent for the project that you have in mind" they will reply "We can not use Clojure because it is not popular enough. We have to use a language where there is a large pool of developers that I can hire, and there is no risk that the language will disappear in 5 years."
I can understand in these environments they want to limit risks. And because the work is boring and the conditions are average to begin with, these companies are always on a massive roll of junior developers. It's especially bad if code isn't their main area of expertise.
I've seen companies of 300-500 employees struggle to keep even a single senior programmer over half a decade. They'd get far more talent by actually embracing an engineering culture. What I always see is that the juniors start getting experience, realize the place they work at is a huge pop culture and leave for an engineering one, thus lowering the talent pool of said company.
Basically they don't want smart engineers, they want replaceable code monkeys. They have yet to realize there's a few orders of magnitude worth of quality and productivity between the two.
I used to work in such an environment until I had enough of this cancer and decided to move to a small studio with less than 30 employees but with a very strong engineering culture.
Yes, that, and the quality of applicants tends to be higher for some of the less popular but more interesting languages. I worked at a company that had a large java codebase and was reluctant to try anything different for fear of not being able to find developers. But then we'd get these applicants with dozens XML/JAX-WS related keywords on their resumes but who couldn't write a simple for loop or understand what a database transaction meant.
I recall reading about someone (was it Spolsky? IDR) who looked for candidates with certain niche languages on their resumes, because it served as a quality signal. If they're interested in learning Clojure, for example, they may just be more generally curious and/or have a desire and interest in learning about different paradigms.
That said, at a practical level one has to balance competing demands. If you have someone on your team working on a project in X and they're the only X developer you have, you're at risk because if they leave, you may be screwed. Plus, they won't be getting quality feedback on their work because no one else can understand X.
I think its google who also asks for Python experience next to Java experience because it shows you went ahead and learned something on your own that wasn't spoonfed to you in school.
While others have pointed out the value of popularity, I think you make an interesting point about SO part of the ranking.
Consider the corners in the graph off the line. E.g. - SQL: "nobody" is making voluntary github projects with it, but it generates a lot of questions (the legacy code quadrant). Alternately, there are fewer things below the line, but those would be the things that people are using, and NOT being regularly confounded by WTF they do :-)
Because if you like a language and that language is popular, you're more likely to find a job using that language, which in turn will make you happier.
If you trim out all the worthless SO questions/anwsers you'll get radically different rankings on redmonk. JavaScript could very easily drop from its first place doing just that.
I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.