Does the Github search API take forks into account? Assuming it doesn’t, this would skew the results towards popular packages with lots of forks. Whether this detracts from your conclusions is debatable. You could argue that a newcomer is more likely to look at popular packages.
It doesn’t. I’d expect at least the relative frequency to be similar, but this could very well increase how frequently extensions pop up. But I think that it’s probably much more common to enable extensions on a file-by-file basis than a project basis.
It’d be cool to see what effect adding those back has, but it’s probably not doable with the GitHub API.
I wouldn’t be surprised if adding it in pushed the most popular ones higher, because why worry about which files need OverloadedStrings? But that’s just a random guess, and it may be that not enough people use the feature for it to matter.
Thanks! My remark was sort of an idle complaint; what a pleasant surprise to see a real study that more or less confirms my unscientific impression. For what it’s worth, in my experience the language pragma combinatorics don’t really contribute inordinately much to the Haskell learning curve, in comparison with all the other fancy abstractions and idioms. It’s a complex language, with or without the pragmas.
Looking at your results, I have a follow-on question about how frequently these extensions occur together. Are there prominent clusters of extensions? I’m thinking of constructing a weighted graph with pragmas as vertices and an edge for each co-occurence in a source file.
Do people no longer turn on extensions in Cabal files? I’m shocked to see numbers so low. For my current Haskell project, now at about 3000 lines, I still have lots of files with >5 extensions, even though I deliberately tried to keep things simple and avoid advanced language features. (This is still nothing compared to Cubix, my last project. When I speak to Haskell meetups, I even have a slide joking about it.)
How many files are there that only use the extensions in the list? They didn’t answer that question (just numbers of individual extensions), though they made claims.
Just so I understand the scope since I’m not a Haskell programmer, but 3000 files sounds like … a lot. I’ve used lots of c family languages and a project in any of those with 3000 files would be pretty significant; is that the case with Haskell as well?
Interesting analysis!
Does the Github search API take forks into account? Assuming it doesn’t, this would skew the results towards popular packages with lots of forks. Whether this detracts from your conclusions is debatable. You could argue that a newcomer is more likely to look at popular packages.
What am I supposed to do with that json file? edit: … oh, it renders completely differently on desktop…
it doesn’t render at all for me
Cool (and encouraging) analysis. Does this account for putting extensions in the default-extensions in a .cabal file?
It doesn’t. I’d expect at least the relative frequency to be similar, but this could very well increase how frequently extensions pop up. But I think that it’s probably much more common to enable extensions on a file-by-file basis than a project basis.
It’d be cool to see what effect adding those back has, but it’s probably not doable with the GitHub API.
I wouldn’t be surprised if adding it in pushed the most popular ones higher, because why worry about which files need OverloadedStrings? But that’s just a random guess, and it may be that not enough people use the feature for it to matter.
Thanks! My remark was sort of an idle complaint; what a pleasant surprise to see a real study that more or less confirms my unscientific impression. For what it’s worth, in my experience the language pragma combinatorics don’t really contribute inordinately much to the Haskell learning curve, in comparison with all the other fancy abstractions and idioms. It’s a complex language, with or without the pragmas.
Looking at your results, I have a follow-on question about how frequently these extensions occur together. Are there prominent clusters of extensions? I’m thinking of constructing a weighted graph with pragmas as vertices and an edge for each co-occurence in a source file.
Do people no longer turn on extensions in Cabal files? I’m shocked to see numbers so low. For my current Haskell project, now at about 3000 lines, I still have lots of files with >5 extensions, even though I deliberately tried to keep things simple and avoid advanced language features. (This is still nothing compared to Cubix, my last project. When I speak to Haskell meetups, I even have a slide joking about it.)
How many files are there that only use the extensions in the list? They didn’t answer that question (just numbers of individual extensions), though they made claims.
Just so I understand the scope since I’m not a Haskell programmer, but 3000 files sounds like … a lot. I’ve used lots of c family languages and a project in any of those with 3000 files would be pretty significant; is that the case with Haskell as well?
thanks for the equivalence! and my bad for misreading.
Some flags also enable others. There’s a list here:
https://github.com/ghc/ghc/blob/65c186f0fdde95fd7c63ab9bd9b33a0213dba7d1/compiler/main/DynFlags.hs#L4342-L4399
Though none of them would really change the analysis!