為什麼程式設計師會有最喜歡與最討厭的程式語言？（earthly）

Stack Overflow的2020年調查結果對“最恐懼的程式語言”和“最喜歡的程式語言”進行了排名。這兩個排名都來自這個問題：

在過去的一年中，您完成了哪些程式設計，指令碼和標記語言的廣泛開發工作，並且在接下來的一年中又要進行哪些工作？（如果您既使用了該語言，又想繼續使用該語言，請選中該行中的兩個框。）

前15種可怕的程式語言：

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

最受歡迎的15種程式語言：

Rust，TypeScript，Python，Kotlin，Go，Julia，Dart，C＃，Swift，JavaScript，SQL，Shell，HTML，Scala和Haskell。

舊程式碼總是最糟糕的

舊程式碼是最糟糕的。在經過三年多的積極開發的程式碼庫中，想找到我一個檔案，很難跟蹤。現實世界中的程式碼會不斷髮展以適應其特定領域，並且隨著這種行為的發展，它變得更加複雜且難以理解。原因很簡單，我首先從喬爾·斯波斯基（Joel Spolsky）聽說過。

認為舊程式碼是一團糟的原因是由於基本的程式設計基本法則：閱讀程式碼比編寫程式碼難。喬爾·斯波斯基（Joel Spolsky）

我們稱其為喬爾定律。在此前提下會有很多事情發生。為什麼大多數開發人員認為他們繼承的程式碼是一團糟，並想將其扔掉並重新開始？

這是因為從認知上講，扔掉它至少比理解程式碼庫所付出的辛苦工作要少，為什麼許多重寫註定要失敗？因為使程式碼看起來凌亂的大部分原因都是至關重要的，因此隨著時間的推移而進行的改進很少。如果沒有簡化它們的計劃，您將回到起點。

在編寫程式碼時很容易理解程式碼。您正在執行它，並在執行時對其進行完善，但是，在事後閱讀程式碼就很難理解程式碼。程式碼本質上也是複雜的，這種複雜性也導致痛苦的程式碼質量問題。這可能就是為什麼PR積壓的問題持續存在的原因嗎？PR評論是一種只讀活動，如果您尚不具備程式碼當時工作模型，那麼舊很難做得很好。

如果許多現實世界的程式碼被不公平地認為是一團糟，那麼程式語言是否也會被不公平地判斷？如果您在最喜歡語言Go中構建新事物，但必須維護龐大的20年曆史C ++程式碼庫，您能否對它們進行公平排名？

棕色和綠色語言

對於2016年已經進入排行榜前20名的語言，現在更可能使已經將其用作維護工作的語言，我們稱它們為棕色語言；2016年未進入前20名的語言更有可能用於新專案中。我們將這些稱為綠色語言。

棕色語言：您更可能在現有軟體維護中使用的語言列表：Java，C，C ++，C＃，Python，PHP，JavaScript，Swift，Perl，Ruby，Assembly，R，Objective-C，SQL

綠色語言：您更可能在新專案（即綠色專案）中使用的語言：Go，Rust，TypeScript，Kotlin，Julia，Dart，Scala和Haskell

現在我們可以回答這個問題：人們是喜歡還是害怕他們所陳述的語言，還是隻是在害怕遺留程式碼？

將棕色和綠色語言與前面最喜歡和害怕的語言兩個調查結果合併後，發現：

• 在最害怕的語言中幾乎都是棕色語言。
• 在最喜歡的語言中有54％是綠色。

人格中的另一個缺陷是每個人都想要建造而沒有人想要維護。―庫爾特·馮內古特（Kurt Vonnegut）

沒有人喜歡維護別人的程式碼。而且，由於喬爾定律：閱讀現實世界很難編寫程式碼。構建新事物很有趣，而使用新語言的頻率更高。

程式語言炒作的生命週期

喜愛的程式語言被大量使用，這導致程式碼維護，這又使人們不喜歡它們，從而導致人們尋找更綠色的牧場並嘗試更新的牧場語。流行的框架也可能遵循此生命週期。

Ruby是2007年最熱門的語言，儘管今天它確實有更多競爭，但Ruby是比那時更好的語言。然而現在，它令人恐懼。在我看來，部分差異在於現在人們需要維護14年的Rails應用程式。這使得Ruby的趣味性不如所有新專案。因此，請注意Rust和Kotlin以及Julia和Go：您最終也會失去光環。

黑客新聞網友討論

我認為Go當前處於蜜月期，人們會在10年後討厭它。但是即使Rust是一門傳統語言，Rust也將繼續受到人們的喜愛，Ruby可以通過最少的儀式快速而輕鬆地做事。隨著時間的推移，這種特性使PHP和Perl進入了“恐懼”類別；另一方面，Rust已針對維護進行了優化，Rust API很難被濫用，所有內容都受到約束並非常明確地指定。文件和測試與您的程式碼保持內聯。您確切地知道一段程式碼可以做什麼和不能做什麼

我見過的大多數語言都以易於學習而聞名，隨後也因維護麻煩而贏得聲譽：perl，ruby，python，php，javascript等。這可能是選擇效果而不是語言功能。較簡單的語言會成比例地吸引較弱的程式設計師。

“學習困難”是上下文中的重要因素，例如，如果您已經瞭解Perl或PHP，則Python或Ruby可能相對容易學習。我發現Haskell很難學習。隨後，PureScript非常簡單。隨著時間的流逝，廣泛共享的知識和概念會發生變化，它們將影響採用的便利性。

