4 ms·

This looks like a cool project and I look forward to trying it later. General comment: one reason that the R package ecosystem often feels creaky and brittle,

This looks like a cool project and I look forward to trying it later. General comment: one reason that the R package ecosystem often feels creaky and brittle, I think, is that a lot of packages (like this one) are pretty far afield from R’s original intended uses of statistics and visualization. Here, we see the use of integers to denote pitches strung together as a vector to generate a sequence. That’s not precisely a misuse, but it’s definitely misaligned with the original vision, and trying to build things on top of that misaligned infrastructure is a potential vector of packages’ breaking and general irreproducibility.

adeelk93 5y ago
R’s package ecosystem is creaky and brittle even for statistics and visualization. I don’t think “misaligned with the original vision” is really relevant. Like, it has nothing to do with someone making a package to work with music in R. Not sure how any of this is really relevant here. This is a general R gripe.
- malshe 5y ago
  > R’s package ecosystem is creaky and brittle even for statistics and visualization Explain what you mean by this. It’s a big claim without any supporting evidence.
  - adeelk93 5y ago
    Sure, I thought this was a common experience, and I’d love to hear how you get around it. The tidyverse is absolutely full of breaking changes. Two big ones off of the top of my head: dropping underscore functions like mutate_, and turning common column names into new function names. So in different organizations you might see two patterns: * Monolith - everyone uses a set of R packages from 2017 or whatever (frozen in time either through MRAN or Nexus) * Wild dockerization - one team’s internal tooling is incompatible with the other team’s, so working across teams you gotta rely on Docker a lot Why? Cause there’s not really a good way to pin versions besides shrinkwrapping, at least in my experience. We tried Drake, but Drake itself had so many breaking changes that it gained a really bad rep (from what I hear from colleagues, haven’t used it myself). Tried renv but it was destroying some of our analyst’s setups (like, you just get a bomb icon in Rstudio). Didn’t troubleshoot it too much, kinda just gave up. I don’t like forcing a specific vintage of packages, but I like everything else less.
    - malshe 5y ago
      Ok, this is not what I thought you meant. I don't know how anyone can solve this problem in a constantly growing and evolving open-source ecosystem though.
      - adeelk93 5y ago
        Well the very first step would be: native R support for installing specific package versions, and sharing that with others. There’s too many third party solutions that come and go over the years. And there’s no guarantee that what you select today will be understood, or work, tomorrow.
        malshe 5y ago
        There is `renv` for that
        adeelk93 5y ago
        Which is a third party solution. A few years ago you may have said packrat. A few years from now you may say some other thing. The idea behind a native R solution is that it is far less likely to be deprecated.
    - 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 ago

R’s package ecosystem is creaky and brittle even for statistics and visualization. I don’t think “misaligned with the original vision” is really relevant. Like, it has nothing to do with someone making a package to work with music in R. Not sure how any of this is really relevant here. This is a general R gripe.

malshe 5y ago
> R’s package ecosystem is creaky and brittle even for statistics and visualization Explain what you mean by this. It’s a big claim without any supporting evidence.
- adeelk93 5y ago
  Sure, I thought this was a common experience, and I’d love to hear how you get around it. The tidyverse is absolutely full of breaking changes. Two big ones off of the top of my head: dropping underscore functions like mutate_, and turning common column names into new function names. So in different organizations you might see two patterns: * Monolith - everyone uses a set of R packages from 2017 or whatever (frozen in time either through MRAN or Nexus) * Wild dockerization - one team’s internal tooling is incompatible with the other team’s, so working across teams you gotta rely on Docker a lot Why? Cause there’s not really a good way to pin versions besides shrinkwrapping, at least in my experience. We tried Drake, but Drake itself had so many breaking changes that it gained a really bad rep (from what I hear from colleagues, haven’t used it myself). Tried renv but it was destroying some of our analyst’s setups (like, you just get a bomb icon in Rstudio). Didn’t troubleshoot it too much, kinda just gave up. I don’t like forcing a specific vintage of packages, but I like everything else less.
  - malshe 5y ago
    Ok, this is not what I thought you meant. I don't know how anyone can solve this problem in a constantly growing and evolving open-source ecosystem though.
    - adeelk93 5y ago
      Well the very first step would be: native R support for installing specific package versions, and sharing that with others. There’s too many third party solutions that come and go over the years. And there’s no guarantee that what you select today will be understood, or work, tomorrow.
      - malshe 5y ago
        There is `renv` for that
        adeelk93 5y ago
        Which is a third party solution. A few years ago you may have said packrat. A few years from now you may say some other thing. The idea behind a native R solution is that it is far less likely to be deprecated.
  - 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.