程序員為何與函數式編程“墜入愛河”?
本文轉載自公眾號“讀芯術”(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和其他語言中加入函數式編程原理意味著什么的話,那就是函數式編程正越來越受到關注。這完全說得通:函數式編程對于大型數據庫、并行編程和機器學習大有裨益。而在過去十年間,這些迎來了蓬勃發展。
雖然面向對象編程有著不可估量的優點,但函數代碼的優點也不容忽視。只需要學習一些基本原理,就足以讓用戶成為一名開發人員,并為未來做好準備。