歷史注定重演，我們（程序員）老是開發同一款應用？

        英文原文：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。如果你寫大程序，它就會讀郵件。如果你是程序員，你會發現自己被待辦事宜清單吸引。然后你就會討論這些東西，因為它們是我們技術共享文化的試金石，是固定的宗教儀式。

        幾乎沒有什么感覺能跟把所有潛在的任務用復選框組織為分層列表那么好的了。做事情，回郵件—這些都很不爽。但是組織這些事情卻預期能給人帶來愉悅。

        工作是困難的，但是思考工作卻相當有趣。因而就有了軟件產業。

        電子郵件沒有壞，生產力工具也都不惡心，只是文化改變了。大家做電子郵件客戶端或待辦事宜清單應用就跟劇院用現代的衣服演莎士比亞的戲劇一樣。“電子郵件”就是我們的哈姆雷特。“待辦事宜”就是我們的暴風雨。

        開發者高舉技術之劍，朝著文化的基石砍去—利刃裂成碎片。沒關系，我們還可以鍛造更大更好的劍。每次打造這把利刃之時，我們會念叨著清單制作者永恒的慰藉：這一次會不一樣。

                    <span id="shareA4" class="fl">                            
                        </span></div>