Unfortunate they had to exclude Javascript. I understand why they chose to do that, but that's a HUGE chunk of data that's been pretty much randomly ignored. So can this really be considered a fair analysis given that?
No one has a choice with JavaScript. Theoretically you could go native or transpile but it's very rare.
Therefore, if you included it, the data wouldn't lead to meaningful conclusions. I feel like this was pretty obvious from the article and that the explanation was enough. For example, substituting node for js seemed to work well enough.
No one really has a choice with C, but its tally was very interesting..
I think there is a lot more vertical movement and the horizontal stuff might be a sideshow without considering overlap or experience with C or JavaScript as significant in how one transitions between purely competing languages.
But JavaScript's real problem for the analysis might be that its competition is largely excluded since the walled garden apps rarely have related code on GitHub, even if their language is present.
There's a huge choice for C. For a lot of uses, you can use C++, Go, Java, Rust, or a few other systems languages. The only thing that needs C is some very niche embedded stuff, or the Linux kernel (also niche).
All the major Unix kernels are in C. If it continues this trend, it seems clear that new kernels in new languages will be needed, or existing kernels will need to be ported to other languages. A memory safe one would be cool...
Well, if you think that C is going to go the way of conversational Latin, that would probably be accurate. I doubt that's accurate, because:
1. The fact that fewer people are choosing C for other projects doesn't mean they can't or won't learn it for kernels.
2. Nobody has yet to produce a language that is clearly superior to C for systems programming. Otherwise, we would be seeing movement towards that language instead of Java and Python.
The other thing to remember is that these are GitHub projects; the vast majority of them are not going to be kernels but application software or libraries. That would explain the moves from C to Java and Python; it's easier to write applications in those languages.
I encourage all programmers to check it out. You may discover like me, that Rust is a compiler and language which guards against all the hard learned lessons I've had over my career. It's an amazing language to program in.
Not really, kernels were being written in HLL 10 years before C existed, and at strange places like IBM research.
The only good thing about it is that the language is easier to write a compiler for, as it is basically a portable macro assembler, specially the K&R C variant.
Right, so the restrictions on at the bottom seem pretty meaningless, and that matches the migration off of C.
So how do we justify this JavaScript as forced labor argument?
The programmer can decide to do webapps that run atop C and get assistance from a backend that ultimately runs on C.
The programmer can use backend frameworks that deliver incantations in JavaScript much like their downcalls to C.
If the migration were toward metal we would be hearing that C has to be excluded. Really how the Buffalo herd is moving does matter in a discussion of what ditches they are stuck in in the middle Savannah.
>The programmer can decide to do webapps that run atop C
Please explain how to make a slippymap[1] in C.
For srs, I'm making a hobby project at the moment that needs a dynamic, interactable map on a webpage, and as a long time noscript user it galls me a little to use JS. The only compromise I can come up with is re-hosting the JS libraries I use and ensuring they don't have their own dependencies so that users only need to enable my domain for the site to work.
If you can tell me how to do the same thing in C, I'll swap to it immediately.
I guess that meets the criteria of "programming for the web but not making github commits in javascript", but it doesn't really solve my problem. Oh well.
I think you could make the argument that because the C ABI is available in most compiled languages, you do have a choice. Whereas on the web, JavaScript is the ABI.
Most working developers don't have a choice at all for most of the coding they do because the company or team that they join has already chosen a language. Ditto for frameworks.
There's a lot of compile to JS languages. It'd be interesting to see how many frontend devs are migrating to these languages for at least some of their projects.
I think so. I mean, aside from Node based projects, how many people are really doing pure-javascript apps? The pattern is typically JS on the front and something else on the back.
I guess if you can split out Node, React Native, and whatever other thing people are doing with Javascript that is pure Javascript, that would be a little bit more fair.
I am not saying that I would exclude Node projects; I am saying I would exclude all Javascript projects that are not Node. Or React Native. Or Electron. Or whatever is used to create a purely Javascript app instead of one that only uses Javascript because a portion of the app's user interface exists at runtime in the context of a web browser.
This looks dubious to me. Not least do to the healthy flow of people moving from other languages to Visual Basic.
Also byte flow makes little sense for programming languages. lower level languages are going to be more verbose than high level languages. They'll be used for different things. Some will have tonnes of boilerplate that travels with the project (e.g java). Forked projects? etc.
Further, to me it seems that this ought to be a more descriptive thing of how something happened in the past and not subject to probability unless the claim is a prediction about next years conversions between languages or that conversions are stationary over time.
I.e a set of metrics that proxy transitions and an order list of from and to, would be just the ticket IMO.
Some possible confounding variables:
what if certain language users are more likely to squash commits?
what if certain language users are more likely to have private repos?
I don't think squashed commits matter since they used project byte size as a filter to get rid of "Hello World" sized noise.
Hard to tell how much private repos would sway the results. Maybe a large number of COBOL programmers are stuck behind their organization's private repos and all we see are the languages they play with on the side for fun?
I think it could make a pretty large difference, actually. Languages like JavaScript (I know it's not included here, but still), Ruby and Python have large open source communities creating time of libraries in common usage. Compare that with a language like C#, which has an extensive standard library and comparatively less open source third party libraries. You'd expect that even if there was an equivalent number of private repos in both cases, the languages with a larger open source ecosystem would appear more popular in this analysis.
I used to think I understand Linear Programming, and the transportation problem. Is there a relationship between this and the Markov formulation? I'm totally confused now. Posts like this make me feel guilty about not reviewing them once in a while. And I guess while I'm at it with the questions:
>We have to add an artificial source and sink on both sides of our bipartite graph to ensure flow conservation
Wasn't there a hack with the slack/surplus variable in the LP constraints to deal with this or was it a dummy variable? Pretty sure that was able to handle the case where supply was not equal to the demand.
Also, how were cases where the user stopped using GitHub altogether or a new user started programming are handled?
People do so much advanced analysis with these outrageously biased datasets (this says nothing about "developers", this has analysis of "developers who put repos on github, skewed towards prolific repo creators")
Yes, it's the only dataset you have. You still sound dumb when you inflate the importance of the population you have data for to make the anlaysis sound more useful.
Relax, it's just a blog post from a "machine learning intern", and sounds like just the kind of project you'd give an intern for experience.
Anyway the first paragraph also says:
Thus, it has become engaging to deepen this idea and see how the popularity of languages changes among GitHub users.
I don't get the sense anyone is trying to inflate the importance of anything.
Uh, at least in my circle of developer and hobbyist friends Elixir and Erlang are blowing up. And reading the front page here, I would think the popularity of Elixir is not some small isolated phenomenon. What past language trends are you thinking of when you provide your source and make that assertion? Curious.
YOU'RE joking, right? Because you're looking at the data entirely wrong. The fact that a relatively new language has a CURRENT fraction of the interest of a more established one is an idiotic comparison to make, all that matters are the rates of change, and I challenge you to find another language with the slope of the "Jobseeker Interest" line on this chart:
