"為什么這段代碼如此混亂? 為什么這個問題很難表達? 這段代碼到底是怎么回事?"

諸如此類的問題使我多次尋求編程語言的圣杯。 我還沒有找到圣杯，但是就像每一次旅行一樣，我變得更聰明，更有經驗。

[[328515]]

長期以來，程序員一直在尋找向計算機表達自己的最佳方式。 在曾經創造的所有語言中，只有少數發展成為廣泛的行業標準。

像我一樣，您可能正在使用經過考驗的流行技術，并嘗試使其以最佳方式工作。 但是我們都知道事情不是完美的-它們的缺點會影響我們的神經和耐心。

這是我嘗試過的語言的簡短列表，這為我的日常工作帶來了一些好處。 雖然不是大多數語言的專家，甚至不是常規用戶，但我對這些語言進行了很多有趣的嘗試，而且我想認為它們只是使我總體上成為一個更好的程序員。

ML語言(F#/ OCaml)

對于第一個條目，我想向您介紹ML系列的語言。 這不是我第一次進入函數式編程(FP)世界。 然而，正是這一點使我對它的實際工作方式有了真正的實際了解。

盡管兩種語言都支持多種范例，但它們最適合于函數式編程。 它們不像Haskell那樣嚴格和純凈，因此您可以將您的腳趾浸入函數式編程風格中，而無需太多的初期掙扎和挫折。

我真的很喜歡通過匹配和破壞來控制流程是多么容易。 F#能夠一目了然地可視化函數的流程。 無論語言如何，我都會努力將其納入代碼中。

多虧了ML語言，我在類型的組成和設計方面變得更好。 即使F#會嘗試從您編寫的核心代碼中猜測您的類型，它也是一種強類型化的語言。

F#非常適合學習序列上的功能樣式操作。 這是任何FP第一語言的共同特征。 折痕，地圖壓縮等與FP編程器工具箱中的錘子等效。 易于使用的語法支持著重于此元素，將幫助您訓練大腦以了解可以抽象為序列操作的問題。

如果您具有OOP(面向對象編程)的經驗，那么學習F#是進入函數式編程世界的絕佳的第一步。 如果遇到困難，您總是可以回到日常的對象和課程。 F#將它們與其他代碼混合在一起，而不必大驚小怪。

如果您具有C#的經驗，則F#與.NET的互操作性也將為您帶來很大的幫助。 您仍然可以使用可信賴的.NET工具和nuget包。

我只能建議您嘗試一下。 沒有非常陡峭的學習曲線，這很有趣。

但是，如果您不害怕陡峭的學習曲線，則可以直接跳至：

Haskell

現在，Haskell一直是(現在仍然是)我要時不時地挑戰。 即使我從未完成過任何大型項目，但我始終喜歡與之合作的精神挑戰。

Haskell編程從一開始就是一種殘酷的經歷……老實說，它仍然是。 Haskell不是一種蓬松的用戶友好型ML語言。 這種語言將迫使您對FP進行編程并正確編程。

您必須正確設計類型。 您必須精確地計劃功能。 而且對實現沒有任何欺騙，如果您說此功能會做某事，則必須兌現您的承諾。 沒有一半的實現，沒有漏掉的案例或"其他"。

但最重要的是，沒有隱藏的副作用。 如果您說您的函數將獲得一個字符串并取回該字符串，則編譯器將強制您兌現您的承諾。 沒有打印調試信息，沒有讀取用戶輸入。 您說過您會得到一個琴弦并只將琴弦還給您，不是嗎?

使用這種語言確實可以使您的大腦注意所承諾的聲明功能(或方法)的內容。

即使這種嚴格性不能總是很好地翻譯成C#之類的語言，但它會使您更加了解，并會促使您謹慎地聲明函數，以便其他用戶不會感到不愉快。 一兩年后再回到自己的代碼時，這將為您節省一些咒罵。

我知道當我修改傳遞給該方法的任何參數時，我的大腦會立即發出警報。 我需要那個嗎? 我是否警告過潛在用戶該功能會干擾他/她的數據?

當我開始學習Haskell時，它是一種奇怪的語言。 我已經知道Haskell程序員坐在編程象牙塔的頂層。 我還發現，顯然奇怪的生物正在懸停在塔頂頂部上方(笑話歸于ScottW)。

這些人在編程：

LISP系列：通用LISP，Clojure，Scheme

對于像我這樣來自C家族的任何人來說，這都是一個真正的陌生人。 第一次困惑地看一下代碼，第一次斜視是由一群大括號擁抱這些陳述引起的。 啊，回憶!

我進入LISP世界的第一步是通過Clojure。 我只是在書店里瀏覽，當時一本關于Clojure的書引起了我的注意(出于對我的愛，我不記得那本書是哪本書)。 我把它帶回家，冒險開始了。 或者，確切地說，是一個天又一個難題地解決，并試圖了解如何使用該工具的日子。 幾周后我放棄了，一年后又回來了。 并再次放棄。 然后，我找到了Common LISP，然后再次使用它，但是這次有了發現我的文本編輯器(也許是操作系統)想要的EMACS的附加價值。

我不記得在這個周期中什么時候點擊了。 大括號融合到背景中，剩下的只是一個清晰的提示。 如果您在LISP中發現一件事，那就太優雅了。 我絕對不會說我可以用LISP編寫優秀代碼，但是閱讀經驗豐富的程序員的代碼是一種敬畏和嫉妒的經歷。 我希望有一天，我將有技能來編寫能很好地說明自己的程序。

如果我可以證明這些語言的出色表現，那么即使我沒有足夠的知識親自編寫該程序，我仍然可以理解該程序的意圖。

所有這些都歸功于簡單而靈活的設計。 最重要的是，有一個我所不知道的宏系統。 通過支持語法構造，這使您可以圍繞已解決的問題編寫程序。

另一個重要功能是使用REPL進行交互式實驗性編程。 編寫活動代碼鼓勵進行試驗，并允許您在提交給代碼的一種設計之前檢查許多想法。

即使我在工作中不使用LISP，它仍然是一個很好的工具，而且我在經常被引用的句子"發現學習LISP將使您成為更好的程序員"中發現了事實。 我不知道我是否可以通過LISP成為一個更好的程序員，但這無疑擴大了我的視野。

Rust

當我處理C ++ pet項目時，我首先發現了Rust。 我不討厭或鄙視C ++，但是使用它的任何人都知道，有時C ++可能會令人討厭。

C ++所提供的復雜性和自由度令人驚嘆，但也可能使人不堪重負，甚至失去希望……

如果您從未在其中編寫過中型或大型項目，那么讓我告訴您，它很快就會變得混亂。

這種語言龐然大物背后的驅動思想是，無緣無故應該阻止開發人員用自己的腳射擊……或者恰好是現在出現的20英尺，而您不確定他們是如何到達這里的。 同樣，您的原始腳在某處，但您不確定該在哪里。

無論如何。 Rust用RAII范式的嚴格性和自以為是的AF解決了這個問題。 類似于Haskell的方式，編譯器始終處于工作狀態，并確保您正確構建程序。

主要目標是：如果編譯，它將正常工作。

用Rust寫作就像與一個憤怒的教練合作，他會在一點點滑倒的情況下糾正您。

這是一個好習慣，尤其是在您無法正確設置內存管理的情況下。

每次查看Rust時，Rust似乎都會得到重大改進。 即使它不能代替C ++代替中級通用語言，還是有一個好的競爭者仍然很不錯。

SmallTalk

我的朋友在有關面向對象和功能范式的酒吧辯論中向我推薦了這個。 在啤酒的充分刺激下，我站在一位功能編程的新手的立場上，他認為這種新的范例將解決我所有的問題，即使不是世界上的問題。

我被一個簡單的論點反駁：

試試Smalltalk，看看面向對象的編程是否真的沒有用。

所以我嘗試了并且感到謙虛。 原來，我不知道如何執行OO。 Smalltalk是特定的。 大多數實現：Pharo，Squeak等將為您提供完整的IDE，這幾乎就像是為開發而構建的小型操作系統。

它為您提供了完成任務的所有工具，但最重要的是，它強烈建議工作流向您展示如何以我所說的Smalltalk方式進行開發。

因此，您要發表評論，也要編寫測試。 您需要將對象和函數命名和分類為適當的對象，協議和包。

叫我瘋了，但是當我以正確的方式做事時，我覺得法羅幾乎為我感到驕傲。

事實證明，正確的方法可以花很多時間。

語言本身非常簡單，您可以在不到15分鐘的時間內輕松學習語法。 沒有技巧，沒有語法糖。 它為您提供了足夠的工具來完成工作，因此您可以做到。 您不必費心去尋找應該使用的語言工具-別無選擇。 我覺得它可以讓我的大腦將所有精力集中在手頭的工作上。 它對我有用，也許對您有用。

后記

我在本文中跳過了一些語言。 其中一些是如此廣泛，以至于您可能以其他形式(例如Python / Java / C ++ / C#等)看到了它們。

有些人我沒有遵守規則，即如果您無話可說，那就什么也不要說(我看著您JavaScript，ekhm)。

有些，例如Ruby，Scala，Perl，我還沒有嘗試過。 希望以后能對這些有所了解。