历史注定重演，我们（程序员）老是开发同一款应用？

        英文原文：Doomed to Repeat It——Learning from the things we make over and over

        我的朋友 Finn Smith 问我：你有没有注意到，我们（程序员）老是开发同一款应用？我们马上脑补出了少部分的清单：电子邮件、待办事宜列表、博客工具等等。

        电子邮件

        电子邮件永远都有大单交易—2013 的就是 Mailbox。这款简化邮件分类和处理的电子邮件应用甚至连下载都要排队。随着 Dropbox 用 1 亿美元将其收入囊中。对 Mailbox 的讨论也戛然而止。

        同年还冒出了 Gmail Inbox Tabs，也可以对邮件进行“主要”、“社交”、“论坛”之类的预分类。这很有用，因为它把来自于人的邮件（高价值）和来自于组织及邮件列表的邮件进行了区分（低价值）。这引发了组织的担忧，因为其未来计划是以你永远都要被迫接收器电子邮件的假设为基础的，但 Google 粉粹了这个基础。

        今年还没有再造电子邮件的竞争者。如果有的话也许是 Inbox。由前 Dropbox 等员工做的这个东西可以让你把电子邮件当作一个平台，并方便 web 开发者通过电子邮件做事。这么做是很有意义的，因为 web 程序员的数量要比电子邮件开发者多。但是这个东西不是消费者产品，更像是开发消费者产品的工具，所以火起来的可能性不高（也包括那堆以 box 作为后缀的产品）。

        这些产品都是“电子邮件问题”的软件解决方案，但是还有文化上的解决方案。许多人干脆放弃电子邮件，宣告它的破产，也就是说这些人要把电子邮件全部删掉重新开始。有的则寻求“零收件箱”，即把所有的电子邮件过滤到任务清单。为此你甚至还能获得一枚零收件箱勋章。1990 年代的程序员兼比萨店老板 Jamie Zawinski 甚至还弄出了一个讽刺的“软件封装定律”：“每一个程序都有扩张的冲动，直到它能读邮件为止。那些无法如此扩张的程序将会被有此能力者取代。”（即真正有用的程序都会受到演变为工具包或应用平台的压力，邮件程序只是其副作用）

        那我们就来看看那些人写软件或写文章抨击的电子邮件问题在哪里：

太多，邮件来源也太多，很难整理（Gmail tabs，Mailbox 要解决的）

它成为大多数应用的一部分（封装定律）

其工作方式难以理解，不像 web（Inbox）

它会压垮你的人生，你收件箱理想的电子邮件数应该为 0（Inbox Zero，破产论）

        下面这个视频是 Bret Victor 有关编程的未来的一段演讲，他扮演了一位 1970 年代 IBM 工程师的角色，值得一看，哪怕你不是程序员，因为它生动地并充满娱乐性的方式说明了早在 1960 年代末的人就已经理解了现代数字时代最核心的思想和概念。而电子邮件始于 1971 年。

        待办清单

        Victor 在演讲里面提到过一个系统，1968 年 Doug Engelbart 的 NLS 系统，这个系统是许多东西的先驱—协作软件、超文本、鼠标等，但最根本的一个是待办事宜管理器。自那以后，个人生产力工具就变得一发不可收拾。每一两年就会有一些新宠出现：先是 Remember the Milk，接着 OmniFocus，然后 TaskPaper，现在是 Asana。Asana 的口号是“没有电子邮件的团队协作”。当然，还有一堆的生产力技术是不需要计算机参与的，包括“Getting Things Done（GTD，尽量去做）”系统，这在互联网已经火了好几年了—Inbox Zero 就是它的传奇。其影响力在整个软件 app 界都可以感受得到。

        待办事宜 app 已经变成流量某种元技术。比方说，一旦程序员为 web 想出了一种新的编程语言或框架，他们就得证明为什么自己的办法更好，证明的办法之一就是写个待办事宜应用。甚至还有一个网站 ToDoMVC 为你克隆版的应用准备好所需的图片和素材；同一个待办事宜工具，在那个网站上面就有超过 60 个不同的版本，每一个都是用自己的框架或按照自己的办法写出来的（这些还只是 web 的，你还可以用任何语言写待办事宜 app）。这样一来，要购买框架的人就知道哪一个适合自己的需求了。待办事宜清单就好比是某种元思想—被理解和接受的程度之高以至于已经成为了一种速记法，一种人人都共享的常识。

        待办事宜清单的隐喻与软件开发的内涵非常类似。任务可分解为序列，序列的每一项都可以依次执行。程序员热爱待办事宜也许是因为待办事宜清单跟程序类似。“Yet another（另一种）”只是无数缩略语的一部分—另一种标记语言（YAML），另一种 JSON 库（YASL），另一种正式层级化体系（Yet another Hierarchical Officious Oracle—Yahoo！o(╯□╰)o）。

        其它东西

        还有很多东西是我们一而再再而三地做的。评论系统、论坛、统一通信管理应用、协作协作工具、博客平台等等。

        还有标记语言。这个包裹数据并赋予其含义以便在计算机间传递的语言已经有了无数的翻新：S-expressions、XML、JSON、YAML、HTML1-5 等等，这些都是解决“如何在计算机间共享信息”问题的无休止的努力。然后就有了格林斯潘的第十定律：

任何 C 或 Fortran 程序复杂到一定程度之后，都会包含一个临时开发的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的 Common Lisp 实现。

        也就是说编程语言 Lisp 的质量（或者说感受性）—它的简洁，它用内存处理一组事情的办法是如此的基础以至于自然而然就会出现。如果你写大程序，你就会重新发明 Lisp。如果你写大程序，它就会读邮件。如果你是程序员，你会发现自己被待办事宜清单吸引。然后你就会讨论这些东西，因为它们是我们技术共享文化的试金石，是固定的宗教仪式。

        几乎没有什么感觉能跟把所有潜在的任务用复选框组织为分层列表那么好的了。做事情，回邮件—这些都很不爽。但是组织这些事情却预期能给人带来愉悦。

        工作是困难的，但是思考工作却相当有趣。因而就有了软件产业。

        电子邮件没有坏，生产力工具也都不恶心，只是文化改变了。大家做电子邮件客户端或待办事宜清单应用就跟剧院用现代的衣服演莎士比亚的戏剧一样。“电子邮件”就是我们的哈姆雷特。“待办事宜”就是我们的暴风雨。

        开发者高举技术之剑，朝着文化的基石砍去—利刃裂成碎片。没关系，我们还可以锻造更大更好的剑。每次打造这把利刃之时，我们会念叨着清单制作者永恒的慰藉：这一次会不一样。