Yihui Xie

深巷之酒

谢益辉 / 2019-07-18


我并不想对 Jupyter 过度吐槽,但我一直认为它的设计其实非常辣鸡,而如此一款辣鸡产品偏偏流行到令人发指的程度,其名声和能力实在不般配。因为流行,人们便给它戴各种高帽子。上个月我见狗熊会一篇文章给 Jupyter 戴上了文学化编程的高帽子,便给留了条言,说它离文学化编程还远着呢。不知何故,这条留言没被准奏。后来问雪姨,雪姨问管理员,管理员说没见着我的留言。

好吧,我们再次祝同样辣鸡的微信公众号系统早日灭亡。

狗熊会的熊大说,要不你干脆给我们写篇文章澄清算了。我心里明镜似的,这不是给我挖坑吗——我赔了留言还得折文章。转念想想,我要说的主题并不复杂,于是告诉雪姨半小时后来收货。于是就有了《究竟嘛是文学化编程,以及为何 Jupyter 不算真 · 文学化编程》这篇短文。其实我写了也不会有几个人看,看了也未必能看懂,懂了也未必觉得有用。说实话,我觉得普通用户也用不着这种功能。

在我眼中,Jupyter 最大的设计缺陷在于它没有 knitr 里的代码段选项的概念,因此很难做到对输出结果的精细控制。比如 knitr 里的 echo = FALSEfig.width = 5 之类的选项,恐怕 Jupyter 都无法做到。我那篇微信文章强调的是诸多代码段选项中的一项,即代码段标签。有了标签,则有了无穷的文学化编程法力。至于它采取 JSON 而不是普通纯文本文档作为源文档格式,倒不算太大的设计缺陷(不过强行把输出和源代码混在一个笨重的 JSON 文件里是一个设计缺陷)。

我一直好奇,为啥这么明显的问题在如此庞大而狂热的 Python 社区没有人出来解决呢?直到前天我终于看见 Python 里出现一款能与 knitr 的设计匹敌的产品,叫 Codebraid。我不懂 Python,但从文档来看,它的设计终于有点像 knitr 了。它号称支持文学化编程,但我不知道它不知道它支持到什么程度。当然,做人不能太厚颜,我得申明 knitr 的设计源于 Sweave;Sweave 提出了一个天才的想法,问题只是它的具体实现太弱。

从 Github 上看,这项目差不多开发了一年了,但它所吸引的目光与 Jupyter 相比,显然只是沧海一粟。在我看来,Codebraid 理论上应该是完胜 Jupyter,但恐怕这巷子太深,Jupyter 的金字招牌太亮眼,好酒也不会有人注意到。一个项目的成功,一定程度上还得取决于时机和宣传手段。之所以有很多人愿意帮我躺着开枪,也不过是因为我踩中了一个好时机(碰巧赶上了 RStudio 的火车),并持续使用一些非常规的营销手段而已。

说到这儿,我干脆打个小广告好了。若有客官像我一样觉得 Jupyter 太弱,不妨尝试一下我几个月前偷偷塞进 rmarkdown 包的一个小函数,它可以把 Jupyter 转化为 R Markdown 文档哟。若觉得它有用,还请帮忙不要公开宣传(可私下转告亲友)。若有任何建议和功能请求,我将洗耳恭听。