我并不想对 Jupyter 过度吐槽，但我一直认为它的设计其实非常辣鸡，而如此一款辣鸡产品偏偏流行到令人发指的程度，其名声和能力实在不般配。因为流行，人们便给它戴各种高帽子。上个月我见狗熊会一篇文章给 Jupyter 戴上了文学化编程的高帽子，便给留了条言，说它离文学化编程还远着呢。不知何故，这条留言没被准奏。后来问雪姨，雪姨问管理员，管理员说没见着我的留言。
好吧，我们再次祝同样辣鸡的微信公众号系统早日灭亡。
狗熊会的熊大说，要不你干脆给我们写篇文章澄清算了。我心里明镜似的，这不是给我挖坑吗——我赔了留言还得折文章。转念想想，我要说的主题并不复杂，于是告诉雪姨半小时后来收货。于是就有了《究竟嘛是文学化编程，以及为何 Jupyter 不算真 · 文学化编程》这篇短文。其实我写了也不会有几个人看，看了也未必能看懂，懂了也未必觉得有用。说实话，我觉得普通用户也用不着这种功能。
在我眼中，Jupyter 最大的设计缺陷在于它没有 knitr 里的代码段选项的概念，因此很难做到对输出结果的精细控制。比如 knitr 里的 echo = FALSE、fig.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 文档哟。若觉得它有用，还请帮忙不要公开宣传（可私下转告亲友）。若有任何建议和功能请求，我将洗耳恭听。