歡迎光臨
每天分享高質量文章

對 C++ 的憂慮?C++ 創始人警告:關於 C++ 的某些未來計劃十分危險 | Linux 中國

Bjarne Stroustrup 是 C++ 語言的創始人,他寫了一封信,請那些關註編程語言進展的人去“想想瓦薩號!”
— Thomas Claburn

 

 

 

致謝
編譯自 | 
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++ 的未來。

他明確表示,他用瓦薩號作為比喻並不是說他認為不斷提升會帶來毀滅。我們應該吸取瓦薩號的教訓,構建一個堅實的基礎,從錯誤中學習並對新版本做徹底的測試。

在瑞士拉普斯威爾Rapperswill召開 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 迴圈:

  1. for (int& x : v) ++x; // increment each element of the container v

v 的位置可以是任何容器。在 C 和 C 風格的 C++ 中,它可能看起來是這樣:

  1. for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v

一些人抱怨說添加了 range-for 迴圈讓 C++ 變得更複雜了,很顯然,他們是正確的,因為它添加了一個新特性。但它卻讓 C++ 用起來更簡單,而且同時它還消除了使用傳統 for 迴圈時會出現的一些常見錯誤。

另一個例子是 C++11 的標準執行緒庫standard thread library。它比起使用 POSIX 或直接使用 Windows 的 C API 來說更簡單,並且更不易出錯。

Register:您如何看待 C++ 現在的狀況?

Stroustrup:C++11 中作出了許多重大改進,並且我們在 C++14 上全面完成了改進工作。C++17 添加了相當多的新特性,但是沒有提供對新技術的很多支持。C++20 目前看上去可能會成為一個重大改進版。編譯器的狀況非常好,標準庫實現得也很優秀,非常接近最新的標準。C++17 現在已經可以使用,對於工具的支持正在逐步推進。已經有了許多第三方的庫和好些新工具。然而,不幸的是,這些東西不太好找到。

我在《想想瓦薩號!》一文中所表達的擔憂與標準化過程有關,對新東西的過度熱情與完美主義的組合推遲了重大改進。“追求完美往往事與願違”。在六月份拉普斯威爾的會議上有 160 人參與;在這樣一個數量龐大且多樣化的人群中很難取得一致意見。專家們也本來就有隻為自己設計語言的傾向,這讓他們不會時常在設計時考慮整個社區的需求。

Register:C++ 是否有一個理想的狀態,或者與之相反,您只是為了程式員們的期望而努力,隨時適應並且努力滿足程式員們的需要?

Stroustrup:二者都有。我很樂意看到 C++ 支持徹底保證型別安全type-safe資源安全resource-safe的編程方式。這不應該通過限制適用性或增加性能損耗來實現,而是應該通過改進的表達能力和更好的性能來實現。通過讓程式員使用更好的(和更易用的)語言工具可以達到這個標的,我們可以做到的。

終極標的不會馬上實現,也不會單靠語言設計來實現。為了實現這一標的,我們需要改進語言特性、提供更好的庫和靜態分析,並且設立提升編程效率的規則。C++ 核心準則是我為了提升 C++ 代碼質量而實行的廣泛而長期的計劃的一部分。

Register:目前 C++ 是否面臨著可以預見的風險?如果有,它是以什麼形式出現的?(如,迭代過於緩慢,新興低級語言,等等……據您的觀點來看,似乎是提出的提議過多。)

Stroustrup:就是這樣。今年我們已經收到了 400 篇文章。當然了,它們並不都是新提議。許多提議都與規範語言和標準庫這一必需而乏味的工作相關,但是量大到難以管理。你可以在 WG21 網站[5]上找到所有這些文章。

我寫了《想想瓦薩號!》這封信作為一個呼籲,因為這種為瞭解決即刻需求(或者趕時髦)而不斷增添語言特性,卻對鞏固語言基礎(比如,改善靜態型別系統static type system)不管不問的傾向讓我感到震驚。增加的任何新東西,無論它多小都會產生成本,比如實現、學習、工具升級。重大的特性改變能夠改變我們對編程的想法,而它們才是我們必須關註的東西。

委員會已經設立了一個“指導小組”,這個小組由在語言、標準庫、實現、以及工程實踐領域中擁有不錯履歷的人組成。我是其中的成員之一。我們負責為重點領域寫一些關於發展方向、設計理念和建議重點發展領域的東西[6]

對於 C++20,我們建議去關註:

◈ 概念
◈ 模塊(適度地模塊化並帶來編譯時的顯著改進)
◈ Ranges(包括一些無限序列的擴展)
◈ 標準庫中的網絡概念

在拉普斯威爾會議之後,這些都有了實現的機會,雖然模塊和網絡化都不是會議的重點討論物件。我是一個樂觀主義者,並且委員會的成員們都非常努力。

我並不擔心其它語言或新語言會取代它。我喜歡編程語言。如果一門新的語言提供了獨一無二的、非常有用的東西,那它就是我們的榜樣,我們可以向它學習。當然,每門語言本身都有一些問題。C++ 的許多問題都與它廣泛的應用領域、大量的使用人群和過度的熱情有關。大多數語言的社區都會有這樣的問題。

Register:關於 C++ 您是否重新考慮過任何架構方面的決策?

Stroustrup:當我著手規劃新版本時,我經常反思原來的決策和設計。關於這些,可以看我的《編程的歷史》論文第 1[7]2[8] 部分。

並沒有讓我覺得很後悔的重大決策。如果我必須重新做一次,我覺得和以前做的不會有太大的不同。

與以前一樣,能夠直接處理硬體加上零開銷的抽象是設計的指導思想。使用建構式constructor解構式destructor去處理資源是關鍵(資源獲取即初始化Resource Acquisition Is Initialization,RAII);標準模板庫Standard Template Library(STL) 就是解釋 C++ 庫能夠做什麼的一個很好的例子。

Register:在 2011 年被採納的每三年發佈一個新版本的節奏是否仍然有效?我之所以這樣問是因為 Java 已經決定更快地迭代。

Stroustrup:我認為 C++20 將會按時發佈(就像 C++14 和 C++17 那樣),並且主流的編譯器也會立即採用它。我也希望 C++20 基於 C++17 能有重大的改進。

對於其它語言如何管理它們的版本,我並不十分關心。C++ 是由一個遵循 ISO 規則的委員會來管理的,而不是由某個大公司或某種“終生的仁慈獨裁者Beneficial Dictator Of Life(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:

◈ 那些能讓編程顯著變簡單的概念。
◈ 並行演算法Parallel algorithms —— 如果要使用現代硬體的併發特性的話,這方法再簡單不過了。
◈ 協程Coroutines,如果委員會能夠確定在 C++20 上推出。
◈ 改進了組織原始碼方式的,並且大幅改善了編譯時間的模塊。我希望能有這樣的模塊,但是還沒辦法確定我們能不能在 C++20 上推出。
◈ 一個標準的網絡庫,但是還沒辦法確定我們能否在 C++20 上推出。

此外:

◈ Contracts(運行時檢查的先決條件、後置條件、和斷言)可能對許多人都非常重要。
◈ date 和 time-zone 支持庫可能對許多人(行業)非常重要。

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 校對:thecyanbirdNorthurlandpityonline

本文由 LCTT 原創編譯,Linux中國 榮譽推出

 

    赞(0)

    分享創造快樂