歡迎您光臨本站 註冊首頁

Linus說...

←手機掃碼閱讀     火星人 @ 2014-03-22 , reply:0

Linux內核的創始人Linus Torvalds最 近在一封郵件中說明了內核開發需要使用C語言而非C++的理由。
Name: Linus Torvalds (torvalds@linux-foundation.org) 6/8/10

anon2 (anon@anons.com) on 6/8/10 寫道:
>
>效率對於內核的開發是個至關重要的問題。
>大部分志願者為內核貢獻代碼,所以在相
>同條件下,使用更高效的語言能讓你的工
>作效率提升,從而更快更出色的完成開發。

事實上,你錯了

志願者貢獻的代碼很優秀,而且他們似乎沒有覺得語言的效率是個障礙。如果改換語言真的能提高效率,那麼這將是使大眾受益的事情——不僅僅是經濟方面 的。一行行的寫代碼,而不和用戶交流,即使使用再有效率的語言都是無用的,很多大型項目都有這個問題的。

內核方面,我們有大約1000個志願者者為每一個內核的釋出做著貢獻(3個月前統計的結果)。現在有更多的人加入,但是我更為擔心的不是代碼,而是 編碼方面的持續性和linux內核的發展方向。現在,我已不寫代碼很多年。我目前主管志願者的代碼是否進入內核,如果代碼可以進入內核,我就說ok,進去 吧;如果不能,我就說No——當然這種情況比較少。

如果想做好一個產品,最重要的就是要與客戶進行交流。內核的編寫也是如此,缺乏交流是整個項目的瓶頸……避免交流缺失最好的辦法就是擁有共同的 「culture」(信仰吧……),或者擁有共同的默契感(原文:潛規則,汗之~)。我們有很多文檔指導人們如何去做以及怎樣去做,但是在不同文化背景的 人們面前,這些文檔是那麼蒼白無力……

(有很多書在介紹文化,你甚至可以在大學取得一個相關的PhD學位,然後窮極一生去學習,但是,但是你卻從來沒有深入了解過自己……)

c語言呢,也有自己的「文化」(Unix也是如此——讓我想起了KISS)。一個語言,就應該簡單而明確,而不是複雜冗餘。c++有一個絕對讓我不 爽的「特性」—— context-dependent,這只是意味著, 當你閱讀代碼時,本地視圖(local view)卻不能給你任何幫助。

這,在交流上可是個大問題……在龐大的項目中,人們對不是自己開發的模塊並不了解,能快速理解其他模塊中函數的確切含義才能提高開發效率,而C++ 引入的各種抽象則使代碼變得晦澀難讀。

如果你想提交代碼(或者補丁),是不是感覺 「sctp_connect()」 比 「connect()」 簡潔而且明了呢?(匈牙利命名?) ,剩下的交給編譯器吧,編譯器能知道你寫的是sctp協議模塊的,並完成一切。

項目開發中,我們盡量使用補丁和分支,郵件列表等形式,而不是對源碼進行整體修改,這是因為唯一重要的在於改變,而不是結果。所以,這也是我們避免 歧義和代碼關聯性(context)的根本原因。——尤其是在內核項目上,絕對不能有半點馬虎。絕大多數軟體工程上都是如此,其實在日常交往中也應該如 此:說話含糊不正常的得不到好處。

因此,一個語言應該簡單而明確。你不必顧慮過多,也不用學習冗長的語法和你不需要的東西。如果每個人都是項目專家,那麼隱含方式調用函數 (implicit context)是個不錯的主意——這就是為什麼真正深奧的科學文獻,基本上都是晦澀難懂的,除非你是一個專家,擁有大量的背景知識以及要素,才能有所了 解。但是如果是一個多人參與的大型項目,呃,這幾乎是不可能的。

例如,我非常了解 VM 部分的代碼,但我仍然需要讀取各文件系統和網路的代碼。即使像我這樣了解的人,仍然把代碼寫的簡明扼要,絕不會有任何「隱藏代碼」。c就是這樣一個語言, 讀代碼,就能知道它的作用。一個函數用來做一件事,而這個函數也只作這一件事情,不會再出現一些「微妙的問題」——這是「哪個版本的一個函數調用」。

這也就是為什麼我認為c語言「簡約而不簡單」——尤其是對於一個os的內核來說,尤為重要;在特定的編程或系統亦是如此。這也是為什麼我不認為在所 有項目中c都適合的原因。

不過,c++……我真得不認為它有什麼出色的地方。垃圾回收和併發等等,這些才是真正重要的特性。可是c++……完全落在了c後邊……

linus

(業餘翻譯,不當之處懇請指出,謝謝!)
原文: http://www.realworldtech.com/for ... did=110549&roomid=2
譯 者:delectate

[火星人 ] Linus說...已經有354次圍觀

http://coctec.com/news/soft/show-post-85140.html