R包过多:CRAN提交量泛滥
摘要
R Works 的一篇文章探讨了CRAN新包数量的快速增长,质疑其中许多包缺乏文档,对R社区也没有实质性贡献。
暂无内容
查看缓存全文
缓存时间: 2026/06/24 13:51
# 新CRAN包:信号还是噪声? – R Works
来源:https://rworks.dev/posts/too-many-R-packages
CRAN 依然是地球上最易获取的统计知识库,而新包被 CRAN 接受的速度正以前所未有的速度增长。但 R 社区真的从这种增长中受益了吗?
如果你在 R-bloggers(https://www.r-bloggers.com/)上阅读这篇文章,你大概知道,我一直在定期发布我挑选的“Top 40”CRAN 新包。最初,这属于我在 Revolution Analytics 工作的一部分,后来在 R Views(https://rviews.rstudio.com/)上为 RStudio 和 Posit 做这件事,而现在则是在 R Works。过去,挑选四十个有趣的包大概需要一个月里分散开的一整天愉快的工作。面对一百来个包,我可以浏览所有包的网页,下载并试用其中少数几个。现在,“Top 40”变成了一个真正的“仓鼠跑轮”项目。下图展示了自从我在 R Works 发布以来,每月成功进入 CRAN 的新包数量。
显示绘图代码
```
library(tidyverse)
file_path <- "new-cran-pkgs.csv"
if (!file.exists(file_path)) {
stop(paste("File not found! Please check the path:", file_path))
}
# Read text and numbers safely
raw_data <- read.csv(file_path, colClasses = c("character", "numeric"), stringsAsFactors = FALSE)
plot_data <- raw_data |> mutate(Date = my(Month)) |>
arrange(Date)
new_pkg <- ggplot(plot_data, aes(x = Date, y = Num_pkgs, group = 1)) +
geom_line(color = "#1f77b4", size = 1) +
geom_point(color = "#d62728", size = 1.2) +
labs(
title = "Monthly Volume of New CRAN Packages",
x = "Date",
y = "Number of Packages",
caption = "Source: R Works monthly Top 40 posts"
) +
theme(
plot.title = element_text(face = "bold"),
panel.grid.minor = element_blank(),
axis.text.x = element_text(angle = 45, hjust = 1)
)
new_pkg
```
[](https://rworks.dev/posts/index_files/figure-html/unnamed-chunk-1-1.png)
为什么出现急剧增长?可能发生了什么?好吧,我有个猜测。显然,现在把代码打包并提交到 CRAN 太容易了。这可以理解:编写和部署任何类型的软件都太容易了。下图是 John Burn-Murdoch 最近在《金融时报》(https://www.ft.com/stream/e191658e-c66a-45bc-9bad-343bdc4210b3)上发布的,基于 NBER 研究(https://www.nber.org/papers/w35275)的数据,展示了我们处于 Agentic AI 时代下应用的爆炸式增长。
随时间推移的应用发布量(https://rworks.dev/posts/API.png)
该图也表明,这些新应用对人们的生活或企业利润的积极贡献不大。它们似乎没有被使用、被评价,甚至没有被发现。
那么,让我们对新 R 包也提出同样的问题。它们中的大多数真的在为 R 和 R 社区做出贡献吗?它们是否贡献了新的统计方法,将 R 的应用范围扩展到新的领域,提供了高效的高性能代码,或者做了其他显然有益于 R 社区的事情?
作为一个涉猎广泛的爱好者,我的印象是:不,大多数新 R 包并没有作出贡献。文档质量是一个明显的指标。大量新 R 包没有提供足够的文档来解释它们提供什么。例如,在 5 月份,323 个新 CRAN 包中有 40 个没有 README 文件、没有 vignettes,也没有指向仓库的 URL。在我看来,除了那些存在某种可发现的带外文档(例如期刊出版物)的包,或者那些不是面向最终用户调用(而是作为某个包套件的基础设施)的包,那些不描述它们是什么、为什么以及如何工作的包,都不能算作贡献。
作为一只在跑轮上的仓鼠,我非常乐意听听您的看法。如果您有兴趣,请在 R Works GitHub 仓库的 Issue #68(https://github.com/r-community-works/rworks-website/issues/68)上留言。
相似文章
FT:AI编程热潮令开源维护者不堪重负
《金融时报》报道称,AI编程热潮正用低质量的AI生成贡献淹没开源维护者,消耗着整个生态系统。具体证据包括cURL关闭其漏洞奖励计划、Ghostty禁止AI代码、tldraw自动关闭PR,以及研究表明贡献者参与度下降。
别再给我发超大PR了;一篇吐槽
这篇吐槽批评了软件开发中流行的大型AI生成的拉取请求趋势,提倡使用更小、易于审查的改动来提升代码质量和审查者的体验。
请停止用AI生成的低质量内容充斥我们的项目,只为充实你的简历
开源项目维护者正面临大量AI生成的贡献涌入,这些人利用AI工具提升其GitHub个人资料以求就业,这引发了关于这些提交的质量与意图的问题。
寻求帮助
一篇讽刺性的开源维护者抱怨,针对自以为是的用户、AI生成的拉取请求,以及被迫采纳流行但不健康的开发实践。
市场正被无人想要的软件淹没
讨论AI智能体如何实现快速应用创建,但产生缺乏开发者理解的陌生代码库,导致应用泛滥但用户吸引力极小。