目錄
對語言的看法
語言發展趨勢
方法和最佳實踐
展望 未來
書籍和電話
偶爾， 進化中的飛躍會迅速改善並重塑整個工程領域。 在軟件開發領域，C++ 編程語言的誕生就引發了此類飛躍。這種飛躍並非此語言本身所固 有的。在 C++ 之前即已存在面向對象的語言（如 Simula67和Smalltalk）。但由於 C++ 是在 C 編程語言的基礎上構建的（並且可編譯現有的 C 程序），因此它可將面向對象思 維的精髓帶入主流。
C++ 在軟件設計和開發方面提供了大量的靈感，從設計模式 到元編程莫不如此。並且由於其可在硬件平台間移植並具備更底層的表示，隨著硬件變得 更快更小，C++ 肯定會成中流砥柱。
我最近有幸采訪了C++ 的發明者 Bjarne Stroustrup，其間談及了多個話題：從他對語言的看法、行業的普遍發展趨勢到他個人閱 讀的書目。其中許多問題都是讀者們通過我的博客所提出的，在此特向那些提出問題的人 員表示感謝。當然，更感謝 Bjarne。
對語言的看法
Howard Dierking 為 什麼編程語言與人們之間有如此深的關聯—以至各種語言都有了自己的“追星 族”？
Bjarne Stroustrup 這個問題最好是問問心理學家、社會學家，甚至 是經濟學家，而不是一個計算機科學家！我猜想由於我們用來表達思想的語言已成為自身 的一部分，因此，如果您僅了解一門語言，則很難與其他語言的支持者進行溝通。如果是 這樣，看起來必須要精通更多的語言。我認為，如果您僅了解一門編程語言，就不可能成 為軟件領域的專家。可能還有經濟方面的原因：盡管理解基本原理可不受編程語言種類的 限制，但許多實際技巧則不一樣。因此，如果我僅了解語言 X 以及其工具集，而您贊成 語言 Y 及其工具集，那麼我們之間就會存在障礙。要想跨越這一障礙同樣需要掌握多種 語言以及工具集（並且牢固掌握基本原理）。遺憾地是，我所建議的解決方案並未考慮到 大多數人沒有多少空閒時間。那些狂熱的粉絲是特例。
HD IDE 在軟件開發中應扮 演何種角色？IDE 應如何對語言進行支持？
BS 我並不經常使用 IDE。我贊賞那些 可理解我的語言且反應迅速的 IDE 編輯器，但是也希望正常工作時不必用到 IDE。如果 性能良好的 IDE 能得以普及，我可能會改變觀點—即 IDE 實際成為語言的一部分 ，反之亦然（請參見圖 1）。我所希望的代碼可移植性在此會有用武之地。通過使用 C++ ，我希望通過源文件中的源代碼就能理解我的系統。有些 IDE 機制包含的轉換或生成代 碼非常不便於理解，我對此很不欣賞。
Figure 1The IDE Designer as a Language
HD 您是否認為無用信息或 可讀性是當今通用語言中所存在的一個問題？如果是這樣，應該怎樣解決呢？
BS 語法越簡單越好，但我猜想當大多數人在談到可讀性時，對於實際文字的抱怨並不多，表 達內容的復雜性往往招來的抱怨更多。太多人都希望能了解以任意語言編寫的任何程序， 並希望在線支持工具只提供少量幫助就可以理解用於表達程序的所有結構和程序本身的所 有邏輯。我們可以將其與查看並使用自然語言的方式做個對比。您是否希望無需背景知識 即可理解莎士比亞的十四行詩？如果遇到原始古英語寫的貝奧武夫又該怎麼辦呢？也許， 我們對於編程語言的期望過高了。對於任意特定的應用程序而言，如果任何語言所表達的 內容適用范圍很大，往往會被視為過於復雜，但是實際上語言必須要適應多種應用程序。 某一領域專用的語言只能適用於特例，但是現在我們必須面對多種語言及其交互所帶來的 復雜問題。
HD 通用語言應如何支持應用程序設計理念（如組件編程和服務編程） ？
BS 通用語言應支持編寫可表達常規和特定於應用程序概念的庫，支持工具構建 以及提供連接應用程序的不同部分所需的“粘合劑”。為此，語言需具有靈活 性、富有表現力的系統、良好的基礎性能以及長期穩定性。
HD 多重分派是否是件 好事？
BS 是的。傳統的單一分派面向對象編程語言（如 Simula、C++、 Smalltalk、Java和C#）無法完美地表達具體類型要到運行時才知道的簡單操作（如將數 字相乘或查找兩個形狀的交集）。生成代碼（由雙重分派、訪問者模式等因素確定）很慢 並且不易維護。在運行時支持多重分派的語言（如 Dylan和CLOS）要好些，而在編譯時支 持多重分派的語言（如 C++）有時效果更好。去年，我和我的一些學生一起發布了一篇有 關如何向 C++ 清晰添加多重分派的研究論文。與我們看過的所有解決方法相比，使用多 重分派時生成的代碼更短、更簡單、占用的內存更少，並且運行速度更快（請參見圖 2） 。雖然對於 C++0x 而言，該工作太晚了。您可在 research.att.com/~bs/multimethods.pdf 中找到相關的文章。
Figure 2Multiple Dispatch via Multiple Inheritance
HD 您對現在 C++ 中的協變/逆變是什麼看法？您是否希望在未來的語言版本中改變當前的行為？
BS 沒有這種想法。在該領域，我認為 C++ 充分發揮了作用。您有沒有考慮過將 vector<Apple> 轉換成 vector<Fruit> 這類示例？這樣做非常不安全，除 非 vector<Fruit> 是固定不變的（或者可向其添加 Orange）。我不認為隱式運行 時類型檢查是用於解決此類問題的好方法。
HD 相對於方法調用，您對使用消息來 傳遞關鍵語言功能是什麼看法？
BS 我喜歡顯式消息傳遞，但我僅在很久以前在分 布式系統環境中用過它。實際上，要普及它的使用，我們必須針對語言和工具做一些細致 的工作，這樣才能支持消息傳遞。我認為這方面的工作尚未完成，當然，也許是我弄錯了 。如果依賴消息和消息隊列，則可以避開許多與共享和鎖定相關的問題。我非常希望在幾 年內能看到用於此類功能的標准 C++ 庫，並且我會親自體驗一下。
HD 如果既要 支持千差萬別的諸多受眾，又要提倡改進代碼表現力和設計精致度，這對通用語言而言是 否存在固有沖突？語言在對後者的支持方面扮演著何種角色？
BS 我想從某種意義 上講，可通過特殊化來實現精致。如果您的受眾（用戶社區）很小，可投其所好，要是您 還是用戶社區的靈魂，即可撇開傳統的表示法和概念（宣稱“你需要研讀類型理論 才能使用它”）。對通用語言的要求不僅包括需支持各種用途，還包括需要讓設想 和教育背景各異的一大群人能學會（基本知識必須可供學業不精的高中生使用）。
因此，我認為只要能通過通用語言來表達完善的代碼，該語言就可提倡精益求精 。對於 C++，可編寫非常完善的代碼。使其成為通用語言的一部分並且廣泛可用，此類示 例可供大眾和讀者數量巨大的文章和課本使用。沒有哪種特殊化語言（雖然也具備完善的 代碼）可做到這些。
HD 我們是否太過強調體系結構了？
BS 沒有，至少我 定義體系結構的方式並非如此。恰好相反，對於體系結構的強調太少，而不理解結構化原 理的糟糕編碼太多了。我認為體系結構方面的主要問題是：許多程序員對於什麼能讓好編 碼發揮正常功效只有一個非常模糊的概念。看到並意識到還不夠。制定規則來確定禁止執 行的操作也不夠。我們需要連貫的法定規則。
HD 開源社區對於軟件質量、設計和 職業水准是有所幫助、有所損害還是沒有影響？
BS 這真是個很難回答的問題。我 看到過能有所幫助的情況（提高了代碼質量以及相關人員的職業水准），也遇到過有損害 的情況（教授真的很糟糕的習慣和態度），還有許多情況我也說不清。
我無法猜 想對社區產生的普遍影響，或者如果開源工作的力度更大一些或更小一些，會發生什麼情 況。對我來說，社區太大了，猜不透。
語言發展趨勢
HD 您是否認為在不 久的將來動態語言會成為焦點？
BS 應該不會。我想人們對蘋果和桔子比較得太多 了。我認為一般意義的選擇不適合靜態和動態語言，並且語言也不能嚴格地分為這兩種： 絕大部分動態語言都有需要用靜態方式確定的內容，所有主要靜態語言也都可完成需在運 行時確定值含義的操作。當然，一定會有一些我猜不出的流行趨勢；但是我認為在現實中 ，仍是根據應用程序的需求、應用領域和/或開發人員現有的技能來理性選擇語言的。例 如，我不會嘗試使用 Ruby（例如）來實現 Java 運行時，也不會用 C++ 表達交互性很強 的模擬語言（這一點與它的實現相反）。
HD 您是否認為最終刪除 void*/variant/object 這類項目是件好事？（圖 3 顯示了一個不錯的示例。）
BS 刪除所有內容包羅萬象的選項從理論上是行得通的，但在實際中，前提條件是 我們必須對要表達的所有內容進行完整分類，以便確保針對性。例如，我從未看到過實際 有函數可對每個對象執行操作；想要執行操作，始終需要對所操作的內容進行一些假定（ 我認為純粹的轉發函數是最接近計數器示例的函數）。當前在 C++ 概念方面的工作（有 關泛型算法的約束/需求）可以提供幫助，但是如果缺少一些實際的常規機制來表達 “是我確實不知道的內容”，就不能處理意外需求，我們也就無所作為。
HD 隨著松散類型語言又成為了流行趨勢，我們是否應該重新考慮匈牙利表示法？
BS 我不肯定有這種趨勢，盡管在總體工作中，適合松散類型語言的份額可能有所 增加。換句話說，雖然松散類型語言的使用率增加得更快，靜態類型語言的使用率也在增 加（我認為是這樣）。但是絕不要使用匈牙利表示法。那是個很糟糕的主意。源代碼應該 反映程序的內涵，而不是模擬類型系統。如果確實覺得需要使用匈牙利表示法，可能是使 用的語言與應用程序不搭配。
HD 在 2000 年，您做了一場講座，題目是 “C++：用於新千年的新語言”，並且介紹了Wrap<T> 這一概念。這基 本上就是面向方面的編程 (AOP)。您對 AOP 及其 Wrap<T> 模式（Pointcut、 Advice 等等）的形式化有何看法？
BS 我對於 AOP 的研究不多，因此不能給出一 個可靠的答案。我喜歡在語言中支持組合（尤其是非入侵式），而不是“不支持 ”和“通過某個工具支持”。我擔心的是超語言工具和非標准工具鏈。 C++ 模板在非入侵式組合方面極其成功 — 只需看看標准模板庫 (STL) 和一些嵌入 式系統編程中的使用情況就能了解這一點。要是進行組合時不必將概念強行放入剛性或預 先設計的層次中，那當然不錯。然而，對於某些開發人員和維護人員而言，太難於管理了 。並且太過繁重。C++0x 將嘗試在不影響靈活性和性能的情況下解決這一問題。
HD C++ 語言的某些特征可能會產生一些令人討厭的意外結果（比如宏）。您希望 C++ 或常見的流行語言能消除其他哪些意外結果？
BS 實際上，當我開始使用 C 時，我就知道宏非常令人頭疼；但是與大多數人一樣，我對它造成的麻煩和普遍的負面影 響還是估計不足。在 C 中普遍使用宏可能是十年前 C++ 開發環境不盡人意的主要原因。 並且 C++ 中初始化對象方法還太多太混亂；我希望在 C++0x 中使用統一的機制來解決該 問題。我回答上一問題時提到過模板。它們使後來的 C++（1985 年發布）取得了巨大的 成功，但對語言也有負面影響—同樣，C++0x 中有一部分內容會專門解決這一問題 。
由於兼容性原因，C++ 無法解決我們在過去所發現的許多小問題和不大不小的 問題。例如，聲明符語法沒必要這麼復雜，能說明任意線性表示法就足夠了。此外，許多 默認值也存在錯誤：構造函數不應默認為轉換，名稱不應默認為可從其他源文件訪問等等 。不能控制鏈接程序一直是問題根源；特別是實現者似乎喜歡以不兼容的形式提供類似的 功能。
當然也有意外的收獲。其中最出色的是，在與資源管理和錯誤處理（使用 異常）相關的技術中普遍使用了析構函數。我知道析構函數是個不錯的主意，因為您總會 需要用到構造函數的逆向功能—但是，對於它們在合理使用 C++ 方面的重要性，我 還不太了解。
HD 您曾在自己的網站上說道：“我認為我們應該力求完善所 構建的應用程序，而不是完善語言本身。”在域特定語言 (DSL) 方面的發展是否就 集中體現了您的這一說法？
BS 是的，這是很明確的。它經常向這個方向做嘗試。 有時甚至會達到預期的效果。
HD 您對於 DSL 的主要看法是什麼？您設想 DSL 和 通用語言之間是怎樣的一種關系？
BS 我擔心的是許多語言在設計、實現和引進時 聲勢浩大，然後就銷聲匿跡，沒有任何顯著的實效。在此期間—通常是多年的長期 開發—新語言耗費了大量資源，卻基本沒有回報。我曾寫過一篇有關此現象的文章 ，名為“語義增強庫語言的基本原理” (research.att.com/~bs/SELLrationale.pdf)。我贊成使用庫（可能通過工具來支持）和 通用語言。
我認為 DSL 應是不得已而為之的辦法，而非首選方法。如果可能的話 ，DSL 應牢牢地根植於通用語言和標准工具鏈之中。DSL 需要通用語言（或者至少是系統 編程語言）完成自身實現並實現其運行時基元。我認為最好是 DSL 有意識地與至少一門 通用語言穩定配合使用，這樣即可通過使用以通用語言編寫的庫來輕松地添加新功能。專 業人員自然應掌握多門語言，但是我擔心各種 DSL 的復雜性匯集起來可能產生問題。並 且，許多 DSL 似乎都“想”成為通用語言。
HD 您提到過由於不同硬 件存在定義的多樣性，所以 C++ 中的許多構造有意模糊不清。您有沒有發現互操作性方 面已經做出了改進，讓一些這樣的構造變得明確了？
BS 我認為“模糊不清 ”這個詞並不准確。太多東西都沒有定義或者要在實現時才定義。我想如果能從頭 重新定義 C++ 的話，它可能會沒有未定義的行為，要在實現時定義的行為也會少許多。 但是，我沒有逆轉時光的機器，也不能用現在的一組決議毀掉億萬行代碼。
方法 和最佳實踐
HD 您比較喜歡使用和傳授哪種過程方法？
BS 確定關鍵應用程 序概念，確定有用的庫，構建新庫以支持應用程序概念、盡早試驗想法、盡早集成、盡早 且經常進行測試，將文檔和教程資料用作設計工具，並且從小程序生成大程序（反復）。 顯然我剛才側重的是相對較小的項目。
HD 您有沒有發現語言和開發方法之間存在 交叉或密切關系？
BS 庫設計被視為設計/開發技術時，我認為是這樣的。通過庫 構建來關注越來越高級（更接近應用程序）的功能對語言提出了要求。我不想過分誇大這 一點，但是我認為您不能擁有用於（例如）COBOL、C、Java、C++ 以及 Python 的單個開 發方法，而又期望從每種語言獲得更多的支持。
HD 在創建軟件時，您個人有哪些 經驗法則？
BS 注重關鍵概念、它們的接口、資源（內存、文件、鎖定等等）的管 理和錯誤處理。為類設計良好的不變體和“資源獲取即初始化”(RAII) 是關 鍵技術。
HD 對於敏捷有各種說法。“敏捷”對您意味著什麼？C++ 是 否支持敏捷？
BS 我不使用這個詞，它太含糊不清。C++ 當然支持敏捷—無 論它表示什麼意思。
展望未來
HD 一種語言應如何發展才能既支持高級功 能（如模板、動態事件以及自我編寫的代碼），同時又能讓新手理解這種語言？
BS 我不知道。我想並不存在一個通用的答案。如果新功能支持更有效的技術，那 麼它們就在語言中占有重要的地位。但是，穩定性至關重要：C和C++ 保持效力的一個原 因是標准委員會要求舊代碼（通常有十年的歷史）仍然有效且可順暢地集成新功能。至少 可以說這並不太容易，並且引入新功能並不總是成功。標准委員會成員經常忽視新手因素 。為 C++0x 計劃的一些關鍵功能（如統一初始化、自動關鍵字（從其初始化表達式推斷 出變量類型）以及如檢查模板參數要求等概念）應能使語言更易於被普通人員使用。
HD 您是否將語言元數據看作未來編程語言的重要基礎？
BS 不，我個人非 常不喜歡大量使用元數據。
HD 如果 CPU 開始上升為多核，您是否認為並發性未 來會發生重大轉變？C++0x 會如何解決並發性挑戰？
BS C++0x 具備基礎：適用於 多線程的機器模型，用於構建庫的一組基礎基元以及線程和鎖定庫 API。我希望看到（可 能在今後的幾年裡）更多這類堅實的基礎，尤其是更為簡單且級別更高的並發模型，它們 以線程池、功能和消息隊列為基礎。我們需要找到自動或近似自動的方法，將計算分布到 多個處理器並在這些處理器上進行局部處理。在這一領域中已有許多模型（許多是使用的 C++），但都還不是主要模型。示例包括德克薩斯 A&M 大學的 STAPL 和英特爾的 TBB。
HD 您對圖形處理單元 (GPGPU) 方面的通用計算有什麼看法？
BS 非 常著急，但除了利用特定用途的處理器需要多種技能這一明顯現象外，我並沒有實際經驗 可做出更多評論。
HD 您是否預見高性能計算 (HPC) 最終會對編程人員透明？此 外，它是否會成為語言、庫或框架的目標？
BS 略微有些透明；我不認為並發性可 以或應該完全透明。對於初學者而言，錯誤處理可能會非常困難，具體取決於處理器的可 用性、有無共享內存、分布與否以及延遲。在適當的地方接近透明現在是並將一直是新語 言、新語言功能以及（我最喜歡的）新庫的目標。僅當底層語言提供了作為機器模型所需 的基本保證以及一組非常底層的基元，後者才可行。C++0x 將會做到這一點。
HD C++0x 的設計進展到什麼程度了？
BS 馬上要最後完工了！至少我希望如此 —在出現最終結果前，誰都預料不到會出什麼變化，越接近完成，情緒越緊張激動 。當前的計劃是在六月選出完整的新標准以供公眾評論，12 到 18 個月後出台一個正式 的新標准。我完全可以圍繞這個主題寫一本書：如何制定標准，指導方針應該是什麼以及 其中具體有些什麼？這些內容我基本都寫到了，請參閱我的 HOPL 文章“在現實世 界中不斷改進語言：C++ 1991-2006”（位置為 research.att.com/~bs/hopl- almost-final.pdf）以及我主頁文章中有關 C++0x 的所有內容。如果您的要求很高，可 在 Web 上查找“WG21”並搜索所有 ISO C++ 標准委員會的文章（包括所有建 議）。它至少可以讓您確信其中包括大量工作。改進一門使用廣泛的編程語言非常困難， 如果語言處在許多工具、語言和應用程序的實施層就更困難。您還可以在網上和我的 C++ 頁面上找到許多我和其他人提供的視頻資料。
書籍和電話
HD 您目前在看 什麼書？
BS 技術資料方面，我重讀了Hennessy和Patterson 撰寫的計算機體系結 構方面的書，還在努力收集可以幫助人們編寫出色代碼的文章和書籍（我正在教的一門課 也能用到）。查找此類文章的難度超出了我的想象；學術文章太過專業化，而非學術文章 往往說得好聽，實際作用又不大（歡迎提供建議）。當然，我還讀些 C++ 標准化方面的 文章。我原准備重讀 Knuth，但由於有人偷偷拿走了我的第 III 卷，所以只好再等等。 我還將再讀一遍 O'Brian 的 Aubrey和Maturin 系列，就當是個消遣。為了加深對科 學的理解，目前打算拜讀 Richard Dawkins。我最近還讀完了Rodger 的《Command of the Ocean:A Naval History of Britain, 1649-1815》（因此准備讀 O'Brian 的書 ）。
HD 您曾說過：“我過去常常希望我的計算機能像電話一樣容易使用； 現在這個願望終於實現了，我不用再費心研究電話用法了。”您有智能電話嗎？它 的操作更簡單了嗎？
BS 我並不太熱衷使用電話。我更喜歡面對面的交流，如果無 法面對面，用書面文字也行。即便最炫的電話也比不上一封措辭完美的電子郵件。我使用 是一款很薄並且小巧玲珑的手機，但是它的大部功能我都用不上。聲音質量和可靠性也很 不盡人意。公平地講，現在的用戶界面比我說出那番言論時要好得多了。
