Cloud2016 啊哈哈，这本”BT擂台赛“原本没打算涉及这么深入的探讨。本来只是想搜集整理一下这里的提问和解答，帮助学习和使用而已，没想到扯到了站队问题。”只有把这个定义好了才有后续的比较“，这个态度严格上来说是对的，然而从实用角度来讲，不是”BT擂台赛“这本书的目的。如果在这一步纠缠不清，那么可能没法往下做了。你看人家 Thanos，一心一意想着打个响指灭掉一半生命，就把事儿给办了，没想着先定义一下什么是生命，人变成灰了可是身上的衣服怎么也灰了，同时体内的细菌病毒寄生虫算怎么回事儿……

不过，既然牵出这个话题，聊一聊也挺有意思的。

网上有不少关于 Base R vs. Tidyverse 的讨论（如这里，这里，这里，这里），我看他们就直接讨论下去了，没见到先定义的，可见，二者应该是有约定俗成的范围的。你猛一看觉得是 Base R 那就是 Base R。就擂台赛来说，如果需要界定一下的话，我觉得可以这样简单界定：

  • B 方案：不需要require()或library()或foo::bar()就能实现的方案。
  • T 方案：需要且仅需要require('tidyverse')而不需要加载其他包就能实现的方案。

这样可能更具有操作性。这也是我为啥没让 data.table 卷入的原因。

我理解的 Base R，就是 R 默认安装包（参考这里）：

  • base
  • compiler
  • datasets
  • graphics
  • grDevices
  • grid
  • methods
  • parallel
  • splines
  • stats
  • stats4
  • tcltk
  • tools
  • translations
  • utils

      dapengde
      既然开始了，那就讨论一下。

      其实我提出在 BT 擂台里加入 data.table，和站队无关，而是因为想起了 @Cloud2016 转发的 Mattlof 的文章。对文中的观点我不全认同，但是认为 data.table 值得拥有更多人知道这点，我无保留地支持。既然 BT 擂台“不是要他们分输赢，而是通过比较来强化我们对他们的理解和消化”，我想，在这个精神的指导下，加入 data.table 于比较的行列是件两全其美的好事：一来丰富了比较的多样性，让各系统的优劣充分展现；二来可以让更多人的了解 data.table 这个有很多优点的包。我觉得在数据整理部分为 data.table 单开一栏并无不可，不必拘泥于比较的对称性，即同时考虑作图和数据整理。不过既然考虑了这点，我想按照 data.table 的设计精神，将其划入 Base R 是自然的。如同建立系统发生树，总有合理的算法将“物种”聚类的。这个提议的初衷和站队无关，如果我觉得 data.table 和极乐净土更接近，也会毫不犹豫地提议将其划入 T 方案。

      定义是重要的，在你举的 Thanos 的例子里，就算默认生命这个概念是自明的，但“一半”如何处理？是一个细菌等价于一个人这样算一半，还是按照体积或重量算的一半？如果现在设计一个函数帮助 Thanos 完成任务，定义的不清楚或许会让程序设计出现问题。你提出了你对 B 和 T 方案的定义，我想这表明你也至少部分认同定义边界是重要的。

      我认同你对 T 方案的定义（考虑到极乐净土在一直囊括新包，不断扩张，其实这定义对 B 方案来说是不公平的；另外，管道这样本来中性的函数为管道所独占也不合理，它本不是专为 T 设计的，不过这些暂且先忽略），但我觉得 B 方案的定义太狭窄。在极乐净土出来之前，大家对 Base R 的理解和现在是很不同的。我想现在大家对 Base R 的理解一般为 “非 Tidyverse”。不过如果按照非 T 来理解 B 方案的话，似乎使得 B 方案有了无限可能，这有点耍赖：）会引发很多的问题，比如 lattice 作图要不要放到 B 方案里？但是我觉得加上一个设计精神源于 Base R，且功能强大，值得推广的 data.table 到 B 方案里应该是合理且有益的事情。

      哈哈，突然想起最近看《西游记》时的一个感慨，“或许在天上佛道已然一家亲了，只苦了“愚昧”的世人，还在下界痴痴地守着分别心。”不过想想，世上很多事情都是由分辨始，至融汇终的（取其优点，秉承“拿来主义”），这也算世事的一个常态吧。

          dapengde 我完全赞同你的BT之分的观点，tidyverse 是不含有 DBI 的，而 HarryZhu-7harryprince 可能长期泡在 tidyverse 和 sparklyr 的世界，已经有点模糊了，事实上， sparklyr 加载之后会自动从命名空间导入 DBI， 因为 sparklyr 是面向 spark 的接口包，没有这一层是无法传递 SQL 语句的，tidyverse 加载之后不会加载或从命名空间导入 DBI 包

                Liechi Cloud2016 data.table 我没用过，而且也没时间没兴趣试用—— Base R 已经解决了我所有的问题，额外学习 tidyverse 已经是很奢侈的事，我不想再花精力学别的可以完成同样工作的包了，DBI 更是用不着 。BT 这事儿要是有意义，诸位一起做才行啊！PR 或当合作者都行。

                      dapengde 我对 github 不够熟悉，所以比较犹豫给别人发 PR，不过会尝试。要是操作不对，还请多包涵。

                          离开了便利性问题谈功能，这个比较是有失偏颇的。按照研究套路，先定义清楚B和T，然后设定指标，对指标进行量化，最后通过分析得出结论。

                          • B我认为就是刚装上R时候的那个状态。
                          • 比较对象应试限于B和T功能上有交集的部分，不然没法比较。
                          • 指标设定包括但不限于学习陡峭程度、代码可读性、处理速度、资源占用等。
                          • 结论应该以数据为基础，避免主观偏好之间的无意义的舌战。

                          以上个人愚见供参考。

                          11 天 后
                          1 个月 后

                          dapengde 预览里”后记“链接失效了。可以从"title"部分点下一章进入”后记“，但目录处的”后记“超链接不工作。我克隆了这库，但是没有找到链接失效的原因，所以无法提出修改建议。

                              dapengde 大鹏，你那个分列的语法，我查不到啊，我自己建了一个例子，加了下面那个:::cl text ::::没有用啊。

                              
