> "It’s not very idiomatic for JavaScript projects to use Make."
While I agree that popularity is a factor in picking a tool, it shouldn't be a deciding factor. Going by popularity is precisely how we end up with a new Build System of the Year(TM) every few years. The fact that we've gone through 4 fairly prominent tools (Gulp, Grunt, Broccoli, Webpack), all of which contending to "fix" the previous, and none of which have proper DAG or incremental builds (which Make has had for decades) is damning evidence.
In other words, I think Make could be (and I wish it was) idiomatic for JS.
Anyway, the fact that things change quickly in JS-land is more of a testament to how popular it is than anything else IMO. If C were used in the same environments as JS, I’m sure that you'd see just as much churn.
But if you consider browsers to be a "platform", which I think they are in fairness, then the GP comment could still apply. Whether the browser is written in C is pretty irrelevant to whether it can host it.
I conjecture that an upper-level "platform" that's on top of a lower-level "platform", for some definition of "platform", will be less varied and fragmented than the lower-level one.
Here's another survey that shows what kinds of languages programmers actually want to use and JS tops the list while C comes in below even Bash/Shell programming and PHP.
My point was that TIOBE is simply more all-encompassing than GitHut. It gives you a clearer picture of the most searched programming languages, which includes both GitHub as well as non-GitHub stats.
Also, GitHut counts repositories, not lines of code. Not sure which of C or JS has more lines of code being written every year, but my guess is that it's C (Java might have more than both though).
Nah, then it's pretty simple. My rebuttal is that I think "programming languages that programmers actually want to use"
(besides still being a debatable claim) is an insignificant metric. The industry doesn't pay for what you want to use.
Yes, popular = the thing people want to use. And it was my comment and it’s quite obvious upon reading again, that my implication is very clear. That's why github numbers alone are better because it shows what programmers actually want to use.
It's the same thing I've been saying to you for our last 20 interactions here. But I'll keep going because I'm not going to let you get the last word.
The GitHut numbers show repository count. I'm sure there all sorts of small JS repos with 50 lines of code, boosting project porfolios of people everywhere. Of course lines of code also don't mean something good: some languages are a bit more verbose than others. The TIOBE index shows what programmers search for, which is likely unbiased by LoC or repository count. My goal really is to help show you that JS is popular, but not nearly as widely used (or desired) as people make it out to be. As uncool as Java and C are, they still dominate software development. If you're dead-set on your position however, and don't wish to believe those data, then by all means let's disagree. :)
My position is that JavaScript is way more popular than C with programmers and that the popularity of JavaScript on GitHub proves my point.
Nothing that you have said has refuted that.
However, I do find your comment about "JS repos with 50 lines of code" to be particularly humorous since you can do more with 50 lines of JS than you could possibly dream of doing with 50 lines of C. LOL :) Thanks for a good laugh.
Any common examples?
> "It’s not very idiomatic for JavaScript projects to use Make."
While I agree that popularity is a factor in picking a tool, it shouldn't be a deciding factor. Going by popularity is precisely how we end up with a new Build System of the Year(TM) every few years. The fact that we've gone through 4 fairly prominent tools (Gulp, Grunt, Broccoli, Webpack), all of which contending to "fix" the previous, and none of which have proper DAG or incremental builds (which Make has had for decades) is damning evidence.
In other words, I think Make could be (and I wish it was) idiomatic for JS.