GitHub Language Trends • Hacker News Board

Re: GitHub Language Trends

#61

Post by lkrubner » Sun, May 04, 2014, 9:01 PM UTC

To my mind, the big trend is toward polygot programming, which perhaps reveals what a transitional and perhaps revolutionary time this is in the world of computer programming. This paragraph struck me as the most important:

"Almost every language shows a long-term downhill trend... My initial guess is that users of languages below the top 12 are growing in share to counterbalance the decreases here. It’s also possible that GitHub may leave some users unclassified, which would tend to lower everything else’s proportion over time."

Re: GitHub Language Trends

#62

Post by meepmorp » Sun, May 04, 2014, 9:04 PM UTC

threeseed wrote: post #20

camus2 wrote: post #17

Earlier quoted context omitted.

say what? Ruby isnt for hobbyists, neither is Python(dont know Perl).But you just wanted to hear yourself say that didnt you?

It isn't entirely untrue. Ruby/Python are more popular in the hobbyist space and less so in the enterprise. Java is the opposite. It shouldn't be seen as a reflection of the platform.

Does the scientific computing community count as hobbyist? It seems to be a significant niche for python these days, largely due to numpy.

Also, as another user noted, hobbyist/enterprise is a false dichotomy. There's shedloads of non-hobbyist code that also non-enterprise.

Re: GitHub Language Trends

#63

Post by The_Double » Sun, May 04, 2014, 9:16 PM UTC

rumcajz wrote: post #6

This looks like commercial ecosystem (Java, JavaScript) migrating to GitHub rather than hobbyist ecosystems (Ruby, Python, Perl) being on decline.

I think a large part of the rise in Java code is because of a large amount of open source android projects. (applications and mods/forks of the operating system)

Re: GitHub Language Trends

#64

Post by chx » Sun, May 04, 2014, 9:25 PM UTC

camus2 wrote: post #57

chx wrote: post #50

Earlier quoted context omitted.

I do not think Go as something that would go on itself as a job. Instead if you already have a site (like Drupal which is my primary skill) and you want to add a very performant REST interface then Go provides a pleasant way to write one.

I would really question the choice of drupal at first place,or any use of the PHP plateform.

There's still nothing, by far, that would match the versatility of how much can you do from the Drupal UI.

Re: GitHub Language Trends

#65

Post by gurkendoktor » Sun, May 04, 2014, 9:27 PM UTC

m_ram wrote: post #30

> Violating all expectations and trends, new Java users on GitHub even grew as a percentage of overall new users, while everything else went downhill. This further supports the assertion that GitHub is reaching the enterprise. This is more likely to be due to the rise of Android since 2009.

I would also expect a few CS students to push their homework to github nowadays, and most homework is Java.

Re: GitHub Language Trends

#66

Post by gurkendoktor » Sun, May 04, 2014, 9:32 PM UTC

pron wrote: post #22

GitHub is slowly starting to reflect the software world at large, although the true picture is Java and C leading by a huge, huge margin. I don't expect GitHub to ever fully reflect that, as most Java shops, and nearly all C shops, would never host their code on GitHub.

I think it's safe to say that most projects on github are libraries and snippets, not finished products. Not even Ruby shops push all of their actual work to github. But at least there is a culture of sharing libraries, which drives the Ruby % up, and I don't see this happening a lot with C.

Re: GitHub Language Trends

#67

Post by munro » Mon, May 05, 2014, 1:52 AM UTC

unfunco wrote: post #58

munro wrote: post #54

Earlier quoted context omitted.

The Node core dev actually went back and forth on this, and came to the conclusion to not commit dependencies to the repo, and introduced "shrinkwrap" [1]. It felt wrong committing dependencies to the repo, which I agree with. I hate my diffs being drowned in external changes, I'd rather see that someone simply upgraded a dependency. Plus it does skew the project, both for what the primary language is, as well as how…

I agree. Hovertruck quoted a piece from the Bower documentation, which I can see the reasoning behind, if you're working on a web application then committing the library removes the possibility that the dependencies cannot be resolved because a library has been removed from the package manager. There are benefits to both options, but my personal preference is to keep third party libraries out of the VCS.

:D Just to take this a little further, at my old employment, our Ops wanted the dependencies to be committed to the repo. To make rolling back faster, since `npm install` can take awhile. Also, there was a time NPM register went down wrecking havoc.

But that's shouldn't put weight in either direction. Instead, there's a much deeper issue here: Ops should be building packages for deployment. Whatever that means, RPMs, VMs, Docker images, ... Just separate the concerns. Seal it up, and store it forever and ever, perfectly.

Because even if dependencies are there, safe and happy, most applications have a build process. Which takes time, and could be different on the machine it's building on. Only you can prevent production fires.

Re: GitHub Language Trends

#68

Post by return0 » Mon, May 05, 2014, 12:07 PM UTC

zongitsrinzler wrote: post #23

sheetjs wrote: post #8

FWIW many projects written in web languages like PHP seem to be treated as javascript by Github because they also have javascript code (which happens to be more significant / larger than the underlying code). It's unfortunate that there is no way to specify the primary language of a project. The Github language system is also somewhat unpredictable: https://github.com/SheetJS/test_files seems to alternate between App…

If a project mainly consists of JavaScript it should be a JavaScript project, no?

Most HTML projects would then be "Images". My plain html project is marked as 'CSS', my arduino project (which contains a python file, but no java) is marked as 'Java'; that's 2/5 errors.

The files that get changed/updated are the ones that matter. If most of your diffs are PHP, then you're mostly workign with PHP.