Dear data analyst (or small investor?), В Fri, 13 Jun 2025 11:49:37 +0000 (UTC) Small Investor via R-help <r-help@r-project.org> пишет:
> 1. Version compatibility issues seem to be on the rise. Very > often, you get the message that package x was built on R version y > (and thus, won't work in your version of R). Is this about the warning that appears when you are running the previous patch version of R and install a new binary from CRAN? I think R had code to signal it since 2002: getRversion() # [1] ‘4.4.0’ library(MASS) # Warning message: # package ‘MASS’ was built under R version 4.4.3 It's not that it won't work: the R developers are very careful not to break any interfaces between patch releases (those that only differ in the "z" component in "R-x.y.z"). But this is a sign you probably need to update to the latest patch release as well and enjoy the bug fixes. > When you update to the latest version of R, you realize that not all > packages are available for that version. It seems that for each > version, only a (non-predictable) subset of packages is available. Let's quantify this. What are the packages that fell of CRAN that you miss and would like to use again? Some of them may be alive and well elsewhere. (R-universe? Private repositories?) Others, well. The first rule of the free software club is that neither the developers, nor the contributors, nor the users owe each other anything (except basic courtesy, and even that is subjective). Despite that, when Dr. Jim Lemon passed away in September 2023, people kept his 'plotrix' package maintained (thanks Duncan Murdoch!). Maybe you can find someone to maintain the packages you need too. > 2. The overhead of installing new packages seems to be on the rise. It > seems that the packages depend on more and more other packages. The > more packages you have in the 'foundations' of package x, the more > likely it is that one of these causes an error and the whole stack > fails. Installing used to be easy back in the day: You got a 20 lines' > output. Now you get endless prints. Deep and/or wide dependency trees are on the rise in programming as a whole, not just R. Modern package managers make it possible to program with dependencies the same way we previously learned to program with loops, functions, and classes. Here's a take on the NodeJS ecosystem: https://sambleckley.com/writing/npm.html And here are a few takes on CRAN: https://journal.r-project.org/articles/RJ-2023-060/ https://aitap.github.io/2020/07/10/cran.html (I think that Lluís Revilla Sancho <https://llrs.dev/> also discussed these problems, but I cannot find a post dedicated to the dependency problems right now.) 15 years ago our dependencies had more stable interfaces and were less numerous by necessity, both because the tools we used to manage the dependencies were blunter, and because the world was less connected, making it harder to install new dependencies or upgrade them at will. Nowadays the assumption of always-on connectivity is easier to make, and the developers are expected to solve compatibility problems with version pinning when they reuse code from other packages: https://utcc.utoronto.ca/~cks/space/blog/programming/BuildSystemsAndAPIChanges (There are downsides to this approach too, such as the security patch problem, but all of this is as old as the static linking vs. dynamic linking debate; don't expect a decisive resolution soon.) Not everyone is happy with this situation either, see <https://www.tinyverse.org/>, but one has to be pragmatic. If a package does what you want but requires a hundred dependencies, it may still save you time and effort to use it, at least in the short run. As for why software can't stay a product instead of becoming a process, I don't know. I'm not sure we can do better as an industry. > I may be mistaken but some packages seem to require admin rights on > your computer which you don't often have on your work PC. Not on Windows or macOS, where statically linked binary packages with dependencies included are already available from CRAN. (Third-party dependencies bundled with the package. Isn't that a nightmare for an IT security department?) > If you put in a job announcement that somebody has to know R, it > doesn't mean the same thing for different people. > If you compare the use experience of R in 2025 to that of Matlab, the > difference is striking: Matlab is concise and clear, R is more and > more about endless prints. Out of the members of the R community, who should be assuming the role of Mathworks and instituting a monoculture? Can the R community even survive being made into a monoculture? "There is more than one way to do it" is much more welcoming than the alternative. Similar things can be observed about Python and C: data science Python is very different from web service Python, and so is numerics C vs. embedded C. While a good Python or C programmer would be capable of contributing to either kind of project, it helps to specify what the job is about to attract specialists. It's not all roses on the other side of the fence, either. Here's Mathworks breaking a long-standing component of Matlab, preventing a multi-thousand-$ product of their customer who themselves brought customers to Mathworks (the product depends on Matlab) from working: https://eigenvector.com/pls_toolbox-and-matlab-2025a/ At least when free software breaks compatibility, you retain the right to run the old version indefinitely, and may hire some other programmer, not necessarily the original developer, to keep it running for you. (Is it cheaper than upgrading in the long run? Probably not.) > I don't know if many other people feel the same way, but I think I am > shifting away from R. Best of luck in your future endeavours! Learning a new programming language (especially if it uses a different paradigm) will make you a better programmer. -- Best regards, Ivan ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
