LTkongjianyang 所谓 R Notebook，指的是纯 R 脚本，它可以直接编成输出报告，其原理是先通过 knitr::spin() 整理成 .Rmd 文件，剩下的就是 R Markdown 的套路了，R Markdown 能输出什么，它就能最终输出什么。

R Markdown Notebook 指的是一种特定输出格式的 R Markdown 文件，输出格式是 rmarkdown::html_notebook。只有这个是可预览的，前面说的 R Notebook 只能从头到尾一口气编译，不能像 R Markdown Notebook 那样一步步执行每个代码块、预览。

dapengde 是有点混乱。尤其是 R Presentation 这个菜单应该扔掉了，很容易引起误解，它是一个早期的试验品，现在基本废弃了。

.Rmd 文件通过 knitr::knit() 编译为 .md，然后通过 Pandoc 编译为其它输出（HTML、PDF 之类的），所以 rmarkdown = knitr + Pandoc 的包装。剩下的包都是 rmakdown 的扩展，几乎是平行关系，但 blogdown 继承了很多 bookdown 里的特性，所以算是 knitr 的重孙了。

        1 个月 后

        看 Hadley 的 《R for Data Science》也碰到这个疑惑，结果一搜就看到 yihui 的解释了。真高兴。

          10 个月 后

          dapengde 我觉得我明年应该停止一年代码开发，把我做过的事情好好捋一遍。我捣鼓的很多东西都没有卖力打广告，因为我不喜欢主动打广告，一般都是等用户自己去发现、雀跃，这样他们印象会更深一些。开发者自己王婆卖瓜容易招人嫌。

              yihui 可以请慕课网Angelayuan小姐姐给你打广告，她的讲解条例清晰、幻灯片优雅，说话声音尤其甜美。另外多去你同事那里转转，时不时测试下他们写的包对中文是否友好，这个很重要。另外可以考虑出中文版的书了，10个包乘以10人，不如1个包乘以1000能量大啊。

                yihui R mark down 混和写 she l l、python、s pa r k s q l 目前体验比 ju py te r 和 ze p pin 都要好太多了。但是推广力度不够，很少人知道怎么用。

                  rmarkdown 的推广难度，我感觉比推广 R 要高一两个数量级。

                  很多人使用 R，只为用其中的某个包，只需学会进入 R，读入数据，计算，拿到结果，离开 R。完毕。只是把 R 作为 Excel 里缺少的一个函数。即便是这个过程，门槛也不低，已经过滤掉了一批人。

                  而 rmarkdown，相当于让用户取代 word, powerpoint, endnote, mathtype，以及用户已经习惯的其他作图工具。肯换的都是有点极客精神，并且有闲或忙里偷闲。一般人都懒得换。

                  要想推广 rmarkdown，得抓住两点：

                  1. 从娃娃抓起。本科生开相关基础课，研究生从一开始就 rmarkdown。我将来要是带学生，就在科研入门阶段手把手地教。

                  2. 做好跟传统软件的接口，例如把 rmarkdown 跟 .docx，pptx等文件的相互转换做好，让不愿意换的人跟 rmarkdown 用户能顺畅协作。目前虽然 pandoc 能转成 doc，slidex 能转换 pptx，但都不够令人满意，而且是单向。老板一句“把 ppt 发给我修改”，能断了多少年轻人学xaringan的念想。

                  呈 yihui 阅。

                      dapengde 第一点我自己几乎无法控制，只能靠教育战线上的各位老师了，我能做的基本上只有写书（我的时间只够照顾到英文，中文就靠你了）。第二点难度略大，不过我相信 Markdown 与 Office 文档的可逆转换应该不会等太久了。最近刚有人做了个相关的包：https://github.com/noamross/redoc

                          yihui 这个好，找个时间试用。

                          文件格式互转的问题，我觉得思路可以放宽一点，不一定非要在技术层面写个包来实现，也可以从策略层面，只要找到常见场景下的解决方案就行了。

                          比如 spin() 函数将 R 脚本转成 .Rmd 文档，技术层面是不难的，它的价值在于策略层面，提出了一种 R 代码的书写方式，让两种格式的转换变得很容易。

                          在策略层面发发力，能减轻技术层面很多负担，也就是你说的“人脑一小步，电脑一大步”。

                              dapengde

                              其实Rmarkdown的尴尬之处还是在于用R的人不多。人都是有惯性的，习惯用word或者latex的人要转投Rmarkdown的话，除了markdown的学习成本(虽然不多)，还有R的学习成本。即使是编程作为必备技能的学术界，R也不是唯一的选择。

                              如果向别人推广学R的这一步跨过去的话，使用Rmarkdown等等都是很自然的事情。所以我认为推广Rmarkdown的关键还不在于Rmarkdown，也不在于Rmarkdown跟其他格式如何转换如何兼容，而是如何把R卖出去。

                                  tctcab 我一直再纳闷，R一开始安装上为什么不是Rstudio这样的ui，我一开始学R，看到那个原生的丑陋的ui就没什么兴趣了。其实R的原生ui设计的实在不够专业。另外，很多网上关于R的评价都是片面的，比如R运行速度比python慢，R不能处理大数据之类的。还有就是R的包太碎了，相互之间还有兼容性问题。我心目中的R应该是包的底层都用C或者C++实现，自带rstudio这样的ide，包按照功能分成大概100个以内就可以了，其他开发人员都去GitHub上完善功能就可以了，没必要开发那么多包，记不住。

                                      tctcab 确实如此， R 如果能推广的话，Rmarkdown 的用户自然也会多起来。然而这是另外一个话题了，不如逐个击破。我这里主要是想说让 R 用户用上 Rmarkdown 这个问题。并且，如果 Rmarkdown 推广得好，说不定会反哺 R，作为 R 的一个卖点，吸引一些人专门为了享受 Rmarkdown 的便捷而投入 R 的怀抱呢。

                                      chuxinyuan 丑陋的 UI 确实阻挡了一部分用户，但我觉得这不是 R 的问题，反正我给学生讲课的时候是直接忽视，提都不提，就当这个 UI 从来不存在，就当 R 是个类似于 ffmpeg 那样的 cmd 命令，这样的话，第三方 UI 可以尽情发挥，用户也有更多选择，这样也能刺激各个 UI 不断完善，比一家独大垄断要好得多。在 RStudio 出现之前， 其他 UI 如 Tinn-R、 Rkward 都挺流行的，而一些通用编辑器如 vim 等都有 R 的插件。即便是现在，RStudio 也不是一统江湖，Sublime Text、Atom、Emacs 等用户未见得需要 RStudio。不过，如果 RStudio 能将 R 打包一起安装，像对待 pandoc 那样，并且能对 R 的版本一键升级，像对待包包们那样，倒是会省很多唇舌。

                                      包太碎我觉得不是什么大问题。需要的话，你完全可以把一些小包整合成大包，像 tidyverse 那样，想合就合，想分就分。

                                            dapengde

                                            只论R的IDE的话，目前为止没有比Rstudio做的更好的了（并不只是我一个人的看法）

                                            很多人没转投python就是因为python里没有Rstudio同一级别的IDE

                                                chuxinyuan

                                                你看的这些评论水平都很低，不用理会，R包如果限制死一百个以内的话那就会跟c++一样让我讨厌了。
                                                另外R的包那么多记它干嘛…要用啥直接搜就行了，谁也不会嫌淘宝京东货物种类太少对吧

                                                    tctcab RStudio 也是最适合我的 R IDE。然而，每个人衡量的标准不同，功能强大的另一面是安装臃肿、加载缓慢、偶尔崩溃，这对我不算啥问题，但对一部分用户恐怕是难以容忍的。

                                                    我喜欢 RStudio，但不希望它一家独大，这样它才有前进和革新的动力。

                                                        tctcab 其实我心目中的R应该至少做好下面几方面的事情：

                                                        • 功能重叠和相似的包整合。有时候干同一件事，有n个包都可以，纠结啊，作为完美主义者，我往往只喜欢用功能最强大最优雅的那个，但是往往都是各有千秋，又有重合，两个都得学都得用，如果两位作者能合作下，那就事半功倍。

                                                        • 个别核心依赖包自动放在base里。比如ggplot2，很明显lattice应该换成ggplot2.

                                                        • 包的风格统一。一会儿驼峰，一会儿下划线，还有用点连接的,比如openxlsx::read.xlsx, readxl::read_excel,
                                                          jpeg::readJPEG, magick::image_read。统一风格可以减少学习成本。如果read.xlsx, xlsx.read, read_xlsx,
                                                          xlsx_read, xlsxRead, readXlsx都是等价的，随便用那个都可以，可以满足不同使用者的偏好，但是就是苦了
                                                          开发人员，而且不利用代码分享。不过可以做一个参数设置，开发人员自行选择自由切换。

                                                        • 包都支持管道符。不用管道符的时候大部分情况下，我都是用“=”号的，在管道符下我更愿意用“->”，而不是“<-” 。

                                                        • rmarkdown、blogdown、bookdown、shiny中文书籍。其实rmarkdown、blogdown、bookdown、shiny这些东西才是R诱人（装逼）的地方，但是我发现这方面的书基本都是英文版的。估计yihui工作所迫吧，其实很明显中国人多啊，中文版本能量更大啊。

                                                        • R的帮助系统支持多语言。这个对于初学R的比较友好。不然真的很容易放弃。

                                                            chuxinyuan

                                                            这几点我都觉得有道理，功能重复的包多的话确实有时候不知道用哪个…
                                                            风格统一算是小问题，然鹅争起来会没完没了

                                                            另外关于那些yihui的书的中文版的话，你也可以努力贡献呀，在出中文书之前开个blog写写教程什么的，还可以给主站投稿。你楼上的大鹏都整理整理博客出版了呢::😃

                                                              dapengde

                                                              有道理，rstudio在我的使用过程中感觉也有很多可以改进的地方，要是能有sublime那样灵活定制性和插件系统同时轻便快速那就完美了。主题和代码高亮颜色的自定义也想要，ubuntu下fcitx中文输入支持得不好也是一个问题。

                                                              不过本就是开源的项目的话，我觉得并不需要很担心一家独大的问题。