1樓：
所有這些計算模型的結果，從某種角度講，都是等價的，而且和泛式的馮諾伊曼機器，即數字計算機是等價的，這也隱含的說明了這樣乙個結果，就是任何乙個系統的結果都可能等價於另乙個系統的結果，而任何乙個系統都可以用另乙個系統來模擬，然後lambda的創始人，Church這位數學家從理論上推想，所有對於計算的描述都是等價的，但是無法被證明，雖然如此，我們看到lambda計算能夠在數字計算機上實現的，這也許就是乙個事實上的例子。
2樓：
如果題主指的「演算法」就是「能行過程（Effective method）」的話，那麼根據丘奇圖靈論題（Church）任何一種圖靈完備的語言都能實現。
PS:題主可以看一點關於可計算性理論和形式語言的知識。
3樓：Yunfei Lu
我的結論是：可以，因為圖靈完備性。但函式式程式設計對遞迴資料結構的演算法問題效果較好，對需儲存狀態的以及需要隨機位址訪問的資料結構效果較差。
因為函式式程式設計的演算法是遞迴的，遞迴資料結構與遞迴演算法天生就很相配。
演算法與資料結構是分不開的。資料結構的核心是引用與解引用。
例如樹結構，struct tree_node，left與right是兩個從幹到枝的引用，parent是從枝到幹的引用。對一般的操作，遞迴都很方便。但是紅黑樹就有麻煩了，因為有狀態，而不是簡單的引用與解引用的問題。
改變狀態，在函式式程式設計特別是純函式式程式設計裡面就是天大的事，因為可能是乙個物件的生滅。
再舉例看list資料結構和map、filter這樣的高階函式。map、filter需要利用list的遞迴資料結構：struct list。
map和filter的操作是先解引用car用乙個函式f操作，把剩餘cdr部分和map或filter打包到遞迴函式裡面。但是如果要隨機訪問呢？比如直接取第100個元素？
如果不改變list結構的底層（指的是list的定址方式由遞迴改成隨機定址），那麼就是非常困難的。map結構的key如果不能隨機定址，map就沒有存在的必要了。
最後舉乙個例子：丘奇數。丘奇數是遞迴定義的自然數，加減乘除靠遞迴演算法實現。實在不如小學生的九九表來得直接。
回到問題本身，若要強行用遞迴演算法解決一切演算法問題，需要先針對問題設計乙個好的遞迴資料結構。比如紅黑樹問題，也許轉變成2-3-4樹更方便一點？（猜測）
為什麼有這麼大的區別，我覺得因為從彙編碼的隨意goto到命令式的if/else/while，再到函式式的遞迴，抽象的概念越來越清晰，但是威力越來越受限制。人理解起來容易，但機器會覺得被綁住了手腳。對於確定的演算法，最快的是專用積體電路ASIC，最慢的是CPU和程式語言。
4樓：Kang kai
CMU 15210 用 sml實現了圖論的演算法，動態規劃，等等等等
5樓：ge wang
大多數是吧，看《演算法導論》裡基本上所有的演算法都是以遞迴的方式書寫的，如果以函式式方式寫感覺要方便很多，個人最近正在嘗試使用C++和函式式語言haskell寫一些演算法。感覺函式式寫法要舒服很多。就說插入排序，歸併排序和快速排序吧，用指令式的寫法不光要思考演算法本身的遞迴結構，還有就是用陣列下標的形式來實現這些演算法（個人感覺後面這一步驟是比排序演算法本身更難的部分，而且更容易出各種小bug），但是用haskell直接把演算法導論上的概念演繹玩就將排序實現了。
感覺就像在做數學題一樣。
有關函式式程式設計，return語句能否理解成為乙個函式？
據我有限的觀察，我認為 某些語言，乙個函式就是乙個表示式 此類語言多半也同時是函式式的 return確實就是乙個函式，它的返回值是乙個Monad型別類的資料型別。另一些語言，比如Rust,雖然強調一些函式式的風格，但稱不上函式式語言，return是一種流控制語句。 丟貓 函式式語言和函式式程式設計不...
想要理解函式式程式設計的思想，最好用哪種函式式程式語言入門？
SML虐我千百遍，我待SML如初戀 上學期上了CMU 15150，差一點就拿C了好驚險。SML作為教學用還是很不錯的，因為理論方面比較完善。SML裡有個概念叫totality。有了這個totality可以證明很多theorem。這個是Haskell做不到的 Scheme Standard ML Ha...
是不是 JavaScript 函式式程式設計的 Pointfree Style 有時會喪失程式可讀性？
胖虎 如果不考慮 this 我認為其實可讀性更高的const aSet new Set someArrary.forEach aSet.add 這本是乙個很適合的例子，但是無法正常執行 因為 add 的 this 指向不正確了 已重置 嘗試用HS 純函式式語言 做了下,與題主的邏輯相同。data P...