Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Groundhog: Addressing the Threat That R Poses to Reproducible Research

datacolada.org

Post reply on HN
Print view View original

101–110 of 124 posts

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#101

Post by epistasis »

roel_v wrote: post #59
mattmanser wrote: post #48

Earlier quoted context omitted.

It doesn't even seem to be on GitHub, in fact the source doesn't seem to be listed anywhere on the project website. Which in our world would scream 'complete amateur, avoid, avoid, avoid', but perhaps it's different in the R world.

While this specific project does have a github page, the R world is 'complete amateur, avoid avoid avoid'. It's not really a 'programming language' in the way software engineers would see it. It's more a loose collection of stats functionality that is tied together with text interfactes in a way that somewhat looks like programming to the uninitiated. I mean, batch scripting is technically 'programming', and Excel (e…

> you can't do real software engineering

This is completely, 100%, absolutely wrong.

Of course you can. There's packages, with excellent software engineering structure, that are designed to include documentation and tests.

R has so much good software engineering, that clever people with no software engineering background can easily make their own packages!

And come on, the R language is a masterpiece. It's not cobbled together like JavaScript or bash. It's got impeccable functional programming language pedigree, you can even look at the AST directly of a function directly inside code.

I'm not sure how you came to any of your conclusions, other than not bothering to understand the language to start. It's a beautiful language with a messy, user contributed set of stats code.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#102

Post by kumarsw »

st1x7 wrote: post #33

Either I'm misunderstanding or this is a non-problem. You can specify older versions of a package when you install it. You can also manage them with packrat. As long as researchers share their language and package versions, you can fully reproduce their environment. (And the base language is really stable, almost to a fault.) This is just a bad way for the author to promote their own library for dealing with this. Th…

The impression I get is that this tool has a forensic bent to it. You ask for the code for a paper and Joe grad student with no programming knowledge emails you a zipped folder of R scripts. He just finished his dissertation, is starting a new job somewhere on the west coast, and no longer has access to the computer in his old advisor's lab where he did the work. The implementation may (or may not be) be lousy, but the use case sounds plenty valid.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#103

Post by mslip »

st1x7 wrote: post #33

Either I'm misunderstanding or this is a non-problem. You can specify older versions of a package when you install it. You can also manage them with packrat. As long as researchers share their language and package versions, you can fully reproduce their environment. (And the base language is really stable, almost to a fault.) This is just a bad way for the author to promote their own library for dealing with this. Th…

Not really relevant but just to note packrat had been soft-deprecated and is superseded by renv, which comes standard with rstudio.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#104

Post by mslip »

_Wintermute wrote: post #80
st1x7 wrote: post #33

Either I'm misunderstanding or this is a non-problem. You can specify older versions of a package when you install it. You can also manage them with packrat. As long as researchers share their language and package versions, you can fully reproduce their environment. (And the base language is really stable, almost to a fault.) This is just a bad way for the author to promote their own library for dealing with this. Th…

Correct me if I'm wrong but specifying an older package version in R still pulls the newest packages from CRAN for any dependencies, which is quick way to run into a load of incompatibilities. I've not tried renv yet but packrat was a pretty poor solution.

You can specify version numbers in renv, you take snapshots of your dependencies into a lock file and can always restore from there or make a new snapshot.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#105

Post by mslip »

samch93 wrote: post #47

Can recommend the paper "A Reproducible Data Analysis Workflow with R Markdown, Git, Make, and Docker" by Peikert and Brandmaier [1], which shows a much more robust approach to reproducibility. [1] https://psyarxiv.com/8xzqy/

Thanks!

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#106

Post by dracodoc »

Title aside, the purposed solution just

- use Microsoft MRAN which did the heavy lifting of hosting archives

- use date instead of version

- install package automatically in first time (which pacman::p_load has been doing for ages) and easier to use in script level.

It's not coincidence that most package manager solutions used version instead of date to control the environment:

- A paper published on 2017 may used a date in 2017.10.01, but there is a high possibility that some of the dependency packages might be of earlier date, unless the author update packages every day/week, which is not a good habit anyway because updating too frequently will break things more frequently.

- Then how can you reproduce the environment using a date? The underlying assumption that all packages will be latest till that date simply doesn't hold.

That's why packrat/renv etc will use a lock file to record all package versions, and why you will need a project to manage libraries, because you will need to maintain different library environments and cannot install to same location.

Yet the author take installing all packages to a single location as a feature since you don't need to install same package again, and try to avoid project and prefer script as much as possible when doing reproducible research?

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#107

Post by SoSoRoCoCo »

> The problem is that packages are constantly being updated, and sometimes those updates are not backwards compatible.

Uh oh, someone just discovered the modern programming landscape!

Python, Node, R, Rust, and other langs/OSes with package managers are at the mercy of volunteers who keep important packages healthy. Once issues stop being fixed, y'all better have local copies. This used to be predominantly an OS issue, now it is a language issue, too.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#108

Post by swsieber »

SoSoRoCoCo wrote: post #107

> The problem is that packages are constantly being updated, and sometimes those updates are not backwards compatible. Uh oh, someone just discovered the modern programming landscape! Python, Node, R, Rust, and other langs/OSes with package managers are at the mercy of volunteers who keep important packages healthy. Once issues stop being fixed, y'all better have local copies. This used to be predominantly an OS issu…

> The problem is that packages are constantly being updated, and sometimes those updates are not backwards compatible.

> Python, Node, R, Rust,

Correct me if I'm wrong, but for binary programs, a lock file easily mitigates these issue. I know Node and Rust both support lock files.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#109

Post by jcheng »

_Wintermute wrote: post #80
st1x7 wrote: post #33

Either I'm misunderstanding or this is a non-problem. You can specify older versions of a package when you install it. You can also manage them with packrat. As long as researchers share their language and package versions, you can fully reproduce their environment. (And the base language is really stable, almost to a fault.) This is just a bad way for the author to promote their own library for dealing with this. Th…

Correct me if I'm wrong but specifying an older package version in R still pulls the newest packages from CRAN for any dependencies, which is quick way to run into a load of incompatibilities. I've not tried renv yet but packrat was a pretty poor solution.

If you need to use an older version of a package and don’t have a packrat/renv lockfile already, then packrat/renv are not going to help you. mran/checkpoint could though.

I agree packrat (which I created) was a poor solution for most users. renv is far better and more usable.

Re: Groundhog: Addressing the Threat That R Poses to Reproducible Research

#110

Post by mespe »

While I agree with many of the negative comments here about issues with how this is implemented, the tone of some comments is... not great. To the point that I would be reluctant to share work I do in R on Hacker News, which is not helping anyone.

Just a reminder: https://news.ycombinator.com/newsguidelines.html

Post reply on HN