Earlier quoted context omitted.
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.
Absolutely correct. CRAN takes down and rejects packages all the time for minor issues and violations of their rules and guidelines. And there are a lot of them: https://cran.r-project.org/doc/manuals/r-release/R-exts.html The fact that there is a human (and one with expertise in R) reviewing each incoming package makes pure vibe coded slop much, much harder to get approved.
Too many R packages: CRAN is inundated with submissions
51–60 of 85 posts
Re: Too many R packages: CRAN is inundated with submissions
#52CRAN 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 i…
In the same boat... from a PL perspective, yikes (especially the macro mechanism that somehow never seemed to be planned, but somehow exists). As a working statistician? It really does get work done quickly.
To pass inputs with complex unevaluated syntax, I've seen...
– ad-hoc string parsing (lavaan etc.)
– formulas (which somehow the tidyverse doesn't use),
– base R syntax manipulation by round-tripping between as.list and as.call;
– and whatever wheel reinvention with bizarre semantics that the tidyverse uses.
Re: Too many R packages: CRAN is inundated with submissions
#53Earlier quoted context omitted.
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 submissio…
I've got a very Clark Kent kind of a job doing very ordinary work at a university unit which is authoritative in its domain and don't talk a lot about what I do there because the last thing I want to do is have people think my opinions have anything to do with my employer (and the second to last thing I want to do is post statements to that effect!) I code Java and Javascript by day and mostly Python for my side proj…
Re: Too many R packages: CRAN is inundated with submissions
#54Earlier quoted context omitted.
Absolutely correct. CRAN takes down and rejects packages all the time for minor issues and violations of their rules and guidelines. And there are a lot of them: https://cran.r-project.org/doc/manuals/r-release/R-exts.html The fact that there is a human (and one with expertise in R) reviewing each incoming package makes pure vibe coded slop much, much harder to get approved.
Even though I've dealt with this, I'm genuinely appreciative of requirements: out of many stipulations, packages that monkeypatch are prohibited (I have a few ones that add diagnostics to advance analyses), online API access needs robust error handling... and there is a conformance/diagnostic suite. https://cran.r-project.org/web/packages/policies.html
Re: Too many R packages: CRAN is inundated with submissions
#55Frankly the bigger problem is an over reliance among R instructors on the tidyverse, an ever-expanding ecosystem of redundant functions and anti-patterns. They’re teaching new R users that everything can be solved with yet another package import and skipping over teaching them how to use the already powerful and intuitive base packages.
I’m not saying it doesn’t have flaws, but the tidyverse is still the most coherent and functional ML/stat computing ecosystem I’ve ever used. R packages outside of the tidyverse can get pretty gnarly. Even the R stdlib is usually considered to be inconsistent and riddled with legacy cruft.
Re: Too many R packages: CRAN is inundated with submissions
#56Earlier quoted context omitted.
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 i…
> I do not like the R language at all myself, but to be fair there are reasons it is widely used in higher ed. In the same boat... from a PL perspective, yikes (especially the macro mechanism that somehow never seemed to be planned, but somehow exists). As a working statistician? It really does get work done quickly. To pass inputs with complex unevaluated syntax, I've seen... – ad-hoc string parsing (lavaan etc.) –…
Re: Too many R packages: CRAN is inundated with submissions
#57Re: Too many R packages: CRAN is inundated with submissions
#58Earlier quoted context omitted.
A considerable amount of work for grad students is answering the question: "How the f#$% do I get this code to compile and run" Some other researcher, often with limited skills in your native tongue, even more limited skills in software development best practices, wrote some code for a paper between 5 and 50 years ago and your PI has told you to use that code and some OTHER code together at the same time to validate…
The other half is: "What combination of packages and task views do I actually need to not reinvent the wheel for this particular type of analysis?"
Because I have never met a person who is great at that last part (methods theory) and sucks at the others (technical implementation; because the same work and effort leads one to train both). The issue is that AI solves all these problems at once, which will probably result in more academics understanding their methods and choices in preprocessing etc even less. At least this is what I have seen, and seen it getting worse.
I wish the problem was just finding the right packages. Web search, and mentoring/talking to colleagues are pretty good solutions to that. LLMs are more of a gamble here if one use them as an authoritative source, they may suggest the right package, or they may take you on a long trip to nowhere, depending on random factors.
Re: Too many R packages: CRAN is inundated with submissions
#59CRAN 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…
I'm not really sure what output file even means for an interpreted language, but GCC doesn't ask either, it will spit out an a.out by default (not even .elf or something logical).
Re: Too many R packages: CRAN is inundated with submissions
#60Earlier quoted context omitted.
> 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-…
> 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. You’re right, mentorship is key and I do my best to suggest better practices. They are often quite happy to find out they can do more with less and can forget having to remember multiple additional syntaxes (looking at you “ggplot2”). I somewhat understand why R instr…