---
title: 深巷之酒
date: '2019-07-18'
slug: hidden-gem
---

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

好吧，我们再次祝[同样辣鸡](/cn/2017/05/wechat/)的微信公众号系统早日灭亡。

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

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

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

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

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