Github should really just enable the developers to specify the language of their repo by themselves. Bitbucket get this right in the first place. Auto detection for language sounds cool, while doesn't work for most of the web project.
GitHub Language Trends
51–60 of 68 posts
Re: GitHub Language Trends
#52Javascript is really hard to measure I believe, the numbers are always skewed because of 3 things:
1. A lot of repositories include 3rd party libraries.
2. A lot of software includes a web interface, even if the backend language is something else, but the LOC for Javascript can be equal or even higher because of 1.
3. JSON is counted as Javascript sometimes
Re: GitHub Language Trends
#53FWIW 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…
You can avoid 3rd party libraries being counted in by following some conventions, see the patterns ignored by Github's linguist https://github.com/github/linguist/blob/master/lib/linguist/...
Why not just hash popular files and don't count ones that match?
Re: GitHub Language Trends
#54Earlier quoted context omitted.
One could argue that jQuery, and other libraries shouldn't be included in the repository proper, instead it could be a submodule or included in a package manager manifest, such as bower.
From the bower docs: "N.B. If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control."
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 much a committer is contributing.
I would love to see this eventually in Bower! They have an issue for it [2].
[1] "Why not just check node_modules into git?" http://blog.nodejs.org/2012/02/27/managing-node-js-dependenc... [2] https://github.com/bower/bower/issues/505
Re: GitHub Language Trends
#55Earlier quoted context omitted.
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.
You have set up a false dichotomy here between enterprise and hobbyist.
[deleted]
Re: GitHub Language Trends
#56>Language detection is based on lines of code
This is important to note. As a huge ruby fanboy, one of my favorite things about the language are the shortcuts and syntactic sugar that are provided to make things easier.
I saw the decline and got a bit worried, then came here and had those fears assuaged. I do wonder if the LOC difference has anything to do with people getting more familiar with the language and doing more things in less code.
Re: GitHub Language Trends
#57Earlier quoted context omitted.
Go is a new language so not that surprising. It is also over represented here on HN. You don't see Go jobs in the wild for example.
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.
Re: GitHub Language Trends
#58Earlier quoted context omitted.
From the bower docs: "N.B. If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control."
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.
Re: GitHub Language Trends
#59In my experience, GitHub's so-called "detection" gets it wrong far more often than right. It's worse than useless -- it's misleading.
Re: GitHub Language Trends
#60Earlier quoted context omitted.
> I wonder if they weed out duplicate copies of, say, jQuery. Linguist tries to filter out things like that: https://github.com/github/linguist/blob/master/lib/linguist/...
"Tries" is the operative word here. There is a documented history of utter incompetence in Linguist.
Likewise for most of GitHub's other libraries. Sundown is some of the worst code I've ever seen.