【譯】「綠色」和「棕色」的編程語言

「綠色」 和 「棕色」 的編程語言

數據

Stack Overflow 的開發者調查 1 結果是瞭解開發者工做狀況的重要信息來源。最近我分析了 2020 年的調查結果,但願以此肯定咱們應該在集成發行版的文檔裏添加什麼語言。我發現了一些關於人們喜好哪一種編程語言的有趣結論,而這些結論彷佛在不少關於編程語言偏好的討論中都沒有出現。前端

調查結果包含了最使人畏懼的編程語言最受歡迎的編程語言這兩組排名。它們來自同一個問題:android

在過去的一年裏,你主要的開發工做是用哪種編程、腳本和標記語言完成的?在接下來的一年裏,你又想用哪種語言工做呢?(若是你已經在用這種語言工做並且但願能繼續使用,請在那一行把兩個框都勾上。)ios

使人畏懼的語言指的是你今年主要在用但不想再繼續用下去的語言,而受歡迎的語言則指的是你主要在用並且但願繼續使用的語言。這些結果頗有趣,由於它們反映的觀點來自主要使用這種語言的開發者們,應該不會受到 「我據說很棒」 這種心理的影響,也就是說,人們不會僅僅由於語言熱門就給他們並不使用的語言打很高的分數。反之亦然:把語言放在使人畏懼列表上的也是正在使用它們的人。他們懼怕這種語言不是由於據說它很複雜,而是確實在使用它的過程當中感到痛苦。git

最使人畏懼的語言榜單 TOP 15:github

VBA、Objective-C、Perl、Assembly、C、PHP、Ruby、C++、Java、R、Haskell、Scala、HTML、Shell 和 SQL。web

最受歡迎的語言榜單 TOP 15:編程

Rust、TypeScript、Python、Kotlin、Go、Julia、Dart、C#、Swift、JavaScript、SQL、Shell、HTML、Scala 和 Haskell。後端

這個列表蘊含了某種規律,你能發現嗎?性能優化

在我參與以前寫的代碼是最糟糕的

舊的代碼是最糟的。若是讓你從一個已經開發了三年以上的代碼庫裏給我找一個文件,你會發現很難追蹤。最初只是一個很直接的文件獲取層,卻在開發過程當中逐漸加入了特殊案例、性能優化以及各類由設置選項控制的分支。真實世界中的代碼須要根據市場需求進行迭代,而在迭代的過程當中,它就變得更加複雜且難以理解。這種現象背後的緣由很簡單,我最初是從 Joel Spolsky 口中聽到的。markdown

開發者們認爲舊代碼一團糟的緣由能夠追溯到一個最基本的編程法則:閱讀代碼比寫代碼要難

—— Joel Spolsky,Things You Should Never Do, Part I

咱們能夠把它稱爲 Joel 定律。不少事情都聽從這個前提。爲何大多數開發者認爲他們接手的代碼是一團糟,還想要把它們刪掉重寫?這是由於從認知層面來講,寫新的程序要比閱讀寫好的代碼庫輕鬆不少,至少在最開始是這樣。爲何不少重寫工做都難逃失敗的厄運?由於大部分讓代碼看上去亂七八糟的語句其實是相當重要的細微提高,這些提高是隨着時間推移慢慢累積的。若是毫無規劃地精簡這些代碼,你最後就不得不回到起點。

漫畫做者:Scott Adams。
漫畫中的對話內容:① 我接手的項目代碼很糟糕。我須要從頭開始從新寫一遍。② 難道就沒有一名工程師會說:「上一位夥計作的很棒。讓咱們把他的工做保留下來」?③ 但願你招過來取代個人白癡會這麼說。

理解你正在寫的代碼是件很容易的事。你在不斷地執行和改進這些代碼。可是僅靠閱讀去理解已經寫完的代碼就比較困難了。若是你回看本身寫過的舊代碼並發現它很難理解,這多是由於你做爲一名開發者已經有所成長,可以把它寫得更好。可是也有可能代碼自己就很複雜,可你卻把理解這種複雜性的痛苦歸咎於代碼自己的質量問題。這會是 PR 持續積壓問題的誘因嗎?PR 檢查是一項只讀的工做,若是你腦中沒有一個當前代碼的運轉模型,你就很難把它作好。