::: cl

Left block

:::

::: cr

right block
:::

                                  看了一眼大鹏的repo提一下建议：

                                  我觉得bookdown不适合作为BT擂台赛的平台，blogdown可能更适合一点。一来netlify+github的实时编译发布比起bookdown方便及时，一个新帖子对应一个运用实例+不同解决方案可以不断更新，二来gitbook模板单一可发挥的余地不多，hugo模板漂亮多了ww三来blogdown的tag categories等分类功能也可以方便地自动建立不同运用实例之间的关系，如 可视化/数据清理 这样的大致分类

                                  还有大鹏那个bookdown项目因为用了双栏布局，好多长代码快还多了个水平方向的拖动条，观感并不好。

                                  还有代码能加注释更好吧…

                                    tctcab 有道理。开始的时候我想过要不要换成别的形式，后来就搁置了，主要原因是懒得在形式上花更多精力，以及目前内容就那么一点点。

                                    从方便及时角度来说，现在是 travis 自动实时编译的，还算快。

                                    hugo 模板确实丰富漂亮，只是又得挑又得改的，麻烦。

                                    tag categories 当然会方便读者，不过就目前这么点儿内容， 暂时用不着吧。况且，这个项目能不能更新下去都不好说……

                                    长代码我会尽量弄短换行，消灭横滚条。

                                    代码加注释可以有……

                                    好吧，总之我就是懒。

                                    有空的话就 PR 些内容过来呀。等内容丰富了，再调整形式也不迟。

                                        dapengde

                                        要内容的话，我之前回答过的问题都有些记录，有空我整理一下pr过去
                                        https://github.com/tcgriffith/cosx_exps

                                        还有另一个可能的平台是wiki的形式，github那种，想参与的小伙伴直接编辑就行，省去了github克隆来叉过去的操作。

                                        另外如果嫌麻烦是主要难点的话，我就抽空去把blogdown的架子搭起来试一试

                                            tctcab 你这个问答记录整理得真棒。我以后也这么干。

                                            主要难点其实是怕雷声大雨点小。怕先搭好个大戏台，结果讲了个段子就完了。

                                                dapengde

                                                我在想怎么通过自动化来偷懒…
                                                比如一周拿爬虫扫一遍cos论坛找有用的帖子…

                                                    tctcab 可行。只要在问题答完之后，把问题和解答整理一遍，按设计好的格式发个总结帖即可。爬虫就抓这个总结帖。

                                                    不过，这恐怕没有减少多少工作量。

                                                      1 年 后

                                                      Liechi 以前用Tidyverse，现在用data.table. data.table虽然可能易读性差一点，但是简洁高效，写起来神清气爽！