• 新鲜事R语言
  • 诚邀广大R语言、数据可视化爱好者和我们一起搬迁升级谢益辉著作《现代统计图形》

Cloud2016 如果是曾国藩来写这个函数,恐怕会是这种天然呆风格:

ruler <- function(width = getOption("width")) {
  x <- seq_len(width)
  y <- rep('-', width)
  y[x %% 5 == 0] <- '+'
  y[x %% 10 == 0] <- seq_len(width %/% 10) %% 10
  cat(y, "\n", sep = "")
  cat(x %% 10, "\n", sep = "")
}
ruler()

你用 ifelse() 当然也是极好的。此处用 dplyr::case_when() 在我看来就属于杀鸡用牛刀了,用一个笨重的依赖完成了一个细枝末节的任务,我觉得不值当。

净土宗在包的依赖问题方面确实是有不少问题,它的那些不靠谱的反对党还煞有介事地搞了个踢馆的网站名曰 Tinyverse:http://www.tinyverse.org 但基本上都是说了些废话(谁还不知道引入依赖的坏处?)、给自己的个人网站打广告(独孤求赞)、以及展示他们自己的确认偏误(看!Tidyverse 又搞砸了吧)。这个问题不能一概而论,不同人的平衡点不一样:你是选择臃肿而方便,还是选择轻量而麻烦?就以上的 ruler() 函数而言,引入 dplyr 当然是毫无必要;但如果在一个项目中大量使用了 dplyr 包中的其它主打函数,那么顺手用一下 case_when() 也无妨。就是看引入依赖的动机和目的是什么了。我一般倾向于用基础 R 函数,如果有什么杂项任务需要完成,我就写个零依赖的函数丢到 xfun 包中,当然偶尔也需要用到依赖,但 xfun 包本身没有硬性依赖,依赖按需安装就好了。ruler() 这种函数就适合放在这般乌合之众的包中。

    yihui
    看你的代码之后我也用了不少xfun里的函数

    @yihui 谢大在这里提到曾国藩,我乍一看不明白其中逻辑!搜罗一番才知道他有个特点:结硬寨、打呆仗!吸引我去搜罗的另一个原因是我以前看过《走向共和》这部剧,里面多次提到李鸿章的老师曾国藩,同治中兴的重要人物!这部剧我觉得是对李鸿章一个富有立体感的呈现,非常推荐!以前有人推荐我看《曾文正公》文集,说里面还有很多为人处世的东西,今天搜罗一番后,我觉得我应该弄来好好看看!

    回到正题,我其实没想那么多,引起 tidyverse or not 的讨论?tidyverse 本身是好的,它的一致性胜过一切,在《现代统计图形》这本书所有内容都完备的时候,我会再清理一遍代码,看一些地方是不是值得用,或者是不是某一章可以全部转化为 tidyverse 风格,但是最后应该不是随处散落 tidyverse 的代码

    至于宣传方面,《Tidyverse design principles》<https://principles.tidyverse.org/> 《Tidyverse 设计原理》的风格就是举例子说明 Base R 哪个地方不好,所以我要造一个新的东西!这本身就是一个强大的宣传攻势,新事物诞生往往也是靠这个路子,这个风有点猛,一些 R 前辈老人可能受不住!两边能融合该多好,不要去学习两个新的东西,让 R 来一次壮士断腕,奔向一个 4.0 or 5.0 时代,像 Python2 走向 Python3 那样?

      Cloud2016
      别了别了,python闹得我不得不建两个conda的环境,用不同软件的时候还得来回切换,很烦啊w

      Cloud2016 你可能没仔细看我说的 Tinyverse 的拼写,是 Tiny,不是 Tidy。我说的宣传是反对党在自己宣传自己。

      结硬寨、打呆仗正是我的意思。用中括号下标索引就是这种风格,一步一结寨、一步一呆仗,每行代码不多不少只做一件事,毫无技巧可言。

        7 天 后
        22 天 后

        @yihui @dapengde @所有关心和帮助本书变得更好的朋友们

        我已经想好了,仗着自己对书籍的控制,凡是净土代码一律替换或注释掉(最终也要替换掉),凡是提交含有净土代码的 PR 一律不合并!

          举个栗子

          library(tidyverse)
          death_tidy <- death %>%
            as.data.frame() %>%
            rownames_to_column(var = "population_group") %>%
            pivot_longer(cols = -population_group, names_to = "age", values_to = "count") %>%
            mutate(
              age = fct_inorder(factor(age)),
              population_group = factor(
                population_group,
                levels = c("Rural Male", "Rural Female", "Urban Male", "Urban Female")
              )
            )

          会被替换为

          reshape_VADeaths <- transform(
            expand.grid(
              sex = colnames(VADeaths),
              age = rownames(VADeaths)
            ),
            rates = as.vector(t(VADeaths))
          )

          本人水平有限,一方面看不懂净土代码,另一方面也很是怀疑其稳定性,为了后续维护计,我放弃了书籍中所有净土代码,一律会被替换掉,类似上面的例子。

          Cloud2016 上帝的归上帝,凯撒的归凯撒。

          此前我提议过三步走,以现有版本里的“道”为芭比娃娃的“体”,保持其稳定性,然后换不同的衣服(“用”),各自独立维护,也许比较可行。

            dapengde 那新开一个分支就好了,很简单,不同的娃娃在不同的分支上,我主要负责 master 分支的维护,你来负责各条线上的芭比娃娃?

              把 tidyverse 相关的代码替换掉以后,又可以运行了 😂 😂

                Cloud2016

                你链那篇谭显英的博客提到的mutate_at 的问题我也碰到过,一年前写的dplyr相关代码一编译出错, 结果发现语法变了。

                感觉向后兼容性真是开发过程里很重要的问题。前几天看了python2/3 为什么分家的博客,大概就是引入了不向后兼容的变化(比如print加括号),现在说是2020年py2不再维护寿终正寝,但library下载统计显示40%的下载量依然基于2.7。python2/3生生把社区割裂开我觉得算是软件史上因为引入不兼容改变走过的最长弯路了😂

                但是一昧向后兼容也会导致积重难返,很多东西明知有更好的做法但为了不破坏下游的依赖也只能将”错”就”错”,比如r里stringasfactor=TRUE, R选项默认保存当前工作环境的image等等…

                总之我很同意谭那篇博客里提的“不要在生产环境里用净土宗”,好多基础性的语法都在变来变去的话,在我看来是跟鼓吹多年的reproducible research背道而驰的。

                  Cloud2016 我恐怕 git 的功力不够,做不到维护一个或多个分支。鉴于眼下只有你老哥一个在折腾,我建议走一步看一步,搁置争议,共同开发吧。

                  tctcab 关于兼容翻车的问题,perl 6 改名叫 Raku 也是个榜样。

                  7 个月 后
                  5 天 后