※ 引述《godfat (godfat 真常)》之銘言： : 就我所知，一般會拿來跟 functional 比較的是 imperative, : 即函數形式或命令形式的程式風格。而 functional programming : 一直不是主流方式，就我所知主要是因為在 turning machine 上 : functional 的執行效率比之 imperative 是差一大截的。 : 所以在電腦執行速度越來越快的情況下，functional programming : 我想還會變得再更流行一些。或是哪天還會有全新的電腦架構流行起來， : 讓 functional program 的執行效率可以有很大的進步，這樣可能會掀起 : 更大的浪潮。 我想目前的趨勢仍是靠前者。目前 functional programming （以下 簡稱 fp）最重要的會議 ICFP 的前身叫做 FPCA -- Functional Proramming and Computer Architecture, 表示當時的熱門話題除了 fp, 還包括開 發適合 fp 的電腦架構。現在回想起來，這其實是走回了 Lisp machines 失敗的老路 -- 專為 Lisp 設計的機器又貴、軟體又少， 買來幾年之後就反而比速度一直快速增加的新工作站還慢。 但當時 lazy evaluation 剛剛成為熱門研究話題，大家都認為 要有效率地實現 lazy evaluation 一定得要特別的硬體架構。 直到 fp 在普通硬體上的實作方式經過幾輪演化之後慢慢成熟 （代表作大概是 Peyton Jones 的一篇 paper, 後來成為 GHC -- 目前最重要的 Haskell compiler 之一的基本架構），研究特定 硬體架構的走向就比較式微了。FPCA 也轉變成 Internatioanl Conference on Functional Programming. Peyton Jones 等人 在一篇回顧中提到，其實很多實作技巧現在看來都很自然，但當時 大家似乎都走到了死胡同，覺得 lazy evaluatio 只能靠 graph reduction 來實作，而後者又一定需要特殊的硬體。 我的感覺中，如 OCaml 之類的語言其實在執行效率上不比 C 差 太多，實用性已經蠻高了。不過 OCaml 是個 eager 的語言。 Lazy 的 Haskell 效率還是差一截。可能是 lazy evaluatio 的 負擔。另外就是記憶體使用的問題。 lazy 語言寫起 prototype 很漂亮，但是執行起來一不小心就浪費了不必要浪費的記憶體（ 所謂的 space leak），總是要用工具分析很久才知道問題出在哪。 : 不知道分散式（distributed）對此是否也有很大的關聯？ Hmm.. 據我所知用 fp 來作 parallel programming 的研究是有 的。Distributed computing 好像更少些。中研院有個老師幾年前 曾試過把 OCaml 跟 MPI 連在一起，不過後來就沒有後續了。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.192.157.71