知識星球
https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
作者 | Thomas Claburn
譯者 | qhwdw ?共計翻譯：154.5 篇 貢獻時間：369 天
今年早些時候，我們對 Bjarne Stroustrup 進行了採訪。他是 C++ 語言的創始人，摩根士丹利技術部門的董事總經理，美國哥倫比亞大學電腦科學的客座教授。他寫了一封信[1]，請那些關註程式語言進展的人去“想想瓦薩號！”
這句話對於丹麥人來說，毫無疑問，很容易理解。而那些對於 17 世紀的斯堪的納維亞歷史瞭解不多的人，還需要詳細說明一下。瓦薩號是一艘瑞典軍艦，由國王 Gustavus Adolphus 定做。它是當時波羅的海國家中最強大的軍艦，但在 1628 年 8 月 10 日首航沒幾分鐘之後就沉沒了。
巨大的瓦薩號有一個難以解決的設計缺陷：頭重腳輕，以至於它被一陣狂風刮翻了[2]。透過援引這艘沉船的歷史，Stroustrup 警示了 C++ 所面臨的風險 —— 現在越來越多的特性被新增到了 C++ 中。
我們現在已經發現了好些能導致頭重腳輕的特性。Stroustrup 在他的信中取用了 43 個提議。他認為那些參與 C++ 語言 ISO 標準演進的人（即所謂的 WG21 小組[3]）正在努力推進語言發展，但成員們的努力方向卻並不一致。
在他的信中，他寫道：
分開來看，許多提議都很有道理。但將它們綜合到一起，這些提議是很愚蠢的，將危害 C++ 的未來。
他明確表示，他用瓦薩號作為比喻並不是說他認為不斷提升會帶來毀滅。我們應該吸取瓦薩號的教訓，構建一個堅實的基礎，從錯誤中學習並對新版本做徹底的測試。
在瑞士拉普斯威爾召開 C++ 標準化委員會會議之後，本月早些時候，Stroustrup 接受了 The Register 的採訪，回答了有關 C++ 語言下一步發展方向的幾個問題。（最新版是去年剛釋出的 C++17；下一個版本是 C++20，預計於 2020 年釋出。）
Register：在您的信件《想想瓦薩號！》中，您寫道：
在 C++11 開始的基礎建設尚未完成，而 C++17 基本沒有在使基礎更加穩固、規範和完整方面做出改善。相反，卻增加了重要介面的複雜度（原文為 surface complexity，直譯“錶面複雜度”），讓人們需要學習的特性數量越來越多。C++ 可能在這種不成熟的提議的重壓之下崩潰。我們不應該花費大量的時間為專家級使用者們（比如我們自己）去建立越來越複雜的東西。（還要考慮普通使用者的學習曲線，越複雜的東西越不易普及。）
對新人來說，C++ 過難了嗎？如果是這樣，您認為怎樣的特性讓新人更易理解？
Stroustrup：C++ 的有些東西對於新人來說確實很具有挑戰性。
另一方面而言，C++ 中有些東西對於新人來說，比起 C 或上世紀九十年代的 C++ 更容易理解了。而難點是讓大型社群專註於這些部分，並且幫助新手和非專業的 C++ 使用者去規避那些對高階庫實現提供支援的部分。
我建議使用 C++ 核心準則[4]作為實現上述標的的一個輔助。
此外，我的“C++ 教程”也可以幫助人們在使用現代 C++ 時走上正確的方向，而不會迷失在自上世紀九十年代以來的複雜性中，或困惑於只有專家級使用者才能理解的東西中。這本即將出版的第二版的“C++ 教程”涵蓋了 C++17 和部分 C++20 的內容。
我和其他人給沒有程式設計經驗的大一新生教過 C++，只要你不去深入程式語言的每個晦澀難懂的角落，把註意力集中到 C++ 中最主流的部分，就可以在三個月內學會 C++。
“讓簡單的東西保持簡單”是我長期追求的標的。比如 C++11 的 range-for 迴圈：
for (int& x : v) ++x; // increment each element of the container v
v 的位置可以是任何容器。在 C 和 C 風格的 C++ 中，它可能看起來是這樣：
for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v
一些人抱怨說添加了 range-for 迴圈讓 C++ 變得更複雜了，很顯然，他們是正確的，因為它添加了一個新特性。但它卻讓 C++ 用起來更簡單，而且同時它還消除了使用傳統 for 迴圈時會出現的一些常見錯誤。
另一個例子是 C++11 的標準執行緒庫。它比起使用 POSIX 或直接使用 Windows 的 C API 來說更簡單，並且更不易出錯。
Register：您如何看待 C++ 現在的狀況？
Stroustrup：C++11 中作出了許多重大改進，並且我們在 C++14 上全面完成了改進工作。C++17 添加了相當多的新特性，但是沒有提供對新技術的很多支援。C++20 目前看上去可能會成為一個重大改進版。編譯器的狀況非常好，標準庫實現得也很優秀，非常接近最新的標準。C++17 現在已經可以使用，對於工具的支援正在逐步推進。已經有了許多第三方的庫和好些新工具。然而，不幸的是，這些東西不太好找到。
我在《想想瓦薩號！》一文中所表達的擔憂與標準化過程有關，對新東西的過度熱情與完美主義的組合推遲了重大改進。“追求完美往往事與願違”。在六月份拉普斯威爾的會議上有 160 人參與；在這樣一個數量龐大且多樣化的人群中很難取得一致意見。專家們也本來就有隻為自己設計語言的傾向，這讓他們不會時常在設計時考慮整個社群的需求。
Register：C++ 是否有一個理想的狀態，或者與之相反，您只是為了程式員們的期望而努力，隨時適應並且努力滿足程式員們的需要？
Stroustrup：二者都有。我很樂意看到 C++ 支援徹底保證型別安全和資源安全的程式設計方式。這不應該透過限制適用性或增加效能損耗來實現，而是應該透過改進的表達能力和更好的效能來實現。透過讓程式員使用更好的（和更易用的）語言工具可以達到這個標的，我們可以做到的。
終極標的不會馬上實現，也不會單靠語言設計來實現。為了實現這一標的，我們需要改進語言特性、提供更好的庫和靜態分析，並且設立提升程式設計效率的規則。C++ 核心準則是我為了提升 C++ 程式碼質量而實行的廣泛而長期的計劃的一部分。
Register：目前 C++ 是否面臨著可以預見的風險？如果有，它是以什麼形式出現的？（如，迭代過於緩慢，新興低階語言，等等……據您的觀點來看，似乎是提出的提議過多。）
Stroustrup：就是這樣。今年我們已經收到了 400 篇文章。當然了，它們並不都是新提議。許多提議都與規範語言和標準庫這一必需而乏味的工作相關，但是量大到難以管理。你可以在 WG21 網站[5]上找到所有這些文章。
我寫了《想想瓦薩號！》這封信作為一個呼籲，因為這種為瞭解決即刻需求（或者趕時髦）而不斷增添語言特性，卻對鞏固語言基礎（比如，改善靜態型別系統）不管不問的傾向讓我感到震驚。增加的任何新東西，無論它多小都會產生成本，比如實現、學習、工具升級。重大的特性改變能夠改變我們對程式設計的想法，而它們才是我們必須關註的東西。
委員會已經設立了一個“指導小組”，這個小組由在語言、標準庫、實現、以及工程實踐領域中擁有不錯履歷的人組成。我是其中的成員之一。我們負責為重點領域寫一些關於發展方向、設計理念和建議重點發展領域的東西[6]。
對於 C++20，我們建議去關註：
在拉普斯威爾會議之後，這些都有了實現的機會，雖然模組和網路化都不是會議的重點討論物件。我是一個樂觀主義者，並且委員會的成員們都非常努力。
我並不擔心其它語言或新語言會取代它。我喜歡程式語言。如果一門新的語言提供了獨一無二的、非常有用的東西，那它就是我們的榜樣，我們可以向它學習。當然，每門語言本身都有一些問題。C++ 的許多問題都與它廣泛的應用領域、大量的使用人群和過度的熱情有關。大多數語言的社群都會有這樣的問題。
Register：關於 C++ 您是否重新考慮過任何架構方面的決策？
Stroustrup：當我著手規劃新版本時，我經常反思原來的決策和設計。關於這些，可以看我的《程式設計的歷史》論文第 1[7]、2[8] 部分。
並沒有讓我覺得很後悔的重大決策。如果我必須重新做一次，我覺得和以前做的不會有太大的不同。
與以前一樣，能夠直接處理硬體加上零開銷的抽象是設計的指導思想。使用建構式和解構式去處理資源是關鍵（資源獲取即初始化，RAII）；標準模板庫（STL） 就是解釋 C++ 庫能夠做什麼的一個很好的例子。
Register：在 2011 年被採納的每三年釋出一個新版本的節奏是否仍然有效？我之所以這樣問是因為 Java 已經決定更快地迭代。
Stroustrup：我認為 C++20 將會按時釋出（就像 C++14 和 C++17 那樣），並且主流的編譯器也會立即採用它。我也希望 C++20 基於 C++17 能有重大的改進。
對於其它語言如何管理它們的版本，我並不十分關心。C++ 是由一個遵循 ISO 規則的委員會來管理的，而不是由某個大公司或某種“終生的仁慈獨裁者（BDOL）”來管理。這一點不會改變。C++ 每三年釋出一次的週期在 ISO 標準中是一個引人註目的創舉。通常而言，週期應該是 5 或 10 年。
Register：在您的信中您寫道：
我們需要一個能夠被“普通程式員”使用的，條理還算清楚的程式語言。他們主要關心的是，能否按時高質量地交付他們的應用程式。
改進語言能夠解決這個問題嗎？或者，我們還需要更容易獲得的工具和教育支援？
Stroustrup：我儘力宣傳我關於 C++ 的實質和使用方式的理念[9]，並且我鼓勵其他人也和我採取相同的行動。
特別是，我鼓勵講師和作者們向 C++ 程式員們提出有用的建議，而不是去示範複雜的示例和技術來展示他們自己有多高明。我在 2017 年的 CppCon 大會上的演講主題就是“學習和傳授 C++”，並且也指出，我們需要更好的工具。
我在演講中提到了構建技術支援和包管理器，這些歷來都是 C++ 的弱項。標準化委員會現在有一個工具研究小組，或許不久的將來也會組建一個教育研究小組。
C++ 的社群以前是十分無組織性的，但是在過去的五年裡，為了滿足社群對新聞和技術支援的需要，出現了很多集會和部落格。CppCon、isocpp.org、以及 Meeting++ 就是一些例子。
在一個龐大的委員會中做語言標準設計是很困難的。但是，對於所有的大型專案來說，委員會又是必不可少的。我很憂慮，但是關註它們並且面對問題是成功的必要條件。
Register：您如何看待 C++ 社群的流程？在溝通和決策方面你希望看到哪些變化？
Stroustrup：C++ 並沒有企業管理一般的“社群流程”；它所遵循的是 ISO 標準流程。我們不能對 ISO 的條例做大的改變。理想的情況是，我們設立一個小型的、全職的“秘書處”來做最終決策和方向管理，但這種理想情況是不會出現的。相反，我們有成百上千的人線上討論，大約有 160 人在技術問題上進行投票，大約有 70 組織和 11 個國家的人在最終提議上正式投票。這樣很混亂，但是有些時候它的確能發揮作用。
Register：在最後，您認為那些即將推出的 C++ 特性中，對 C++ 使用者最有幫助的是哪些？
Stroustrup：
此外：
Register：您還有想對讀者們說的話嗎？
Stroustrup：如果 C++ 標準化委員會能夠專註於重大問題，去解決重大問題，那麼 C++20 將會非常優秀。但是在 C++20 推出之前，我們還有 C++17；無論如何，它仍然遠超許多人對 C++ 的舊印象。®
via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/
作者：Thomas Claburn[11] 選題：lujun9972 譯者：qhwdw 校對：thecyanbird、Northurland、pityonline
本文由 LCTT 原創編譯，Linux中國 榮譽推出