Bjarne新文章《Evolving a language in and for the real world: C++ 1991-2006》的讀後感

《Evolving a language in and for the real world: C++ 1991-2006》是Bjarne Stroustrup于2007年6月，在HOPL-III上發表的一篇新論文。

文章大體的内容同D&E相近，但補充了一些新的資訊，特别是D&E出版後C++的發展和變化，以及對未來的展望。更重要的是，Bjarne一反D&E裡中立的态度，比較了幾種熱門語言同C++的差别，非常有趣。

該文的原版連結在這裡（http://www.research.att.com/~bs/hopl-almost-final.pdf）。但水木的overcomeunic不辭辛勞，翻譯了這篇整整60頁（夠得上單行本了）的巨大paper，這裡對其表示敬意和萬分的感謝。文章中文版的連接配接在此處。也可以從ponba的讨論組TopLanguage裡下載下傳。

我花了大半天的時間，幾乎一口氣看完了這篇文章，感想頗多。于是決定寫下來，同大家一起交流。

開篇是一些概括性的介紹。然後便是早期曆史，這些也沒什麼，D&E上基本都有。引起我注意的，是第8頁關于iso标準程序的内容。D&E中講述過一些，但這裡提供了更多的細節資訊。有這樣一段話引起了我的注意：

“J16委員會的成員是自願者，他們必須付錢（一年大約800美元）去獲得做這些工作的榮幸。是以，大部分的成員代表公司，公司願意支付會費和旅行開銷，但總有一小部分人得為自己買單。”

我把這段paste給一個同僚看。他立刻回複我：“倒貼啊！”。不過幾秒鐘後，他馬上發出了感歎：“他們的學術環境很好，中國現在是利字當頭，不會有人去做這種事情的。”當然，對于那些公司支付費用的而言，并沒什麼。令我們感到詫異的是那“一小部分得為自己買單”的人。從文章後面的内容來看，這種苦差事，别說“倒貼”，就是付錢少了，也很少有人原意幹的。

這段緊接着講述WG21(ISO)的情況。然後是投票的方式等等。這段最後以這樣一句話結束：

“對于1997/1998的最後标準投票，ANSI投票是43-0，ISO是22-0。我們真的達到了一緻性，甚至是全體通過。我被告知這樣明确的投票是很不尋常的。”

這種一緻性當然是委員會成員長期努力的結果。這也是這個組織充分平衡的結果。當然，後面可以看到，這種平衡通常也會造成很大的問題，甚至是傷害。

“對于大多數成員來說，與C++的早期版本（ARM C++[35]）相容，與C的早期版本（K&R C[76]）相容和公司的各種方言相容是一個嚴重的事件。我們（委員會的成員們）嘗試面對将來的挑戰，比如并發，但我們真的牢記C++是許多工具鍊的基礎。破壞C++，那麼Java和C#的主要編譯器也會被破壞。顯然地，委員會不能通過不相容性來“破壞C++”，盡管不相容性會破壞C++。工業界會簡單地忽視一個嚴重的帶有不相容的标準，同時開始偏離C++。”

這段内容明顯地表明标準化的重要性，同時也表明C++有多麼大的曆史負擔。

3.3節 ISO C++标準程序，第10頁，：

“在1991年的Lund（瑞典）會議後，下面的警戒性的傳說在C++社團中流行起來：

我們常常提醒自己關于輪船Vasa的故事，那時它是瑞典海軍的驕傲，計劃建造成有史以來最大和最漂亮的戰艦。不幸的是，為了裝載足夠的雕像和大炮，它在建造過程中經曆了重大的重新設計和擴充。結果是它在跨Stockholm港灣的途中，一陣風過後它就沉了，大約

有50人遇難。這艘船已經被打撈上來，你可以從Stockholm的博物館裡看到它。它看起來非常漂亮—比它第一次擴充重新設計前漂亮得多。也比那些17世紀的戰艦漂亮得多—但那不能成為它的設計者、建造者和預期的使用者的安慰。

