Dear R community, I have been using R for over 15 years. I want to raise an issue which has been haunting me for some time now: It feels as if R is falling apart. I try to justify this feeling by providing three discussion points: 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). 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. 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. 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. 3. R seems to be developing into different dialects. You have dplyr and tidyr, some people prefer data frames, some prefer tibbles. Some people use pipes, some use traditional syntax. Some prefer object-oriented programs, some prefer procedural scripts. 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. Of course, Matlab is a commerical product, but R used to be the same way. I don't know if many other people feel the same way, but I think I am shifting away from R. yours best,a data analyst dude [[alternative HTML version deleted]]
Would you prefer that R be static? If you don't like the dependency hell of certain packages, then perhaps those packages are not appropriate for you. You always have the option to create your own packages... and in nearly all cases the licenses of contributed packages allow you to re-formulate their code into your own packages. Do be clear... contributed packages are not "R". R Core bears no responsibility for the decisions made by package developers in making progress on those packages. I am curious what you are drifting _toward_... Python has had some dramatic changes in syntax over time... so much so that using Python without a version-pinned virtual environment is hardly possible. You have support for that approach in R also. I suspect that any open scripting tool will have similar problems... if one tool doesn't have that problem now, it will later. On June 13, 2025 7:49:37 AM EDT, Small Investor via R-help <r-help at r-project.org> wrote:>Dear R community, >I have been using R for over 15 years. I want to raise an issue which has been haunting me for some time now: It feels as if R is falling apart. I try to justify this feeling by providing three discussion points: >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). 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. >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. 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. >3. R seems to be developing into different dialects. You have dplyr and tidyr, some people prefer data frames, some prefer tibbles. Some people use pipes, some use traditional syntax. Some prefer object-oriented programs, some prefer procedural scripts. 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. Of course, Matlab is a commerical product, but R used to be the same way. I don't know if many other people feel the same way, but I think I am shifting away from R. >yours best,a data analyst dude > > [[alternative HTML version deleted]] > >______________________________________________ >R-help at 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.-- Sent from my phone. Please excuse my brevity.
I would add to what Jeff replied. Many and perhaps most or even all languages that have room for evolution, including Python, can end up getting more and more complex with multiple ways to do things but it generally is possible to write many useful programs in the core language. I often wonder what would happen if someone took a language that was decades old, and examined a recent version and used the results to create a new streamlined language in which many choices are simply removed and some newer ones are used instead. Consider the endless number of ways you can now do formatted printing in python including various versions of strings. In R, some of the ideas have been made available in the glue package in the tidyverse which many people do not know about and others use instead of much of what is available in basic R. I think having choices is great for programmers but as noted, makes it harder when hiring people to see if they fit. But, IMNSHO, any programmer you hire that is not able to rapidly get on board and read manual pages or sections of books showing how to use features, may not be the best hire. I know I have been hired in situations where my experience was of different operating systems, programming languages and editors/environments and switching was not hard because I had a flexible background. Over years, we kept shifting and I kept up while some others who knew ONE THING were often struggling. The reality is that R was written so long ago that it would rapidly have been less and less attractive to some programmers if it stood still. Some of the concerns mentioned are reasonable and some have solutions such as taking a snapshot of what versions of things you allow to be used that form a stable environment and then not updating anything. A new machine would download just the copies needed, as long as the version remained archived. But is R as bad as Python which split in ways that made many 2.x programs incompatible with 3.x and yet some people continue to use the old version, which is a bit souped up to emulate, rather than changing the code to be compatible? Nobody forces you to use dplyr and frankly, it has similar issues as the tidyverse once built has been changed often enough so my older programs often tell me functionality has been, or will soon be, made obsolete and the newer stuff may be much more powerful and yet a pain to use for simple things as they allow ever more abstractions. I will say that it may happen to R too and a new language named P may be offered alongside R that will become more difficult within a year. But had this happened, R would not have things like a built-in pipe that some find useful or even essential. -----Original Message----- From: R-help <r-help-bounces at r-project.org> On Behalf Of Small Investor via R-help Sent: Friday, June 13, 2025 7:50 AM To: r-help at r-project.org Subject: [R] Some general comments Dear R community, I have been using R for over 15 years. I want to raise an issue which has been haunting me for some time now: It feels as if R is falling apart. I try to justify this feeling by providing three discussion points: 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). 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. 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. 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. 3. R seems to be developing into different dialects. You have dplyr and tidyr, some people prefer data frames, some prefer tibbles. Some people use pipes, some use traditional syntax. Some prefer object-oriented programs, some prefer procedural scripts. 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. Of course, Matlab is a commerical product, but R used to be the same way. I don't know if many other people feel the same way, but I think I am shifting away from R. yours best,a data analyst dude [[alternative HTML version deleted]] ______________________________________________ R-help at 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.
Dear data analyst (or small investor?), ? Fri, 13 Jun 2025 11:49:37 +0000 (UTC) Small Investor via R-help <r-help at 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