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

除其他貢獻外，Hoare 還發明瞭併發程序通訊（CSP）語言，用於指定併發程序的互動。他是一位聰明人，為計算機科學的發展做出了傑出貢獻。

1980 年，Hoare 因“在程式語言的定義和設計方面做出的基礎性貢獻”而榮獲圖靈獎。他題為《皇帝的新衣》的獲獎感言，不僅應成為計算機科學家必讀的材料，IT 管理員和應用程式開發人員也應必讀。

讓我引用幾句金玉良言

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

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

與語言相關——以及早已過時的技術——的觀點至今仍然具有共鳴

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

現代翻譯——程式碼到測試的週期必須儘可能短，使敏捷測試對生產力至關重要。

在描述一個過於複雜的語言專案時，Hoare 評論道：

起初我希望這樣一個技術上不健全的專案會崩潰，但我很快意識到它註定會成功。軟體中的幾乎任何東西，只要有足夠的決心，都可以實現、銷售，甚至使用。沒有什麼純粹的科學家能夠抵擋住一億美元的洪流。但有一點是無法用這種方式購買的——那就是可靠性。可靠性的代價是追求最大的簡潔性。這是非常富裕的人們最難付出的代價。

當我 5 到 6 年前第一次看到這篇演講稿時，在“舊 J2EE”的黑暗時代，我感覺 Tony Hoare 正在直接對我說話。Tony Hoare 在 1980 年就預測了 J2EE 的問題。那時，就像大多數比提升簡歷更關心取得成果的 J2EE 架構師一樣，我陷入了與 Hoare 在 PL/1 上的困境——以緩慢的 गति 觀察一場災難，卻無力挽救。在 2004 年的《J2EE without EJB》一書中，我寫到了“複雜性產業”，它以巨大的金錢、時間和純粹的失敗為代價，產生了過度複雜的解決方案。複雜性產業在應用程式開發團隊和內部架構組以及基礎設施中蓬勃發展。複雜性產業很難克服，因為有太多的人對其存在既得利益——有時是經濟上的；有時是職業上的（當它讓他們建立帝國時）；而且非常頻繁地只是為了提升簡歷。那些為其辯護的人總是可以爭辯說批評者根本不理解他們批評的東西——這使得當 Hoare 這樣無可爭議的傑出人物發言時，其重要性更加凸顯。

那是本世紀初——那是上個世紀概念的遺產。今天，情況已經不同了——至少在企業 Java 領域是這樣。 **Tomcat 的流行度急劇增長** 也許是開發人員現在有能力強制執行簡潔性的最大證明。Ruby on Rails 對 Java 的（健康的）壓力（我認為最終會加強 Java）也指向了這一點。甚至有證據表明，一些傳統的應用程式伺服器供應商已經理解了這種變化以及它如何使他們的客戶受益。BEA 透過擁抱 Spring 和其他簡化客戶體驗的技術，可以說已經走在了前面。即使是 Sun——透過Java EE 6 Profile 概念——似乎也與時俱進，並認識到許多客戶不再想要傳統的、單體的應用程式伺服器的現實。

每次有人選擇不使用 EJB；每次有人選擇將 Web 應用程式部署在 Tomcat 而不是 WebSphere 上；每次有人選擇使用簡單的遠端呼叫策略而不是複雜的基於 SOAP 的方法，他們都在做出這種選擇簡潔性的決定。正如 Hoare 所評論的，透過更簡單的方法，他們遠非構建“非企業級”解決方案，而是實際上在可靠性等關鍵的企業級特性方面取得了顯著的進步。

可靠性的代價是追求最大的簡潔性。這是非常富裕的人們最難付出的代價。

自從在最近一次悉尼之行中遇到一位現在是學者的大學老朋友以來，我一直在思考計算機科學。因此，我重新審視了 Hoare 的演講。但除了 Hoare 在商業和學術界經驗中的明顯教訓之外，在企業 Java 應用程式開發的背景下思考計算機科學是令人沮喪的。我們離做聰明的事情還差得很遠。我們已經深受複雜性的困擾，以至於我們專注於讓事情正常工作。正如 Hoare 所強調的，無論你想做什麼，從程式設計師的角度來看，擁有一個簡單的模型是成功完成它的先決條件。（通常基礎設施需要很聰明才能實現這種簡潔性。）

過去幾年一直在努力讓企業 Java 的模型在實踐中奏效，並擊敗複雜性產業。這在很大程度上已經完成。今天，企業 Java 專案的結果相當可預測且良好。我相信未來幾年將專注於解決更深層次的問題，並構建更智慧、對執行的程式碼有更深入瞭解的基礎設施。我為我相信我們的公司能夠幫助實現這一現實而感到自豪。隨著我們不斷在許多領域帶來創新，SpringSource 將處於開發下一代技術的最前沿，例如Spring OSGi 動態模組和 AspectJ，而不僅僅是收拾過去的爛攤子。無論情況如何，對於希望獲得可預測、成本效益的開發人員和管理者來說，未來是光明的。

新年快樂！