程序員為何與函數式編程“墜入愛河”?
本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。
函數式編程發展至今已有60年的歷史，但是截至目前，它仍然算是比較小眾。盡管像Google這樣的大公司依賴于函數式編程的關鍵概念，但是普通程序員對此幾乎一無所知。
這種情況即將改變了。不僅是Java或Python這樣的語言越來越多地采用了函數式編程的概念，類似Haskell這樣的新語言也正在完全實現函數式編程。
簡單來說，函數式編程就是為不可變變量構建函數。與之相反，面向對象的編程則是有一組相對固定的函數，而用戶主要是修改或添加新變量。
由于函數式編程的特性，它非常適合完成諸如數據分析和機器學習之類的需求任務。但是這并不意味著用戶要告別面向對象的編程，轉而完全使用函數式編程。但用戶需要了解其基本原理，以便在適當的時候使用它們以發揮優勢。
一切都是為了消除副作用
要了解函數式編程，首先需要了解函數。函數是將輸入轉換為輸出的東西，它并不總是這么簡單。下面看一個Python中的函數：
- def square(x):
- return x*x
這個函數很簡單。它需要一個變量 x，或者是一個int，又或者是float或double，然后輸出該變量的平方。
現在再思考這個函數：
- lobal_list = []def append_to_list(x):
- global_list.append(x)
乍一看，該函數看起來像是接受了一個任意類型的變量x，并且由于沒有 return 語句，它不會返回任何值。
請等一下!如果未事先定義global_list，那么該函數將不起作用，并且在經過修改后仍輸出相同的列表。盡管global_list從未被視為函數的輸入，但使用函數時它也會發生改變：
- append_to_list(1)
- append_to_list(2)
- global_list
它將返回[1,2]而不是一個空列表。即使我們對此并不明確，但這表明該列表確實是該函數的輸入。這種不明確可能會造成問題。
圖源：GitHub
不忠實于函數
這些隱含的輸入，或在其他情況下的輸出，有一個官方的名稱：side effects(副作用)。雖然本文所舉的只是一個簡單的示例，但是在更復雜的程序中，這些副作用可能會導致真正的困難。
請思考一下如何測試append_to_list：用戶不僅需要閱讀第一行并使用任意的x來測試函數，還需要閱讀整個定義，理解其作用，定義global_list并且以這種方式進行測試。當需要處理帶有數千行代碼的程序時，此示例中的簡單操作可能很快就會變得乏味無趣。
有一個簡單的解決方法：忠于函數認定為輸入的內容。
- newlist = []def append_to_list2(x, some_list):
- some_list.append(x)append_to_list2(1,newlist)
- append_to_list2(2,newlist)
- newlist
它并沒有做出太大的改變。輸出仍然是[1,2]，并且其他所有內容也保持不變。但是有一樣改變了：該代碼現在擺脫了副作用。
現在，當查看函數聲明時，用戶能確切地知道發生了什么。因此，如果程序運行不正常，用戶也可以輕而易舉地單獨測試每個功能，并查明哪個功能有問題
函數式編程正在編寫純函數
沒有副作用的函數是指其輸入和輸出都具有明確的聲明，而沒有副作用的功能就是純函數。
函數式編程一個非常簡單的定義：僅用純函數編寫程序。純函數永遠不會修改變量，而只會創建新的變量作為輸出。(筆者在上面的示例中稍微“作弊”了一下：它遵循函數式編程的原則，但仍使用全局列表。用戶可以找到更好的示例，但這只是基本原則。)
此外，對于給定輸入的純函數，可以得到特定的輸出。相反，不純函數則依賴于一些全局變量。因此，如果全局變量不同，則相同的輸入變量可能導致不同的輸出。不純函數會使代碼的調試和維護變得更加困難。
有一個更容易發現副作用的小竅門：由于每個函數都必須具有某種輸入和輸出，因此沒有任何輸入或輸出的函數聲明一定是不純的。如果采用函數式編程，這些則可能是第一批需要的更改聲明。
圖源：unsplash
函數式編程不僅只有Map和reduce
函數式編程中不包含循環結構(Loops)，請看下面這些Python中的循環：
- integers = [1,2,3,4,5,6]
- odd_ints = []
- squared_odds = []
- total = 0for i in integers:
- if i%2 ==1
- odd_ints.append(i)for i inodd_ints:
- squared_odds.append(i*i)for i insquared_odds:
- total += i
相較于我們要執行的簡單操作，以上代碼明顯過長。而且由于修改全局變量，它也不夠有效。我們可以用以下代碼替代：
- from functools import reduceintegers = [1,2,3,4,5,6]
- odd_ints = filter(lambda n: n % 2 == 1, integers)
- squared_odds = map(lambda n: n * n, odd_ints)
- total = reduce(lambda acc, n: acc + n, squared_odds)
這是完整的函數。因為不需要迭代一個數組的許多元素，所以它更短也更快。而且，一旦了解了 filter、map和reduce 如何工作，代碼也就容易理解了。但這并不意味著所有函數代碼都使用map、reduce 等。這也不意味著需要借助函數式編程來理解map 和 reduce，這些函數只是在抽象循環時彈出很多。
- Lambda functions：談及函數式編程的發展史時，許多人都會先提及lambda函數的發明。盡管，lambda毫無疑問是函數式編程的基石，但這并不是根本原因。Lambda函數是可使程序發揮作用的工具。但是，lambda也可用于面向對象的編程。
- Static typing：上面的示例不屬于靜態輸入，而是函數式的。即使靜態類型為代碼增加了一層額外的安全保護，但也并非一定要其函數化，不過這可能會是錦上添花。
一些語言對函數式編程更加友好
圖源：unsplash
(1) Perl
Perl對于副作用的處理方法與大多數編程語言截然不同。它包含一個神奇的參數 $_，這使得處理副作用成為Perl核心功能之一。盡管Perl確實有其優點，但作者不會嘗試使用它進行函數式編程。
(2) Java
如果要用Java編寫函數式代碼的話，只能自求多福了。因為該程序的一半不僅將都是static 關鍵字，而且其他大多數Java開發人員也會將此程序視為恥辱。
(3) Scala
Scala是一個很有趣的語言：它的目標是統一面向對象和函數式編程。很多人都覺得這很奇怪，因為函數式編程旨在徹底消除副作用，而面向對象的編程則試圖將副作用保留在對象內部。
話雖如此，許多開發人員將Scala視為一種可以幫助他們從面向對象編程過渡到函數式編程語言，這可能會幫助他們在未來幾年更容易完全過渡到函數式編程。
(4) Python
Python積極鼓勵使用函數式編程。下列事實證明了這一點：每個函數在默認情況下都有至少有一個輸入self。這就像是Python之禪：顯式比隱式好!
(5) Clojure
根據其創建者的說法，Clojure的函數化達到80%。默認情況下，正如在函數式編程中所需要的，它的所有值都是不可變的。但是，可以通過對這些不可變值使用可變值包裝類來解決此問題。當打開這樣的包裝類，可變值將再次不可變。
(6) Haskell
這是極少數純函數式和靜態類型的語言之一。盡管在開發過程中可能會耗費大量時間，但在調試程序時這些付出都會獲得巨大回報。它不像其他語言那樣容易學習，但是絕對值得花時間學習。
圖源：unsplash
與面向對象的編程相比，函數式編程仍然小眾。但是，如果說在Python和其他語言中加入函數式編程原理意味著什么的話，那就是函數式編程正越來越受到關注。這完全說得通：函數式編程對于大型數據庫、并行編程和機器學習大有裨益。而在過去十年間，這些迎來了蓬勃發展。
雖然面向對象編程有著不可估量的優點，但函數代碼的優點也不容忽視。只需要學習一些基本原理，就足以讓用戶成為一名開發人員，并為未來做好準備。
