這是O’Reilly發佈的“The Least Liked Programming Languages”（作者：Mike Loukides）英文文章的中文翻譯版本。英文原版的翻譯得到O’Reilly Media,Ina.的授權。版權所有，未經書面許可，任何部分不得以任何形式使用、複製、修改。
最不受歡迎/最令人畏懼的編程語言有哪些？這些編程語言爲什麼令人畏懼？對它們的評價是否公正？
在 StackOverflow 的 2020 年度開發者調查中，有一張表格，顯示的是“最受歡迎、最令人畏懼和最想要的編程語言”。最受歡迎的和最想要的編程語言，嗯，是有點無聊。倒是那個最令人畏懼的就有意思多了。正如托爾斯泰（Tolstoy）所說的：“幸福的家庭都是相似的，而不幸的家庭則各有各的不幸。”（All happy families are alike; each unhappy family is unhappy in its own way.）
那麼，這些令人不快的、不受歡迎的編程語言都是哪些呢？爲什麼程序員如此害怕使用這些編程語言呢？如果有機會的話，很難不會加入一些理論，甚至說一些不明智的話。或者爲一些因爲錯誤的原因而不喜歡的編程語言辯護。
更準確地說，StackOverflow 統計的是“正使用該語言或技術進行開發，但沒有表示有興趣繼續使用的開發人員的百分比。”這聽上去沒有“恐懼”那麼可怕；“沒有表示有興趣繼續使用一種語言的工具”這一提法的本身就是一種相當模糊的畏懼暗示。我做過的很多事情我都不想再做了，包括編寫產生 shell 腳本的 troof 宏。但我們不用擔心這個，對吧？
最不受歡迎的語言列表與最廣泛使用的語言列表相似，如RedMonk、Tiobe和 O’Reilly Learning 上的搜索結果所示。這一點也不奇怪；C++ 之父 Bjarne Stroustrup 曾說，“世界上只有兩種語言，一種飽受詬病，另一種沒人使用。”（There are only two kinds of languages: the ones people complain about and the ones nobody uses.）這話說得很有道理，至少在這項調查中是這樣。如果你有數百萬用戶，要做到讓很多人不喜歡你並不難。因此，在不受歡迎的語言列表中看到 C 這樣的多年老牌語言和像 Java 這樣的新秀也就不奇怪了。
Kevlin Henney 和我認爲，最不受歡迎的語言列表也反映了從事大型遺留項目的程序員的意見，而不是短程序。不喜歡某一門編程語言的原因可能是“道德連坐”：因爲不喜歡一個龐大的、過時的、文檔最少的代碼庫，以及每次修復一個 Bug 都會破壞其他東西的架構風格。因此，在榜單上看到曾經被廣泛使用但卻不再受歡迎的編程語言也就不足爲奇了。人們也很容易愛上一門古怪的語言，這種語言對於某個項目來說非常完美，但你再也見不到它了。（就拿我來說，這種語言是Icon。你試試吧，你可能會喜歡這門語言。但它卻不在任何人的清單上。）
最令人驚訝的是當一種語言不合時宜的時候：當它比你預期的明顯更多或更少不受歡迎時。這就是我要思考的問題。因此，在進行了初步的討論之後，下面是一些討論的結果：
Java
自誕生以來，Java 就一直是人們愛恨交加的語言。我參加過 USENIX 會議，在會議上，James Gosling 第一次談到 Java（遠在 1.0 之前），人們離開會議室後都在談論 Java 是有多麼可怕——那時候並沒有人真正使用過 Java 語言，因爲它還沒有發佈。在這項調查中，Java 排名第 9 位。鑑於 Java 的聲譽，給出這樣的排名應該已經很夠意思了。
如果這個列表中有一種編程語言與大型項目相關，那就是 Java。關於 Java 有很多令人討厭的地方：儘管其中很多都與 Java 成長過程中程序員形成的不良習慣有關，而不是與語言本身有關。如果你發現自己在濫用設計模式，請退後一步看看自己在做什麼；把所有東西都變成設計模式就是一個信號，表明你並沒有理解模式到底是用來幹什麼的。（如果你需要複習的話，可以參閱 《深入淺出設計模式》（Head First Design Patterns） 或“四大金剛”合著的經典書籍《設計模式：可複用面向對象軟件的基礎》（Design Patterns: Elements of Reusable Object-Oriented Software）。如果你開始編寫 FactoryFactoryFactory，請停下來好好走一走。如果你正在編寫 ，那就無需這樣做了。但 Java 並不會讓你這麼做的。描述性的名稱還是很好的；長得離譜的名稱（以及深得離譜的包層次結構）卻並非如此。我總是試圖在每行代碼上都有一個連貫的想法。你不能在名字只有半行長的時候這麼做。但這不是 Java 的錯，而是 Java 程序員的一種文化怪癖。
Java 是冗長的，但這不一定就是個問題。正如一位並非 Java 愛好者的人曾經告訴我的那樣，類開始時的所有聲明實際上都是文檔，而文檔在大型項目尤爲重要。一旦你知道了數據結構是什麼，你就可以很好地猜測這個類是做什麼的。我發現 Java 比大多數其他語言更容易閱讀和理解，部分原因在於它非常明確——大多數優秀的程序員意識到，他們花在閱讀別人的代碼上的時間要比編寫自己的代碼要多。
Ruby
當我發現 Ruby 在榜單上居然排名第 7 位時，讓我倍感驚訝。Ruby 比 Java 更不受待見嗎？這是爲什麼？我用 Ruby 編寫過一些有趣的程序；在很大程度上，它是一種“按我的意思去做，而不是按我說的去做”的編程語言，15 年前，就是這個承諾讓很多程序員愛上了這門語言。
但如果我們把 Ruby 放在大型系統的環境中予以考慮的話，它還是有意義的。編寫模棱兩可的代碼並不難，至少對於一般的觀察者來說是這樣。如果一個函數或方法被打上“猴補丁”而產生一些非標準行爲，那麼就很容易與之發生衝突，而這些修改卻很少被記錄下來。元編程在 Rails 等框架得到了出色的應用，但是我一直對 Ruby 庫中的神奇功能方面感到困擾。這些功能都不利於大型項目。
譯註：猴補丁（monkeypatch），是一種很髒的編程技巧，用拼湊代碼的方法修改進程邏輯。這種技巧也叫鴨子雙關。猴補丁意思是用類似雙關的技巧拼湊出和常規進程相左的進程邏輯，這種技巧只會在運行時刻生效。猴補丁的出現說明進程本身設計有缺陷，它用在網頁和數據庫上就是 SQL 注入攻擊，Unix Shell 的 flag 使用不當也會產生類似的安全問題，比如將文檔命名爲“-x”形式，命令行就可能將文檔名認作一個傳遞的參數而造成運行異常。
許多年前，我在 Ruby 或 Rails 會議上曾聽到有人這樣說：“沒有任何大型項目，Ruby 中的所有東西都能減少 90% 的代碼行數。”我一直認爲 LOC 是一個愚蠢的指標（譯註：LOC，length of the code，即代碼的長度）。就算你相信 Ruby 真的減少了 90% 的代碼行（反正我不信），一個大數目的 10% 仍然是一個很大的數字，特別是如果你有責任消化這些代碼，包括背後發生的事情。Ruby 很有趣，我現在還用它來編寫快速腳本（雖然我基本上已經改用 Python 來做了），但它會是大型項目的首選語言嗎？那可能會讓我害怕地跑掉。
R
R 在“最令人畏懼的名單”中排在第 10 名。我認爲這是因爲一種誤解。R 既是也不是一種通用編程語言。一些統計學家告訴我，“你們程序員不明白，R 是一個統計工作臺，並不是一種編程語言。它不是 Python 的什麼怪異版本。”我曾多次用過 R，但當我讀完 Vince Buffalo 的《Bioinformatics Data Skills》（譯註：暫無中文版）中有關 R 的教程後，我終於“明白了”（至少是部分明白了）。循環和if語句在該教程的最後只有幾頁，而不是你最先學習的概念之一。爲什麼要這樣？因爲如果你正確地使用 R，你就不會需要它們了。它的設計目的是讓你不必使用它們。如果你使用的是更傳統的語言，你可能會發現自己在與這門語言作鬥爭，而不是使用它。條件邏輯和迭代的實現有更好的方法。
它還有助於使用最好的工具和庫：RStudio是一個非常好的 R 集成開發環境，而Tidyverse是一組用於處理數據很棒的庫。然而具有諷刺意味的是，這甚至可能是問題的一部分：有了優秀的圖形庫和 Web 框架，R 突然看起來不太像一個專門的統計工作臺，而更像一個通用的工作臺了。
許多程序員似乎正在用另一種眼光看待 R——也許是爲了分析 COVID 數據？在 2020 年 7 月的報告中，R 從Tiobe 指數的第 20 位躍升至第 8 位。這是一個巨大的變化。不管是什麼原因，如果你用它工作，而不是反對它，那麼 R 將是一個更愉快的環境。它是非常有意見的，而且這些意見是統計學家的意見，不是程序員的意見。
Python
Python 在這個榜單上排在第 23 位。對於一個使用如此廣泛的編程語言來說，這個排名是非常低的。Python 很容易讓人喜歡；我之所以喜歡 Python 僅僅是因爲它去掉了花括號。但除此之外，它還有什麼值得人們去喜歡呢？我總是講“不要選擇語言，要選擇庫”，而 Python 就有很棒的庫，尤其是在數值計算方面。Pandas、Numpy、Scipy和scikit-learn都是人們喜歡 Python 的好理由。像列表解析（list comprehensions）這樣的功能就消除了許多與傳統控制結構相關的簿記。Python 既適用於快速而棘手的任務，也適用於大型項目。如果我想用電子表格做點什麼，我幾乎總是使用 Python。（我嗎？數據透視表？）而像 Jupyter 這樣的工具可以很方便地記錄你的實驗過程。
從“大項目”的角度來看，Python 很容易閱讀；不會因爲嵌套的花括號而令人感到眼花，而且由於包含了解析（comprehension）、映射（map）和其他功能，嵌套的級別也更少。它具有合理的面向對象的特性（儘管公認有些古怪）。我又回到了一些舊的循環腳本，並且經常能夠完全不使用循環就編寫它們。如果你想把一個連貫的想法放在一條線上，那就是所有可能世界中最好的。《Python 之禪》（The Zen of Python）中有一個重要的口號是“明瞭優於隱晦”（Explicit is better than implicit）；你很少會去猜測別人是什麼意思，或者試圖破譯“發生的”一些意想不到的魔法。Python 獲得了最受歡迎的編程語言的稱號，最大限度地減少人們的反感。它擁有一系列平衡的特性，這使得它成爲小型項目和大型項目的理想選擇。
JavaScript
對於排名第 16 位的 JavaScript，我們該如何看待呢？我是沒什麼好說的。這是一種以隨機和無序的方式發展起來的語言，程序員最終認識到它的強大和高效，這在很大程度上要歸於 Doug Crockford 的經典著作《JavaScript 語言精粹》（JavaScript: The Good Parts）。一種像 JavaScript 一樣被廣泛使用的語言，在最令人畏懼的的語言排行榜上只排在第 16 位，它肯定是做對了什麼。但我不一定要喜歡它。
當然還有很多要說的。毫無疑問，VBA 是最不受歡迎的語言。我承認我完全不瞭解 Objective-C（排名第 2），我從來沒有任何理由去使用這門語言。儘管我很早以前就討厭 Perl，但令我驚訝的是，Perl 是如此不受人們待見（排名第 3），但有些傷口永遠不會癒合。看看 Perl 7 發佈幾年後會發生什麼，這將是一件有趣的事情。彙編語言（排名第 4）是一種後天習得的品味（而且不是一門單一的語言）。如果你不學着去愛它，你就會討厭它。如果你不喜歡它，你真的不應該去使用它。你幾乎總是可以避免使用匯編語言，但當你需要直接使用硬件時，你就別無選擇。C 和 C++（排名分別爲第 5 和第 8）給了你很大的空間，但對於幾乎任何項目，它們都能讓你儘可能接近硬件，而無需擔心使用匯編語言的問題。它們是消失在過去呢，還是會永遠與我們同在呢？我猜是後者；需要 C 的性能和普遍性的項目實在太多了。它是現代計算機中幾乎所有重要內容的基礎。
猜測編程語言以及人們喜歡或討厭它們的原因是一件很有趣的事。它可能有用，也可能沒用。但我所說的不一定有用，你聽聽就好，別當真。
原文鏈接：
https://www.oreilly.com/radar/the-least-liked-programming-languages/