這個故事經常被提起，作為反對增加特征的預警（那就是我告訴委員會的場景）。不管怎麼樣，對于複雜的事物，總有另一面：如果Vasa已經完成原來的設計，當首次遇到“現代的兩層甲闆”的戰艦，它也同樣會被打得滿身是洞，沉到海底。忽視世界中的改變也不是選擇。”

關于Vasa戰艦的故事D&E裡已經說過了。最後這一段則是新的内容。這表明了任何事物都必須不斷變化。而反過來，為了避免Vasa的結局，應當事先考慮周密，需要更富于遠見。

4.1節 STL 第11頁

講述了STL的故事。從STL前的傳統做法開始，到STL的建立過程和思想。其中提到了Bjarne對容器的要求：

“STL代碼看起來非常不同，然而，多年後我總結出一個清單，那些我認為對于容器來說是很重要的屬性都列于其上：

1、單獨的容器是簡單和高效的

2、容器提供它的“自然的”操作（比如，list提供put和get，vector提供下标操作）

3、簡單操作，比如成員通路操作，不需要函數調用用于它們的實作

4、提供公共函數（可以通過疊代器或基類）

5、容器預設是靜态類型安全的，并且是homogeneous（即在同一個容器的所有元素的類型相同）

6、heterogeneous容器能夠由存儲指向共同基類的指針的homogeneous容器所實作

7、容器是非侵入式的（比如，要成為容器的成員，一個對象不需要有特殊的基類或連結的字段）

8、容器能夠包含内建類型的元素

9、容器能夠包含有外部強加布局的structs

10、容器能應用在一般的架構上（容器和在容器上的操作）

11、沒有sort成員函數的容器也能排序

12、“公共服務”（比如persistence）能獨立地提供給一組容器（通過基類？）”

這些标準多少有些理想化，但STL都做到了（除了最後一條）。足見Stepanov的智慧。

“它花了我一些時間—很多周—去習慣STL。”

學習STL需要很大的轉變，即便Bjarne，也花了這麼多時間。其中Koenig起了至關重要的作用。Koenig在C++上所起的作用，可以說僅次于Bjarne，但他的名氣遠不及Bjarne，甚至Meyes。這位幕後英雄的這種執着，令人敬佩。

4.1.3 節 STL理想和概念，p10

“那麼STL是什麼？它來源于一種嘗試，應用數學的一般性的理想去解決資料和算法的問題。對容器裡面的對象進行排序并寫一個算法去操作這些對象，對這類問題的思考也就是理想的方向，獨立群組合地表達概念：

  用代碼直接表達概念

  用代碼直接表達概念之間的關系

  用獨立的代碼直接表達獨立的概念

組合代碼自由表達概念，隻要組合言之有理。”

這讓我想起了工業界已經使用了百餘年的子產品化群組件化方式。在過去，很多人都試圖讓程式設計也具備這種能力。但STL所展示的技術，則是第一次如此靈活、自由、簡潔和優雅地實作了這種方式。STL的出現徹頭徹尾地改變了C++的程式設計，使得C++成為了一種全新的語言。可惜的是，業界似乎尚未從OOP的震撼中清醒過來，對于這種技術的價值，還未有深刻的認識。（這就像神經細胞，一次發放之後，總會有個“不應期”，不對任何刺激做出反應）。

5.2節 export論戰，p31

關于Export的論戰。講述了這樣一個故事：

“這個傷感傳奇的真正主角是EDG編譯器的實作者：Steve Adamczyk，John Spicer和David Vandevoorde。他們強烈反對分離模闆編譯，最後為達到最佳妥協投贊成票，然後花了超過一年的時候完成了他們所反對的東西。這就是專業！編譯器的實作正如他的競争對手所預測的那樣困難。但它成功了并帶來了一些好處，正如它的支援者所承諾的那樣。不幸的是，由于一些對分離模闆編譯的必要的限制，是以承諾以因沒能提供它們預期的利益并且讓編譯器變得更加複雜而告終。一如往常，在技術問題上的政客般的承諾導緻了“warts”。”