我每天都用Python程式設計。Racket可能是Python之後我最瞭解的語言，然後可能是Groovy。我接觸過R，C，C ++，D，Java，Common Lisp等，由於我的熟悉程度，我發現採用新語言更容易。儘管Rust具有我習慣於使用其他程式語言的所有構造，但我發現Rust是我在最近的記憶中最難學習的一種。文件很棒，書很棒，Cargo的工具很棒，但是在閱讀了本書的前15章之後，我努力編寫了一種具有任何複雜性的程式。當然，我可以輕鬆地向我的專案中新增依賴，但是要弄清楚庫中所有內容引發的錯誤會花費很多工作。與同一時間其他程式語言相比，使我對Rust的適應需要更長的時間。這並不是說這是一種不好的語言。我記得有一天，在除錯完一個Python問題之後，我最終感到自己是一個愚蠢的邏輯錯誤，我大喊：“我希望我知道一種程式語言，可以讓我擺脫自己的束縛”。我想...或更確切地說，我希望Rust對於我來說是長期的語言。

Rust不比C ++更“難以學習”或“難以入門”。C ++當然是一種具有大量傳統的語言，足以合理地稱其為“棕色”。Go是一種完全不同的語言，與Java作為最接近的“棕色”對應語言相比，它也許是最好的。

我不同意，進行良好維護的事情與學習難度和是否入行的難度都相關。易於學習的東西往往很容易入手，但最終卻通過框架或編碼標準增加了難度，因為存在複雜的專案，這既增加了學習的難度，又使他們難以接受。具體來說，維護程式碼時需要像最初建立程式碼的人一樣思考。您的想法與他們越一致，就越容易維護。轉變為像他們一樣思考的行為是學習和入職。

在使用了多個大型golang程式碼庫後，其冗長的工作變得很乏味。它不能很好地適用於IDE。錯誤處理總是一團糟，這裡列出了Java沒有的許多問題。例如無法實現Java中字串連結操作someString.trim().toUpper().endsWith(“ ...”))。不要讓我開始使用所謂的快速編譯時間。解析速度很快，但是連結速度卻非常慢。修改和重新執行單元測試一次需要花費幾秒鐘的時間來重新連結。在Java中，因為沒有連結，所以眨眼之間就可以了。

我認為這有點不對勁。程式語言通常分為兩類：

1. 它們是由一個或兩個怪人設計的，因此包含一些重要的指導原則和許多可疑的想法，這些想法不可避免地又回到了大型專案中；
2. 它們是由一個委員會設計的，該委員會試圖製作能夠解決所有可能問題的最終通用語言，從而導致一本無人閱讀的400頁規格的語言陷入窘境。

大多數主流語言做了一些嘗試，以滿足軟體在規模上要求; 例如，OO顯然使軟體更易於維護，因此大多數語言至少部分支援它。但是，如果您使用的是C ++之類的語言，則很明顯，新增了許多功能只是因為它們很酷或表達能力增強（例如，運算子過載），而不考慮長期的可維護性。甚至像“隱含的'this'之類的世俗事物一樣，顯然也對可讀性有害，但顯然具有好處。

當Ruby成為“熱門”產品時，它帶來了很多新東西，而新開發人員現在已經把這些東西視為理所當然。如果您使用typescript甚至C＃啟動一個新專案，那麼您將獲得使Ruby在2006年變得很棒的所有東西。當我向新的開發人員介紹Ruby時，我唯一要支援的就是它是一種設計精美，表達能力強的語言，當然任何新手都可以用它的缺點來說服我：效能中等，沒有型別定義，並且語言中沒有事件I / O。我確實害怕無法在Ruby中啟動新專案的那一天，僅僅是因為我要招聘的人員變成了一個討厭為Ruby工作的人。

看到Ruby被列為一種可怕的語言，這實在令人痛心。我認為，實際上令人恐懼的是Rails，而PM迫使其在2010年代所做的可怕，糟糕，無用的事情。我現在是Python開發人員，但我仍然想念用Ruby編寫程式碼的難易程度。我發現它是一種輕鬆，直觀的活動，我希望它用於除笨拙，可伸縮性差/計劃不足的Web應用程式之外的其他用途。

我認為Kotlin和TypeScript將繼續受到人們的喜愛；他們以簡單且精心策劃的方式解決了真正的痛點，我認為Scala會令人恐懼，我認為Haskell仍然會被愛和恐懼。最有趣的問題是Go和Rust。我的直覺是，我認為Go會像Ruby：一開始就很不錯，但是隨著專案越來越大，它變得越來越笨拙。我確實發現對小型Go檔案進行黑客入侵是一件令人愉快的事情，但會害怕加入具有數百萬行Go程式碼的專案。Rust可能會被視為未來的C ++，以難以維護的程式碼庫大而笨拙而聞名。或者，它可能會被譽為未來更好的C ++，以使笨拙的程式碼難以維護，使它們更易於維護和令人愉悅地工作而聞名。

banq: 程式設計師易於掌握與程式碼易於維護是兩件完全不同事情，以前設計語言的人大概沒有意識這點，期待以後新語言設計意識到這兩個方面的區別，並提出好的解決方案，只有找出問題根源，就能解決問題，最大問題是無法找到真正問題根源。