undefined

points

[-]

> For example the default output file name. It doesn't ask for an output file name when you save output.

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).

by dizhn1 hours ago|

parent|

[-]

I can't find the script now but I am talking about text output to a file. Perhaps people were normally running the script in a Jupiter like env and that's why they didn't bother with file names and it created a file with a default name when I ran it to test the interpreter.

by hadley6 hours ago|

prev|

[-]

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.

by tylermw5 hours ago|

parent|

[-]

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.

by nxobject5 hours ago|

parent|

[-]

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

by tylermw4 hours ago|

parent|

[-]

Yep, as someone who both uses lots of R packages and writes lots of R packages (which, in turn, import other R packages), I've grown to appreciate the strictness of CRAN: if a package is on the CRAN, I'm just about guaranteed to not have installation issues or have it screw up my environment. To me, that's the one major job of a package repository, and CRAN does it well, even if it does cause package authors pain at times :)

by gnerd006 hours ago|

prev|

[-]

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.

by nxobject5 hours ago|

parent|

[-]

> 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.)

– 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.

by hadley4 hours ago|

parent|

[-]

You can learn about the theory that underlies tidyeval at https://adv-r.hadley.nz/quasiquotation.html. I'd claim that it's neither reinventing the wheel (because it solves problems that the base equivalents do not) nor bizarre (because it is backed by a deep, well-founded theory).

by dizhn5 hours ago|

parent|

prev|

[-]

I only dipped into it a little bit while helping out a friend. It looked weird to me but I didn't mean to sound so negative. Sorry. I am sure it does get the job done or people wouldn't be using neither R nor the CRAN.