職業的精神，這種人才稱得上大師。

5.4 自動廢料收集，p34。

出乎我的意料，Bjarne是C++的GC倡導者，甚至還發出了一個提案。我一直以為Bjarne反對gc。C++0x最終還是會引入gc，而且更加完善。或許當時沒有加入gc是對的。反觀java等語言的gc，顯得那麼不成熟。現在新的gc模型要進步許多，或許現在才是C++使用gc的時候。

5.5 未完成的工作，p36。

“對“為什麼我們沒有提供更多有用的庫”的回答是簡單的：我們沒有資源（時間和人力）去做比我們所能做到的更多的工作。”

唉，都是錢鬧得。

“在1992年，TI提供他們的非常漂亮的庫用于考慮，在一個小時内，有5個主要公司的代表清楚地表達了他們的觀點：如果這個庫被認真考慮的話，那麼他們将推薦他們自己公司的基礎庫。這不是委員會所能接受的。對一緻性要求不是很高的委員會也許會通過從商用庫中選擇一個來達到目的，但對于C++委員會來說，這是不可能的。”

商業利益總是象一劑毒藥，損害着真正重要的東西。

“1994年同樣也是必須被記住的，許多人已經認為C++标準庫太大了。Java還沒有改變程式員的觀點，即他們可以從一門語言中免費得到某些東西。反而，C++社團中的許多人使用微小的C标準庫作為庫大小的比較機關。一些國家代表（荷蘭和法國）反複表達他們對C++标準庫的膨脹的擔憂。象委員會中的大多數人一樣，我也希望标準會對C++工業庫有所幫助而不是取代它們。”

這些都是平衡帶來的問題。

6.1節 性能技術報告，p38。

與其空談C++的性能如何如何，或者沒完沒了地争論C++和C誰快，還不如認認真真地去看看這些報告，來提升自己的水準。誰都可以得益，不管用不用C++。

6.2節 TR庫，p41。

“盡管标準庫和它的擴充的重要性是非常巨大的，我在這裡隻能簡要地列出新的庫：

  多态函數對象封裝器

  Tuple類型

  數學的特殊函數

  類型粹取

  正規表達式

  增強的成員指針擴充卡

  通用的智能指針

  引用封裝器

  用于計算函數對象傳回類型 的統一的方法

  增強的binder

  hash table”

這些庫也都是些基礎庫，盡管非常關鍵，有用。但程式員的需求遠遠超過這些。況且除了boost，還沒有哪家廠商正式實作它們。我們隻能等待C++0x早日到來。

7.1 應用程式設計vs系統程式設計，p43。

盡管Bjarne一再聲稱C++主要領域在系統程式設計方面，但實際上，就目前的C++能力而言，同樣也非常适合應用程式設計，盡管不是最适合的。在C++的整個發展過程中，人們發現C++具備了所有領域開發的能力（且不論是否最适合），或者說具備了很好的基礎。于是，大家都希望把有利于自己的技術安插進去。C++最終成為了一種幾乎是“全能”的語言。這是好事，也是壞事。語言的複雜度使得人們望而生畏（多半是心理因素，和環境影響），而教學和教育訓練的壓力陡增，這使C++在現在這種隻注重“表面效率”的環境下，生存會變得更加艱辛。但強大畢竟是強大，當我們充分思考了“如何更好地完成軟體”這個問題後，會發現，C++在很多方面，特别是服務性元件開發方面擁有很大的優勢。是以，我認為，C++的定位應當是“基礎程式設計”，而并非僅僅是“系統程式設計”而已。

7.4 ABI和環境，p47。

