4 ms·
For ad-hoc data science work R is always the first (and last) tool I reach for. It's just so fast and reliable to develop in, and with tidyverse, such a joy!! W
by nomilk 5y ago
For ad-hoc data science work R is always the first (and last) tool I reach for. It's just so fast and reliable to develop in, and with tidyverse, such a joy!! When working on python projects, I've seen very experienced python people (gold for the python tag on stack overflow) get stuck on some frustrating and mundane dependency installation issue and spend an entire day with attempt after attempt to install and get on with their analysis.
By contrast, R has the occasional but rare installation issue, and almost all the common ones are solvable in a few minutes with a re-install.
I think for large software projects where dependencies could be an issue, especially long term, R might not be the best choice.. for now anyway.
I feel some of your pain on the tidyverse front, but for that reason I stick mostly with fairly common functions and avoid exotic new ones. Even if I do venture into new ones, I comment them so I know precisely what's going on so in the event of a refactor a few years' down the track I'll be fairly safe. With R there's usually 10 ways to do the same thing, so you're never completely stuck, you'll just get an error which typically has some sensible way to handle.
To spin a positive light on the deprecations, most are replaced with something nicer, so although you have the pain of updating old code, it forces you to be aware of the new approach, which is a silver lining of sorts.
- adeelk93 5y agoR is my go-to for ad-hoc data science as well. And you’re right, deprecations are generally replaced with something nicer. From the perspective of a language used for ad-hoc analysis, these are all great features. Hadn’t thought of it that way. Which further emphasizes the idea of: R might not be the right tool for production processes. I used to fight that concept, but in the past year or so I’ve come to embrace it.
- 555watch 5y agoIt's not that difficult to fix package versions for any prod deployment, as long as you deploy the projects as R packages. You can fix the versions in the ``DESCRIPTION`` files, which are easy to manage through, e.g., Docker and ``devtools::install_version``. Essentially, not a huge difference from ``requirements.txt`` that we're used to.
- adeelk93 5y agoDESCRIPTION files don't actually solve this problem - if you're trying to peg a package version, and it inevitably ends up an outdated version in the future, you'll be greeted with that error "Package 'xxx' is not available". Why? That version has been archived. I'm sure you've run into this error at some point. devtools I guess is a solution (write some code to iterate over package requirements), but let me ask you this - how do you protect against breaking changes in devtools? I have yet to encounter something more reliable than MRAN snapshots https://mran.microsoft.com/documents/rro/reproducibility https://mran.microsoft.com/documents/rro/reproducibility