近乎函數語言程式設計是不起作用的 - Erik Meijer

banq發表於2019-08-26
函數程式設計

這是一篇2014年的文章，主要針對FP和OOP混合，主要部分是函式程式設計，但又不是純粹的函數語言程式設計，例如Scala，原文點選標題。

大概意思是：軟體行業有一種趨勢是出售近乎函數語言程式設計作為解決開發人員面臨的併發性，並行性（多核），當然還有大資料的問題的靈丹妙藥。不幸的是，正如“突出安全”不起作用，“突出函式”也不起作用。相反，開發人員也應該認真考慮一個完全原教旨主義的選項：擁抱純粹的懶惰函數語言程式設計，並使用monad在型別系統中明確表現出所有效果。
許多人都在吹噓“近乎函式性的程式設計”和“有限的副作用”，作為對抗室內新大象的完美武器：併發性和並行性。很少有人願意接受這些好處必然會以犧牲I / O等常見操作中的潛在影響的便利性為代價，正如節食者寧願不承認鍛鍊的好處必然以犧牲時間和汗水為代價。

“近乎函數語言程式設計”的想法是不可行的。透過僅部分消除隱含的副作用，使指令式程式設計語言更安全是不可能的。留下一種效果通常足以模擬你剛試圖去除的效果。另一方面，允許在純語言中“忘記”效果也會以自己的方式造成混亂。
不幸的是，沒有黃金中間，我們面臨著一個經典的二分法，只能兩者選擇其一。

(從一開始Scala語言的設計就是允許FP和OOP兩者正交，但在實踐中它並沒有那麼好用。要麼人們使用它作為OOP和更好的Java，要麼將它用作純FP語言。)

(也有人認為：混合FP和OO架構對我來說很有意義。FP對於某些事情來說真的很棒，但是當你必須透過可變狀態裝置的外部世界產生效果時，為什麼不把它交給OO中的基礎設施程式碼呢？這是一種成熟，無偏見的方法。
但是最後，必須以某種方式管理副作用。因為最終沒有副作用的程式根本沒用。無論是OO還是FP，將副作用推向應用程式的邊界都是好的。
Haskell強制使用IO monad並且得到了編譯器的幫助，但在OOP中你可以使用類似六邊形體系結構的東西，它允許在應用程式體系結構邊界的介面卡中包含外部世界的副作用。這非常相似)

相關文章