我們經常說C++的這缺陷，那不足。實際上，在我看來，從長遠角度來看，C++最主要的問題是ABI，也就是缺少一個統一的二進制移植标準。從發展趨勢看，未來不可能有一種語言在大多數領域占統治地位。語言間的合作、取長補短，是一種非常好的政策。但這需要語言間擁有統一的接口标準。目前的C++，即便是其自身，也沒有統一的二進制接口，何以因應未來的發展呢？

7.7 Java和Sun，p50。

這是最精彩和最有趣的部分。人人都想知道Bjarne如何評價Java。這回他總算破例，讓我們開開眼。

“然而，已經有許多關于C++/Java關系的說法，Java在市場中的存在已經影響到了C++社團。是以，一些評論不可避免，盡管恰當的語言比較不在本文的考慮範圍之内，甚至在C++的定義中也沒有Java的蹤影。”

這段話的意思差不多就是：你Java已經挖壞了我家牆角了，我也得動點真格的了。

“為什麼不？從Java早期，C++委員會總是包含那些有許多Java經驗的人：使用者、實作者、工具建構者、和JVM實作者。”

就是說：沒我C++，哪來的你Java，别忘本！

“我認為在基礎層面上，Java和C++是在傳達想法時有很多不一樣的東西。特别地：

  C++依賴于直接通路硬體資源，去擷取它的許多目标，然而Java依賴于虛拟機，進而讓它遠離硬體

  C++隻帶有限的運作時刻的支援，而Java依賴于許多中繼資料

  C++強調與用其它語言寫的代碼的互動，并且共享同一系統工具（比如連結器），而Java的目标是通過将Java代碼與其它代碼隔離，進而達到簡化的目标。”

咱根本不是一個檔次的東西，有什麼好比的。

“ 9.2.2 ，我概述出用于C++的基本設計準則：一個比C++更好的語言将意味着什麼？考慮第一位的決定：

  使用靜态類型檢查和Simula類似的類

  分離語言與環境間的關系

  C源代碼相容性（“盡可能地近”）

  C連結和布局相容（“真正局部變量”）

  不依賴于廢料收集”

請注意，最後一條。隻是說“不依賴于”gc，就是說沒gc也得能活，有當然更好了。

“C++并不滿足Java的設計準則；它也不想滿足。類似的，Java也不滿足C++的設計準則。”

咱不跟你一般見識。

“不幸的是，Java支援者和他們的市場機器不是宣揚Java的本質，而是對Java與其它語言（大多指C和C++）做了許多不公的比較。正如2001年晚期，我聽到Bill Joy聲稱（可能是在技術介紹時口頭上說的）說“可靠的代碼不能用C/C++寫，因為它們沒有異常”（參見§5，§5.3）。我認為Java是Sun用于對付微軟的商業武器，但卻誤傷了旁觀者：C++社團。它同樣傷害了許多更小的語言社團；比如Smalltalk、Lisp、Eiffel等。”

這才說到了正題上了：你Java不能欺人太甚。你可以玩你的商業花招，但不要傷及無辜。Java早期的宣傳的确是針對ms的，後來為什麼會來“踢C++的場子”，就搞不清了。

“盡管有許多Java不會取代C++的承諾（“Java會在兩年内完全幹掉C++”是1996我參加一個圖形釋出會時反複聽到的）。事實上，C++社團在Java第一次出現之時到已經翻了三倍。Java沒有真的幹掉C++，然而，通過轉移需要用于工具、庫和技術工作的精力和資金，傷害了C++社團。另一個問題是Java鼓勵一個狹隘的“純面向對象”的程式設計觀點，過分強調運作時的解析和輕視靜态類型系統（隻有在2005年Java引進了“generics”）。這導緻許多C++程式員模仿寫了許多不優雅、不安全和效率低下的代碼。當這種狹隘的觀點影響到教育，并在學生中引起對不熟悉的事物的恐懼時，這個問題就變得特别嚴重。”

