上週五是託尼·霍爾 (C.A.R.) 的生日。誰是 C. A. R. Hoare？如果你是一名程式設計師，你可能對 快速排序 (Quicksort) 很熟悉——這是一種優雅且出奇簡單的排序演算法，在大多數情況下速度極快。如果你學過計算機科學，你幾乎肯定用多種語言實現過快速排序，並且會認出這個頁面上的動畫。霍爾在 1960 年發明了快速排序，它現在是最廣泛使用的排序演算法。

除了其他貢獻之外，霍爾還發明瞭通訊順序程序 (CSP) 語言，用於規範併發程序之間的互動。他是一位聰明的人，為計算機科學的發展做出了傑出的貢獻。

1980 年，霍爾因“對程式語言的定義和設計做出的根本性貢獻”而獲得圖靈獎。他的獲獎感言，題為 《皇帝的新裝》，不僅應是計算機科學家，也應是 IT 經理和應用程式開發人員的必讀之作。

讓我引用幾句精闢的話

程式設計師總是被複雜性包圍；我們無法避免它。我們的應用程式之所以複雜，是因為我們雄心勃勃地希望以越來越複雜的方式使用計算機。程式設計之所以複雜，是因為我們每個程式設計專案都有大量相互衝突的目標。如果我們使用的基本工具，即我們設計和編寫程式的語言也很複雜，那麼語言本身就會成為問題的一部分，而不是解決方案的一部分。

這不僅適用於語言，也適用於平臺和框架。在實現業務應用程式時，平臺和框架對成功和失敗的影響越來越大，甚至超過了語言本身——這是我在 去年 11 月在 QCon 舊金山參加的一個關於 Java 語言未來的小組討論 中提出的觀點。基本的真理是，基礎設施（無論是語言還是平臺）的作用是簡化開發人員的工作，讓他們能夠專注於實現業務價值的真正任務。

關於語言——以及早已過時的技術——的觀點，如今仍有共鳴

對於分時或個人計算機系統的使用者來說，輸入程式（或修改）到開始執行該程式之間的時間間隔是完全低效的。

現代的解讀——程式碼到測試的週期必須儘可能短，這使得敏捷測試對提高生產力至關重要。

在描述一個過度複雜的語言專案時，霍爾評論道：

起初我希望這樣一個技術上不健全的專案會垮掉，但我很快意識到它註定會成功。只要有足夠的決心，軟體中的幾乎任何東西都可以實現、銷售甚至使用。一個普通的科學家所說的話，無法抵擋數億美元的洪流。但有一種品質是無法這樣獲得的——那就是可靠性。可靠性的代價是追求極致的簡潔。這是一個富人最難付出的代價。

大約五六年前，在我第一次讀到這篇演講稿時，正值“舊 J2EE”的黑暗時期，我感覺託尼·霍爾彷彿在直接對我說話。託尼·霍爾在 1980 年就預言了 J2EE 的問題。那時，就像大多數更關心取得成果而非提升簡歷的 J2EE 架構師一樣，我正面臨霍爾在 PL/1 專案中遇到的同樣情況——看著一場災難緩慢發生，卻無力阻止。我在 2004 年出版的 《拋棄 EJB 的 J2EE》 一書中寫到了“複雜性產業”，它以巨大的金錢、時間和徹底的失敗為代價，製造出過度複雜的解決方案。複雜性產業在應用程式開發團隊、內部架構小組以及基礎設施領域都蓬勃發展。複雜性產業難以克服，因為太多人對其存在有著既得利益——有時是經濟利益；有時是專業利益（當它允許他們建立自己的“帝國”時）；更多時候僅僅是為了提升簡歷。那些為其辯護的人總是爭辯說，批評者根本不理解他們批評的內容——這使得像霍爾這樣毋庸置疑的傑出人物發聲變得更加重要。

那是本世紀初的事情了——也是上世紀概念的遺留。今天，情況不同了——至少在企業 Java 領域是如此。Tomcat 流行度的顯著增長 可能是開發人員現在擁有強制推行簡潔性的最大證明。Ruby on Rails 對 Java 的（健康的）壓力（我認為最終會增強 Java）也指向了同一件事。甚至有證據表明，一些傳統的應用伺服器供應商理解這種變化以及它如何能惠及他們的客戶。BEA 透過 擁抱 Spring 和其他簡化客戶體驗的技術，可以說開創了先河。即使是 Sun——憑藉 Java EE 6 Profile 概念——似乎也在與時俱進，承認許多客戶不再需要傳統的、單體式的應用伺服器這一現實。

每次有人選擇不使用 EJB；每次有人選擇在 Tomcat 而不是 WebSphere 上部署 Web 應用程式；每次有人選擇採用簡單的遠端呼叫策略而非精心設計的基於 SOAP 的方法時，他們都在做出簡潔的選擇。正如霍爾所評論的，透過更簡單的方法，他們遠非是在構建“非企業級”解決方案，而實際上是在可靠性等關鍵的企業級特性上獲得了顯著提升。

可靠性的代價是追求極致的簡潔。這是一個富人最難付出的代價。

自從最近一次去悉尼拜訪了一位現在是學者的老大學朋友後，我一直在思考計算機科學。因此，我重溫了霍爾的演講。但除了霍爾在商業界和學術界經歷中顯而易見的教訓外，在企業 Java 應用程式開發的背景下思考計算機科學是令人沮喪的。我們離做一些巧妙的事情還很遠。我們已經被太多的複雜性困擾，以至於我們專注於讓事情運轉起來。正如霍爾強調的，無論你想做什麼，從程式設計師的角度來看擁有一個簡單的模型是取得最大成功的先決條件。（基礎設施通常需要巧妙才能實現這種簡潔性。）

過去幾年主要是關於讓企業 Java 模型在實踐中發揮作用並擊敗複雜性產業。這基本上已經完成。如今，企業 Java 專案的結果相當可預測且良好。我相信未來幾年將是關於解決明顯問題之外的問題，並構建更智慧、對其執行的程式碼有更深入瞭解的基礎設施。我很自豪地相信我們公司能夠幫助實現這一現實。隨著我們在許多領域持續創新，SpringSource 將站在解決構建下一代技術（如 用於 OSGi 服務平臺的 Spring Dynamic Modules 和 AspectJ）的前沿，而不僅僅是清理昨天的爛攤子。無論如何發展，對於應用程式開發人員——以及那些想要可預測、成本效益高的結果的經理們來說——未來看起來一片光明。

新年快樂！