這就是你懼怕它的緣由

若是不少現實世界的代碼會被冤枉成一團亂麻,編程語言也會被冤枉嗎?若是你用 Go 寫新的程序,卻不得不維護一個有 20 年曆史、十分龐雜的 C++ 代碼庫,你能把這兩種語言公正地排名嗎?我認爲這就是調查問卷實際上在評估的:使人畏懼的語言一般被用於已存在的棕地項目 5,而受歡迎的語言則更多被用於嶄新的綠地項目 6。讓咱們驗證這一點。2

衡量棕色和綠色的語言

TIOBE 指數宣稱能夠經過「全世界範圍內熟練的工程師、課程和崗位的數量」衡量編程語言。他們度量的方式可能會有些問題,但其準確度對咱們的目標而言已經足夠了。咱們用了 2016 年 7 月份的 TIOBE 指數(這是在 Wayback Machine 中能得到的最先的數據)做爲已有大量須要維護的代碼的編程語言的表明。若是說 2016 年有什麼很大的數據,比起對應的語言在 2016 年並不流行的假設,更有多是人們在維護用這種語言編寫的程序。

他們給出的 2016 年 7 月份編程語言排行榜的前 20 名是:Java,C,C++,Python,C#,PHP,JavaScript,VB.NET,Perl,Assembly,Ruby,Pascal,Swift,Objective-C,MATLAB,R,SQL,COBOL 和 Groovy。咱們能夠把這個排行做爲更多被用於維護工做的語言清單。並把這些語言稱爲「棕色語言」。在 2016 年並未躋身 top 20 的語言則更多地被用於新的項目。咱們把這些語言稱爲「綠色語言」。

圖表1

在使人畏懼和受歡迎這兩個列表中出現的 22 種語言裏,63% 是棕色語言。

棕色語言:在維護已有軟件(即棕地項目)時更經常使用的語言。

Java、C、C++、C#、Python、PHP、JavaScript、Swift、Perl、Ruby、Assembly、R、Objective-C 和 SQL

綠色語言:在新項目(即綠地項目)中更經常使用的語言。

Go、Rust、TypeScript、Kotlin、Julia、Dart、Scala 和 Haskell

TIOBE 和 Stack Overflow 在什麼是編程語言這一問題上有分歧。爲了解決這個問題,咱們須要把 HTML/CSS,Shell 腳本和 VBA 從兩個榜單上移除來實現標準化。3

移除的語言:TIOBE 和 Stack Overflow 在這些語言上存在分歧。

VBA, Shell, HTML/CSS

這種簡單的綠色 / 棕色一刀切的分割方式會丟失不少細節,好比我預計用 Swift 寫的綠地項目比用 Objective-C 寫的更多,但它看上去確實能有效反映咱們所需的信息。表單上棕色語言比綠色語言多得多,但考慮到編程語言每一年的排名變化相對較小,這也不出我所料。

如今咱們能夠回答這個問題了:人們是真的像他們說的那樣喜好和懼怕編程語言自己仍是僅僅在懼怕經年累月的代碼?或者換一種說法:若是 Java 和 Ruby 出如今今天,沒有那麼多舊框架的 app 和舊的企業級 Java 應用要維護,它們是否仍然面目可憎?或者,它們是否更有可能出如今受歡迎的列表當中?

使人畏懼的棕色編程語言

圖表2

使人畏懼的語言:83% 是棕色的。

最使人畏懼的語言幾乎都是棕色的。在咱們統計的所有語言中,有 68% 是棕色的,然而在使人畏懼的語言中這一比例達到了 83%,這比隨機分配的比例要高。

受歡迎的綠色編程語言

圖表3

受歡迎的編程語言:54% 是綠色的。