說實在的，這才是真正令人擔憂的。無論是Java還是C#，總是為了商業利益，誤導着業界的技術發展。這種技術上的傷害，通常需要很多年才能逐漸恢複。就像被人類過度污染的地球，即便在人類消失後，也要過成千上萬年才能恢複原樣。而此間，無論是企業，還是個人，都會付出更大的代價。

“正如當我第一次聽到有關Java的簡單和性能的吹噓時所預測的那樣[136]，Java迅速添加新特征—有些是與C++一樣的。新的語言總自稱是“簡單”并對現實世界的應用程式是有用的，然後它們在大小和複雜度上不斷增加。不管是Java還是C++都不能擺脫這些效應。顯然，Java已經在效率上取得了很大的進步—考慮到它的最開始的緩慢，它當然會取得很大的進步—但當抽象被嚴重使用時，Java的對象模型抑制了它的性能（§ 4.1.1 ，§4.1.4）。”

抛開Bjarne自吹自擂的預測不談，其他的都是實話。一個試圖完成應用開發的語言，總會不斷地遇到擴張的需求，以滿足實際開發中的要求。就像蘇聯（俄國）人開發的武器，盡管一直宣稱要簡單、實用（實際上是他們在複雜系統，特别是電子系統方面太落後）。但随着戰場特征的改變，也不得不把成噸的電子裝置搬上坦克和飛機。這是自然規律。

“我的猜測是Java能與C++進行比較的真正力量在于它的二進制相容， Sun事實上已經通過對Java虛拟機的定義，控制了連結器。這給了Java連結相容性，那是C++社團所沒有的，因為使用基本的系統連結器和C++提供者沒有在關鍵平台上達成一緻的協定（§7.4）。”

畢竟是搞學問的人，還是肯承認一些不足的。如果能夠多談些易用性、易學性方面的比較就更好了。

7.8節 微軟和.Net，p51。

對于ms，Bjarne似乎比較客氣，但也表達了對C++/CLI的一些不滿。而且對其沒有通過ISO标準，似乎有些幸災樂禍。

第8章開始了整片文章的重頭戲（大軸）：C++0x。這也是最值得期待和最令人興奮的部分。

8.1 技術挑戰

“在C++0x開始構思時，C++社團所面對的技術挑戰是什麼？從高層次上，這個問題可以這麼回答：

  基于GUI的應用程式建構

  分而式計算（特别是web）

  安全”

這個早期清單和最終的C++0x特性清單是有很大差别的。

“從許多讨論和陳述中，我已經有了一個簡短的用于C++0x的一般目标和設計規則的總結，看起來能被廣泛接受，目标是：

  讓C++成為系統程式設計和庫建構的更好的語言—而不是提供特别的設施用于支援特定的子社團（比如，數值計算和視窗風格的應用程式開發）

  讓C++更容易教與學—通過增加統一性，更強的保證和設施支援新手（新手永遠比專家多）

經驗法則：

  提供穩定性和相容性

  優先使用庫，然後才是語言擴充

  隻做那些會改變人們思考方式的改變

  一般性優先，然後才是特化

  同時支援專家和初學者

  增加類型安全

  改進性能和直接在硬體上工作的能力

  适應現實世界。”

這些目标多少有些理想化，但是C++确實在向這方面努力。特别是“同時支援專家和初學者”，難度的确很高。但是從後面的講述來看，似乎還有些苗頭。

“這些條款中的大多數是在前面列出的“經驗法則”的指導下工作的。那個清單比委員會收到的建議（以一種強迫（至少簡要地）去考慮它們的形式）的一半還少。我從email和與使用者會議搜集到的建議是它的好幾倍。”

人們都希望C++按照自己的需要成長，把C++委員會當成許願的噴泉了。但這從另一方面也反映出開發人員對一種完善的語言的渴望（不管是否現實和合理）。

8.4節 阻礙，p61

“我的其它優先權（與更好地支援泛型程式設計一起）是更好地支援初學者。提議的顯著的趨勢是偏向老練的使用者，他們提議并評估這些提議。幫助新學者在幾個月内變成老手的簡單的東西通常被忽視。”

