3 ms·
> The projects should be chosen by controlling their characteristics rather than relying on GitHub “stars” which capture popularity and are unrelated to softwar
by wwwigham 7y ago
> The projects should be chosen by controlling
their characteristics rather than relying on GitHub “stars” which capture popularity and are unrelated to software
development.
> “stars” ... are ... unrelated to software
development.
I wouldn't call sentiment about software _entirely_ unrelated to software development - minimally I'd assume that more popular projects, receiving more traffic due to higher engagement, would also receive more scrutiny, and thus have more bug(fixe)s. That would be an interesting characteristic to attempt to select for, no?
> Part of issue 9 is left unchallenged: 34% of the remaining TypeScript commits are to type declarations. In TypeScript,
some files do not contain code, they only have function signatures. These are the most popular and biggest projects in
the dataset. We corrected for this by removing TypeScript.
Those are... Still code? At least as much as header files in c are, and they can totally still contain bugs. Now, if we're talking about how they're often redistributible copies (like headers), especially way back at the time of the paper before @types came about, and how duplication due to that may inflate meaningful SLOC, that's interesting. Would be nice to see a good argument for it to be corrected and controlled, rather than dropped outright. Then again, TS has grown a ton in the intervening years, and the "largest" repos listed are... Very unused now. Wholly outdated. Entirely obsolete. You'd probably get different results with fresher data, too.
> The classification of languages is wrong: consider Scala. In FSE, it is lumped with Clojure, Erlang & Haskell under
the “Functional Paradigm”. For this to be meaningful, there must exist some shared attribute these languages have
that makes programs written in them similar. Referential transparency and higher order functions could be that. But,
while Scala has higher-order functions, it is imperative. So, it is not a perfect match. Worse: Java also has higher-order
functions, yet it isn’t in that group.
Many newer languages are multiparadigm, but I'd probably still say that Java encourages the imparitive OO style, while Scala prefers the functional composition style. I don't think "a single unifying characteristic" really helps, given the feature bleed between modern languages. I think you only get a great classification by examining, eg, what the community style standards are.
It'd be nice if open data studies like the one under discussion here were reliably posted in a format where the analysis could be easily recalculated, readjusted, tweaked, and represented. It's the kinda thing that could be neat to play around with in a notebook.
- TeMPOraL 7y agoGithub stars are first and foremost bookmarks. Not expression of sentiment, not votes of quality, just bookmarks. You see an interesting repo, you star it, so that you can find it later.