在遊戲開發領域，不考慮現有開發人員熟悉程度，函式式程式設計在設計上或者理論上有它的先天缺陷嗎？

1樓：attilax

最大的問題是效能缺陷。。現在的機器都是諾依曼體系，硬體流水線體系，本來就適合流水線命令式樣的軟體語言。。除非底層硬體架構大改變，否則函式式不能在要求效能高的領域成為主流。

2樓：

修改大資料結構，不會導致資料大量複製，參見 Bagwell 的 HAMT。

clojure Scala 都是使用的這個資料結構

3樓：達達

唉，不說高大上的理論、執行效率和開發人員學習成本什麼的，我用Erlang做遊戲服務端開發，最大的感受就是：

策劃案的不確定性和函式式語言的數學式抽象要求是矛盾的

遊戲開發過程大家最苦惱的就是程式反覆跟著策劃案調整，作為有經驗的開發人員，一定不會牴觸這種行業現狀，也不可能要求策劃案想好後就不做任何調整，而是應當盡量幫助策劃早點明確思路，同時盡量想辦法降低調整的成本，並減少調整後出現BUG的可能性。

但是函式式語言的本質是要把邏輯和行為極度抽象，直到用乙個個簡單公式乙個個嚴謹的模式就可以表達業務邏輯。

當乙個業務需求還沒定型的時候就要做高度的抽象是非常有難度的，而且過早的抽象也導致調整起來很麻煩。

以上是個人愚見，還望指正。

4樓：Tang Boyun

目前，其實還是缺少庫，以及一些語言編譯器級別的特性支援。

1. 封裝良好的，mutable的資料結構，包括向量和矩陣是很有必要的。目前主要是沒有乙個統一的矩陣庫(包括稀疏矩陣與滿矩陣)。

社群裡目前主要商業化方向在金融數值計算上，所以這塊的高質量庫，遲早會有的，應該不會太久。

2. 預設的Strict語義。7.

10或7.12版的GHC，將有乙個Extension，可以給予開發者控制編譯結果是否採用預設的strict語義，而非lazy。這個控制可以精確到每個檔案。

當然，我懷疑短時間內，能否把這個feature做到成熟。

樓上 @WBScan 提到的那個各種語言的benchmark測試，那個測試理論上是不能包含FFI與第三方庫的(實際上許多動態語言是做不到這點的，比如讓perl不用內聯c上正則看看？)。在真正效能敏感的地方：

1. 應該使用mutable的資料結構。Haskell裡，可以象c一樣的去操作記憶體。

2. 內聯外部語言的庫是必要的。目前可以很方便的內聯C。