Bjarne不止一次地表達過這個願望，但似乎委員會更執着于“高技術”。但不管怎麼樣，至少讓我們看到有人正在為此努力。

“我希望許多起小的“障礙”不會在C++0x中出現。然而，我，Francis Glassborow還有其它的人，嘗試系統地消除許多頻繁出現的“障礙”，看起來沒有結果。”

考慮到C++的曆史包袱，以及委員會的社會責任感，（這裡先鄙視一下ms，它會随意改變産品的特性，以破壞既有的代碼），這種嘗試将會是非常困難的。我衷心地預祝，并熱切地期望他們能夠成功。

““障礙”的另一個例子是使用預設拷貝操作（構造函數或指派）去拷貝一個帶有使用者定義的析構函數的類的對象是合法的。需要使用者定義的拷貝操作将會消滅許多跟資源管理有關的肮髒的錯誤。…”

C++還有很多這類缺陷，比如，具有繼承關系的類的數組間的轉換；非虛析構函數基類上的多态等等。這些問題如果能在語言層面加以制止，C++的易用性和易學性将會有空前的提高，相關的口水仗也能緩和不少了。即便是無法一下子解決，一個個來，盡管慢些，也是利大于弊的。

8.5節 标準庫，p62

唉，看來标準gui庫肯定是沒指望了。不過新增加的庫也很大程度上緩解了壓力。但是，語言的新特性對庫的沖擊還是很大的，大部分的庫都差不多要重寫，（為了适應concept），還有新的庫，工作量确實很大。

8.6節 并發，p63

“不幸地，我不得不接受，我對直接支援分布式程式設計的希望超出了C++0x現在能做的範圍。”

看來100%完善的并發一時半會兒是得不到了。現在也沒有什麼語言能100%的解決并發問題。大家都在探索，隻是希望他們能在快些。

第9章 回顧

9.2節 标準程序的影響

“那麼最大的失誤是什麼？…。如果我們不用成為現實主義者，我們可以夢想對分布式程式設計的支援，一個主要的庫包含GUI支援（§5.5），标準平台的ABI，消除隻用于向後相容性的過分精細設計的瑕疵等。如果必須找一個出來做替罪羊的話，我認為我們應該離開語言特征和庫設施的技術領域并考慮社會因素。C++社團沒有真正的中心。…”

C++社群這種沒有中心的模式有利有弊。利在于，不會有人“霸占”整個标準，“奴役”語言的使用者，将自己的思想強加于人。弊端，則是Bjarne所提到的團結性，資源等問題。

9.4節 Beyond C++，p68

“這樣一個模型能否應用于未來的硬體、未來系統的要求和未來應用程式的要求？我認為在沒有相容性要求下，它是可以的，基于這種模型，新的語言可以比C++更小、更簡單、更具表達力和更可容易使用，沒有性能損失或應用領域的限制。多小呢？比如隻有C++定義的10%并且與前端編譯器的大小類似。在D&E[121]的回顧章節中，我表達了那樣的想法“在C++内部，有更小和更幹淨的語言要掙脫出來”。許多簡化将來自一般化—消滅許多特殊用例，這些特殊用例使得C++難以處理—而不是限制或把工作從編譯期轉移到運作期。”

這當然是人人都希望的：象C++一樣強大，象Basic一樣好用。但曆史的負擔總是很重的，我們隻能寄希望于委員會盡快地，最好是系統地消除C++的缺陷。一個複雜的C++，總比一個複雜的、帶有缺陷的C++來得好。

