Live data from Hacker News

Too many R packages: CRAN is inundated with submissions

rworks.dev

31–40 of 85 posts

Re: Too many R packages: CRAN is inundated with submissions

#31
post #2

People would typically choose based on CRAN TaskViews or follow conventional methodologies, but what I notice from this is that R is truly a language used only by those who use it. And the people who use it are usually master's students or professors; it's rarely used at the undergraduate level. So even those with that level of academic background and training must have had their own implementation roadblocks. Could…

There is some great stuff in R but from a software engineering level I'd much rather data scientists work in Python. At risk of sounding like ChatGPT, it's not an R thing, it's a general thing. Turn [showdead] on in your profile and see how Show HN is flooded with AI slop projects and we all know GitHub is drowning in it.

I also think Python is a bit better. (Though, unlike you, my programming skills are directly tied to my livelihood, so it benefits me if one language can cover as much ground as possible. Being locked into a specific domain just narrows the number of jobs I can take on.) You're not wrong, but it makes me pretty sad that all my homepage submissions are marked as 'showdead' and no one ever sees them. Maybe my submissions would look like rubbish by your standards. But looking at it that way, there's also the gap between what people expect and what the site's filters decide.

Re: Too many R packages: CRAN is inundated with submissions

#32
post #14

R slop. Oof. What an awful thing to imagine. It's already the programming language of choice for egregious abuses of good practice.

I do wonder if there isn't enough computer science / software engineering that is being taught as part of data science. People I've worked with that used R and manged data / did analysis didn't really seem too concerned with long term maintenance. Secondary observation, these same people were the first to preach for the AI coding gospel.

At my job I switch between writing analysis code for research projects and writing code for apps. The difference in mindset is so dramatic. In the same way that good software has consistent names and interfaces that are ~useless when you just need the code to run once, research code has its own requirements that are ~useless in software. It's honestly a big challenge to switch back and forth. So I think it just reflects the main skillset of the people who use it (caring is not enough).

Re: Too many R packages: CRAN is inundated with submissions

#34
CRAN is not a conventional package repo. Its audience is not really people who care about programming or software. It is a means to an end for them and slop is perfectly fine. The language itself is also very simple and has defaults that people don't even bother changing. For example the default output file name. It doesn't ask for an output file name when you save output.

As a result of the above, it is full of packages that come with associated datasets right in the package itself. Packages with a tiny script and gigabytes of data. Or perhaps just the data without any actual code.

Very weird universe.

Re: Too many R packages: CRAN is inundated with submissions

#35
post #34

CRAN is not a conventional package repo. Its audience is not really people who care about programming or software. It is a means to an end for them and slop is perfectly fine. The language itself is also very simple and has defaults that people don't even bother changing. For example the default output file name. It doesn't ask for an output file name when you save output. As a result of the above, it is full of pack…

OK you are right but that is selective for an "overview". The attention to documentation has always been outstanding for substantial packages. The culture is to make many repetitive steps into one liner "magic" that sometimes is very very useful; lastly, the completeness of advanced statistical methods in standard libraries is real. ps- I do not like the R language at all myself, but to be fair there are reasons it is widely used in higher ed.

Re: Too many R packages: CRAN is inundated with submissions

#36

I feel like CRAN should be used for packages that are expressly made for others to use, and with effort put in to the documentation and vignettes. If you’re making a package for a small team or aren’t pushing it to a large audience then just keep it on a GitHub repository. It is almost as easy to install from GitHub with devtools as it is to install.packages().

Exactly. I made a small package for my lab and just put it on GitHub. My guess is that many academics don't know that you can install packages from other sources than cran

Re: Too many R packages: CRAN is inundated with submissions

#37
post #26

Earlier quoted context omitted.

I couldn’t disagree more. The base packages are a complete mess. If R was subset to only the tidyverse 5 years ago then it wouldn’t have lost so much ground to Python in nearly all fields. Posit is obviously the only organization with the pull to do that, and I feel like they got pulled in 10 directions during the move to AI and trying to also support Python. R Shiny is dead too which sucks because reflex.dev just co…

The proof is in the pudding. Every single grad student of mine that was brought up on the tidyverse produces gigantic R markdown files with 20 imports to accomplish something that would be shorter and much much easier to understand (and review!) with a base package or with one of a small number of packages (box, data.table) designed by people who understand programming. Not to mention the ridiculous styling/formattin…

> The proof is in the pudding. Every single grad student of mine that was brought up on the tidyverse produces gigantic R markdown files with 20 imports to accomplish something that would be shorter and much much easier to understand (and review!) with a base package or with one of a small number of packages (box, data.table) designed by people who understand programming.

The fact that young people are producing sub-optimal code (in terms of whatever optimization criteria you are choosing--here, it sounds like terseness) is not strong evidence that a particular software ecosystem (tidyverse) is flawed. Young people producing bad code is not surprising. They're your grad students, mentor them, and maybe they'll adapt to your ways of thinking. Or not.

> One of the reasons R has lost ground to other languages recently is that most R code these days is ugly

Citation needed, surely. The fact that this article is about an increase in the number of CRAN submissions and pseudo-quantitative indices like the TIOBE index show R's slice of the pie is growing provides evidence to the contrary.

Re: Too many R packages: CRAN is inundated with submissions

#38
post #34

CRAN is not a conventional package repo. Its audience is not really people who care about programming or software. It is a means to an end for them and slop is perfectly fine. The language itself is also very simple and has defaults that people don't even bother changing. For example the default output file name. It doesn't ask for an output file name when you save output. As a result of the above, it is full of pack…

CRAN is a weird universe, but not (just) for the reasons you mention. CRAN is still heavily human maintained which means that there's a high chance that an actual human will look at your packages (at least for your first package). This imposes a considerably higher barrier to entry than most package repos, and hence I suspect CRAN actually has a considerably lower percentage of slop.

Re: Too many R packages: CRAN is inundated with submissions

#40

The surprising thing to me is that it's taken as long as it has for CRAN to have this problem. As others have said, this is happening everywhere.

CRAN has very different social structures and culture than other languages' package repos. CRAN _will_ pull your package from the repository if you fail to play nice with all packages, for example. This is evidently controversial, but it's accepted practice and one possible explanation for why CRAN feels more cohesive than NPM or PyPI.
Post reply on HN