在最受歡迎的語言中,54% 是綠色的。在咱們統計的語言中只有 36% 是綠色,並且每一種綠色的編程語言都在受歡迎榜單中佔有一席之地。

人性的另外一個缺點即是,人人都想新建而沒人願意維護。

—— Kurt Vonnegut

這可能不足以說明人們的恐懼來源是必須用這種語言來維護項目,但它看上去確實是一個誘因。不少人們喜好的編程語言都太年輕或沒有長時間流行,於是沒有那麼多臃腫的項目要維護。

換句話說,Rust,Kotlin,還有其餘綠色編程語言可能仍處於蜜月期。人們對用這些語言工做的好感可能與沒必要維護有 20 年曆史的代碼庫有極大的關係,不像某些特定的語言必須維護歷史悠久的代碼庫。

打敗偏見

天使與惡魔

一些新興的或之前並不流行的語言有可能比老舊或更加主流的語言要好,可是咱們的判斷彷佛被偏見左右了。實際上,開發者們爲新興的或者過去不經常使用的語言戴上光環,把它們看作天使,而爲已經使用過更長時間的語言插上角,把它們視爲惡魔。我認爲這是由於沒人想維護其餘人的工做。何況,正如 Joel 定律所描述的那樣:閱讀實際存在的代碼很困難。創建新事物頗有趣,而新興語言則更多地被用於這種有趣的工做。

編程語言風評的生命週期

我最開始深挖這些數據,是爲了發佈一個編程語言經常使用性和在開發者中的受歡迎度的排行榜。我原本打算用這些結論做爲指導,給咱們的文檔構建樣例添加示例。然而我卻在中途產生了一些關於編程語言生命週期的想法:受歡迎的編程語言常常被使用,這就帶來了代碼維護工做,而維護工做會讓人們討厭這門語言,因而人們就開始尋找更加嶄新的項目、嘗試更新穎的語言。流行的框架大概也符合這一輩子命週期。

風評曲線

編程語言風評的生命週期

對於這張圖表,我並無數據,可是我清楚地記得 Ruby 在 2007 年是最熱門的語言,即使如今它有了更多的競爭對手,Ruby 也比以前要好得多。然而,它如今卻變得遭人嫌棄了。對我而言,其中一點區別彷佛是如今人們有了這 14 年產出的諸多應用要維護。這讓 Ruby 的趣味性大減,與全是新項目的時期不可同日而語。因此請警戒 Rust、Kotlin、Julia 和 Go:你最終也將親手取下你爲它們戴上的光環。4


  1. 2020 年的圖形化原始結果。

  2. 我最早提出這個標準。我並無爲支撐個人觀點尋找數據。

    我確實考慮過用語言的誕生日來區分綠色和棕色語言,但有些語言已經存在一段時間了卻只在最近纔開始投入使用。

    TIOBE 度量用的是這種方法,並且他們的歷史數據是須要付費獲取的,因此我就使用了 Wayback Machine。

  3. TIOBE 並未計量 HTML/CSS,由於它認爲這些語言並無向完備發展因此不是編程語言。據我所知,Shell 腳本被 TIOBE 單獨歸類,而 VBA 則徹底不在他們計量的語言列表上。

  4. 然而並非全部的棕色語言都使人畏懼:Python、C#、Swift、JavaScript 和 SQL 依然受歡迎,若是有人能解釋爲何的話,我洗耳恭聽。另外,Scala 和 Haskell 這兩種我喜歡的語言是使人畏懼的名單上僅有的綠色語言。這是單純的噪聲仍是有其餘的緣由呢?

  5. 譯者注:棕地項目指須要在已有軟件系統的基礎上開發的項目。這就意味着開發的新軟件系統必須考慮與已有軟件的兼容問題。(來源:Brownfield (software development) - Wikipedia

  6. 譯者注:綠地項目指沒有先前工做束縛的項目。在軟件工程中,它能夠是爲一個全新的環境開發系統,不須要考慮與其餘系統的兼容問題。(來源:Greenfield project - Wikipedia

若是發現譯文存在錯誤或其餘須要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。


掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章
相關標籤/搜索