“這不是一個給出技術論證的地方，但我對它能被實作有信心。這樣一個語言将要求一個現實（與真實硬體相關）的機器模型（包括記憶體模型）和一個簡單對象模型。這個對象模型将類似于C++的：直接映射基本類型到機器對象并簡單組合作為抽象的基礎。這意味着以指針和數組的形式去支援“對象序列”的基本模型（類似于STL提供的）。獲得類型安全—即是說，消滅非法指針使用、範圍錯誤等的可能性—帶最小的運作時檢查是一個挑戰，但有許多對軟體、硬體和靜态分析研究，這給了我們樂觀的理由。該模型将包含真正的局部變量（對于使用者定義類型跟内建類型一樣），意味着支援“在初始化時擷取資源”風格的資源管理，它不能是“用于所有東西的廢料收集”模型，盡管毫無疑問，在大多數語言中會有廢料收集的一席之地。”

或許Bjarne應該另立門戶，開發一個新的語言。不管是否能象C++一樣成功，對于學術界都是非常有用的。隻是Bjarne是否還有這時間和精力，畢竟是50多歲的人了。

“這類語言将支援哪種程式設計？它将更好地支援什麼樣的程式設計呢？這類語言會是一個系統程式設計語言，适合于硬實時應用，裝置驅動，嵌入裝置等。我認為理想的系統程式設計語言就屬于這種一般模型—你需要靠近機器的特征，可預測的性能，（類型）安全和強大的抽象特征。其次，這類語言将是所有資源受限的應用程式的理想選擇，大多應用程式都滿足這兩條準則。這是一個巨大的并且不斷增長的應用。顯然，這個論據是對C++的力量分析的另一個變種§7.1。”

這的确令我失望。這類簡單卻又強大的語言隻能針對如此底層的系統開發。這反過來似乎也表明，一個通用的語言，如果要能夠适應大多數領域的開發，就無可避免地變得非常複雜，就像C++一樣。那麼從另一個方向而言，未來的語言是否也應該采用“語言族”的形式，類似的文法（不是象Java、C#那樣“類似”C++）、相同的程式設計模型、共享的庫、共同的ABI，但有不同的特性和側重。

或許我們可以說：“你用什麼語言？”

“我用XXX-L，你呢？”

“有時用XXX-B，有時用XXX-C。”:)

“現實世界的挑戰通過詳細說明和實作正确系統（通常在資源受限和通常在出現硬體失敗的可能性的條件下）得到滿足。我們的文明重要地依賴于軟體，而軟體的數量和複雜度在持續增長。到現在為止，我們（大型系統的建構者）通過更新檔和令人難以相信的數目的運作時測試來滿足挑戰。對于起動器，除去并發執行，我們的計算機并沒有變得更快，以彌補軟體膨脹。處理方法中我最感樂觀的是對軟體提供原則的方法，依賴更多的數學推理，更多聲明的屬性和更多對程式屬性的靜态檢驗。STL是朝那個方向（受C++限制的限制）前進的一個例子。函數式程式設計也是朝那個方向（受基本的記憶體模型與硬體不一樣和未充分利用靜态屬性的限制）前進的例子。在那個方向要有更大的進步要求語言支援想要的屬性和推理的規範說明（概念就是向那個方向的邁進的一步）。對于這類推理、運作時解析、運作時測試和多層運作時映射代碼到硬體至少是浪費和嚴重的障礙。機器接近、類型安全群組合的抽象模型是最終的力量，對推理提供最少的障礙。”

技術永遠在發展的，在我們争論語言的優劣得失的時候，是否也應該回過頭想想：無論你如何吹噓一種語言，将來總會有一種語言将其超越。重要的是我們在一種語言（比如C++，比如Java）中學到了什麼，領悟了什麼？任何一種語言，也僅僅是程式設計技術發展的長河中的一條支流。有的語言或許提供了更多的水量，有的或許隻是一條小溪。但無論如何，僅從技術的角度而言，語言的貢獻得看它把程式設計技術“朝那個方向”推進了多少。盡管商業上成功的語言，為人們帶來了财富（但很多語言實際上也帶走了不少财富，語言導緻的重複勞動和不合理的設計和代碼也不在少數），但從長遠來看，語言對技術的推動，則是更珍貴的财富。