Don't remember the source and probably misquoting, but I like this truism: there's software that people complain about and software that nobody is using.
The original quote is from Bjarne Stroustrup, the creator of C++. The quote also doesn't apply here. (You can't just use it to excuse any problem with software that you come across). The author of the article and the library in it just seems out of their depth in many ways.
> there's software that people complain about and software that nobody is using.
> The original quote is from Bjarne Stroustrup, the creator of C++
i find this ironic, given the 'popularity' (either way) of C++
The original quote is from Bjarne Stroustrup, the creator of C++. The quote also doesn't apply here. (You can't just use it to excuse any problem with software that you come across). The author of the article and the library in it just seems out of their depth in many ways.
> there's software that people complain about and software that nobody is using. > The original quote is from Bjarne Stroustrup, the creator of C++ i find this ironic, given the 'popularity' (either way) of C++
I don't think it's ironic, the quote directly addresses the many criticisms towards C++.
This title is an exceedingly hot take for someone who wrote a new package manager. Also, it appears that Groundhog is itself a CRAN package and the author recommends installing with install.packages(). So is the author committing to never making any backwards incompatible updates to their new package?
Your take seems a bit 'hot' too? How else would you install the cran packages without using install.packages? Unless if you want them to recursively install it using groundhog but that seems unnecessary. As long as you have the timestamp it should work, though I assume there will be some edge case. What you're saying is like don't use pip because you don't install it using pip? Or don't use package-lock.json because…
> Your take seems a bit 'hot' too?
OP is not claiming that Groundhog itself is a threat to the R language ecosystem itself, whereas the author is claiming that the R language is itself a threat to Science itself...
Apart from all the other considerations and problems with various types of package management, consider this: "Update January 6th, 2021 A reader alerted me to a bug with the current groundhog (version 1.1.0) where you cannot set the groundhog library to be a folder containing spaces in the name." So we are talking about software here that somehow made it to version 1.1 *without anyone ever using a directory with spac…
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.
Apart from all the other considerations and problems with various types of package management, consider this: "Update January 6th, 2021 A reader alerted me to a bug with the current groundhog (version 1.1.0) where you cannot set the groundhog library to be a folder containing spaces in the name." So we are talking about software here that somehow made it to version 1.1 *without anyone ever using a directory with spac…
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.
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.
No, I think you’re correct. Incomplete source is bad in any world. Unfortunately, it’s that world we live in for pretty much everything. Reproducibility? What if all of the source were to depend on part of a CPU instruction set that we stop using? How long must things be reproducible? We don’t even make lab equipment exactly like we used to with the experiments our current sciences are based on. However, I give a thu…
Reproducibility down to CPU bit differences is a sign that you did something wrong. Usually calculation with insufficient precision and no thought given to the range of simulation error. Simulation must be treated like a measurement, there is a maximum precision for your instrument and you have to know and apply it.
And even if you might disagree for the single-threaded case, most things running in parallel will eat that free lunch of bit-identical results due to timing differences.
I’ve yet to use it personally, but renv [1] seems to try to solve the reproducible builds problem in a way more similar to other modern package managers (e.g. by generating a lockfile). This approach enables stricter validations against tampering with the package repositories as a hash of the package can be stored in the lockfile, however it is obviously a bit more complex to use than the groundhog approach. [1]: htt…
I came here to say this.
This seems like a non-issue given renv. And renv gives a more reproducible, I think, solution as it pins to versions, not dates.
Apart from all the other considerations and problems with various types of package management, consider this: "Update January 6th, 2021 A reader alerted me to a bug with the current groundhog (version 1.1.0) where you cannot set the groundhog library to be a folder containing spaces in the name." So we are talking about software here that somehow made it to version 1.1 *without anyone ever using a directory with spac…
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 (even without VBA) is technically Turing complete, but neither of those would be considered 'programming' by software engineers, at least not under an intuitive understanding of what 'programming' is. (by that I mean, it's easy to be pedantic and argue that R and batch files and Excel files are 'programming' because of [xyz] where [xyz] will probably involve real 'definitions' and selection criteria etc; but despite those tools being useful, you can't do real software engineering in them, which you sometimes want/need).
Apart from all the other considerations and problems with various types of package management, consider this: "Update January 6th, 2021 A reader alerted me to a bug with the current groundhog (version 1.1.0) where you cannot set the groundhog library to be a folder containing spaces in the name." So we are talking about software here that somehow made it to version 1.1 *without anyone ever using a directory with spac…
Could also be that the package manager doesn't use spaces and most people use package managers? Ie maven will create a folder structure like "/home/user/.m2/repository/com/example/example.jar" which will never have spaces unless the username has spaces (Can linux usernames have spaces?).
No, the R package manager can tolerate spaces in filenames.