函數編程
① 函數式編程有什麼弊端
不論是面向對象編程還是函數式編程，如果你走了極端，那都是錯誤的。面向對象編程的極端是一切都是對象(純面向對象)。函數式編程的極端是純函數式編程語言。
面向對象編程的問題
面向對象的問題在於它對「對象」的定義，它試圖將所有事情就納入到這個概念里。這種做法極端化後，你就得出來一個一切皆為對象思想。
但這種思想是錯誤的，因為有些東西不是對象。函數就不是對象。
② 什麼是函數式編程
在維基網路中，已經對函數式編程有了很詳細的介紹。
那我們就來摘取一下Wiki上對Functional Programming的定義：
In
computer science, functional programming is a programming paradigm that
treats computation as the evaluation of mathematical functions and
avoids state and mutable data.
簡單地翻譯一下，也就是說函數式編程是一種編程模型，他將計算機運算看做是數學中函數的計算，並且避免了狀態以及變數的概念。
③ 為什麼說面向對象編程和函數式編程
先從結構化編程說起
很久以前，軟體開發的世界還是一片渾渾噩噩，不管開發什麼軟體都面臨著復雜性這個問題，代碼裡面到處是goto語句，程序的流程隨意跳轉。眾生寫代碼時，越寫到後面越不知道自己寫的是什麼。這時候出現一位巨人，它就是結構化編程。
結構化編程的基本思想是：
有序地控制流程，即把程序的執行順序限制為順序、分支和循環這三種；
把共通的處理歸結為常式（函數）。
結構化編程的好處是：
三大限制：大大降低了程序的自由度，減少了各種組合，使得程序不至於太過復雜。對於這一點，結構化編程的順序、分支和循環可以實現一切演算法，雖然降低了程序的復雜性和靈活性，但是程序的實現能力並沒有降低。
常式（函數）：我們只需要知道過程（函數）的名字，而不需要知道過程的內部細節，即「黑盒化」。
雖然結構化解決了程序控制流的復雜問題，但程序裡面不僅包括控制結構，還包括要處理的數據。隨著處理數據的增加，程序的復雜性也會上升。這時候，面向對象編程來了！
面向對象的由來
「分別管理程序處理內容和處理數據對象所帶來的復雜性」問題是，為了得到正確的結果，必須保持處理和數據的一致性，這在結構化編程中是非常困難的，解決這一問題的方案就是數據抽象技術。
數據抽象是數據和處理方法的結合。這便是最初「對象」一詞的得來。面向對象編程也因此得名。
然後，從抽象原則來說，多個相同事物出現時，應該組合在一起，即DRY原則(Don't Repeat Yourself)，便又引出了類這一概念。
根據數據類型來進行合適的處理（調用合適的方法），本來就應該是編程語言這種工具應該完成的事。這便是多態的引出了。
而對於繼承，大部分的觀點是「繼承是隨著程序的結構化和抽象化自然進化而來的一種方式」。結構化和抽象化，意味著把共通部分提取出來生成父類的自底向上的方法。（如果繼承是這樣誕生的話，那麼最初，有多個父類的多重繼承就會成為主流，而實際上最初引入繼承的Simula語言只提供單一繼承。松本行弘認為繼承的原本目的實際是逐步細化）
④ 為什麼函數式編程最近才崛起
簡言之，不論是面向對象編程還是函數式編程，如果你走了極端，那都是錯誤的。面向對象編程的極端是一切都是對象(純面向對象)。函數式編程的極端是純函數式編程語言。 面向對象編程的問題 面向對象的問題在於它對「對象」的定義
⑤ 函數式編程語言的是不是吹牛
不是啊，函數式編程語言出現的很早，在人工智慧方面應用的比較多。
現在挺多新出的函數式語言，一些面向對象的語言也加入了函數式的內容。
⑥ 函數式編程的特性
在經常被引用的論文 「Why Functional Programming Matters」（請參閱 參考資料） 中，作者 John Hughes 說明了模塊化是成功編程的關鍵，而函數編程可以極大地改進模塊化。在函數編程中，編程人員有一個天然框架用來開發更小的、更簡單的和更一般化的模塊， 然後將它們組合在一起。函數編程的一些基本特點包括：
支持閉包和高階函數，支持惰性計算（lazy evaluation）。使用遞歸作為控制流程的機制。加強了引用透明性。沒有副作用。我將重點放在在 java 語言中使用閉包和高階函數上，但是首先對上面列出的所有特點做一個概述。 副作用是修改系統狀態的語言結構。因為 FP 語言不包含任何賦值語句，變數值一旦被指派就永遠不會改變。而且，調用函數只會計算出結果 ── 不會出現其他效果。因此，FP 語言沒有副作用 。
⑦ 式編程，命令式編程（）和函數式編程的區別
編程語言主要有四種類型
聲明式編程：專注於」做什麼」而不是」如何去做」。在更高層面寫代碼，更關心的是目標，而不是底層演算法實現的過程。
ex: css, 正則表達式，sql 語句，html, xml…命令式編程(過程式編程) : 專注於」如何去做」，這樣不管」做什麼」，都會按照你的命令去做。解決某一問題的具體演算法實現。
函數式編程：把運算過程盡量寫成一系列嵌套的函數調用。
函數式編程強調沒有」副作用」，意味著函數要保持獨立，所有功能就是返回一個新的值，沒有其他行為，尤其是不得修改外部變數的值。
所謂」副作用」（side effect），指的是函數內部與外部互動（最典型的情況，就是修改全局變數的值），產生運算以外的其他結果。
⑧ 什麼是函數式編程思維
1.表達式化
在
最初的時候，需要轉變觀念，去可變數，去循環，把命令式改成表達式，注意，這只是把你丟在荒山野嶺讓你感受一下，離開熟悉的環境，地球依然在轉，但是有個
重點，那就是一切都是表達式; 為什麼是表達式呢？這個問題就像為什麼魚在水裡?
因為函數式建立在lambda演算之上而非圖靈機，只不過兩者被證明等價，所以你可以在你的機器上跑全是表達式的代碼，就如有人證明天空適合魚生存，所以
魚可以在天上游
當你接受了魚可以在天上游之後，就該上正餐了
1.5 數據與行為分離
這也是和面向對象不一致的地方，面向對象強調數據與行為綁定，但函數式不是，確切的說函數式 函數與數據等價，所以你才可以將函數當參數與返回值，你在設計時，切勿讓數據自己長腿能跑，其次，行為必須消除副作用，不可以偷偷把數據改了，習慣第一條後，應該不會的
2.高階邏輯
用
了函數式，就不要在想循環，賦值這些低階邏輯了，而應該更高階的思考問題，這比轉化表達式更難，函數式又叫聲明式，也就是你要做什麼，只要說一下就行，而
非寫個遍歷，做個狀態判斷，用函數式你不需要考慮這些，你不知道函數式的列表是怎麼遍歷的，中間向兩邊?
從後往前?這也是為何函數式適合並發的原因之一，你想知道列表中大於3的數有多少，只要，list.count(_ > 3)
而不是寫循環，你可以直接寫你的業務，不要拘泥於細節，有點像sql, 你需要什麼告訴電腦就行，你或許會問，count foreach filter
這些函數怎麼來的? 因為有了他們你才不需要寫循環，他們把你留在高階邏輯中，這個問題的答案請看下面
3.組合子邏輯 或又叫 自底向上的設計
函
數式和OO是反的，面向對象是自頂向下的設計，函數式是自底向上的設計，也就是先定義最基本的操作，然後不斷組合，不斷堆積以滿足你的所有需要，如sql
定義了select, from, where...這幾個組合子，來滿足你的查詢需求，同理函數式語言會提供foreach,
map等組合子(操作)來滿足你的需求，所以你必須自下而上的設計你的代碼結構，並且滿足你的需求，當你只用組合子寫代碼時，你會發現你寫的全是高階邏輯
如
果這些已有組合子滿足不了你，你就得自己寫，foreach不行，你就自己寫遞歸，我告訴你，遞歸背後也是組合子，這里一些'大神'應該不知道，在圖靈機
里，遞歸就是方法不斷調用自己沒什麼好說的，但是在lambda演算中，匿名函數是沒法調用自己的，所以遞歸是用Y組合子(又叫不動點組合子)把遞歸函數
自己求解出來再調用的，這才可以實現遞歸，並與圖靈機的循環等價，有點跑題了，總之要想順手的寫函數式，最好用面向組合子的設計，注意，不是必須，組合子
演算和lambda演算可以相互轉化，也就是，你完全可以寫一堆雜亂的表達式，但沒有組合子邏輯來得清爽，Haskell大規模使用monad這個特殊組
合子，始其變得統一整潔
好了，總結一下
函數式思維，其實就是組合子邏輯，用簡單的幾個函數組合來構建復雜邏輯，始終以高階的角度去表達問題，而非依賴副作用。
知道這點，你用java也可以寫函數式代碼了
⑨ 想要理解函數式編程的思想，最好用哪種函數式編
面向過程（函數式）的編碼流程。思想。相對的還有面向對象的編程思想（oop）
面向過程的編程 比如c語言，匯編，全局函數那種，不用類的。都是函數式編程。
面向過程優點 運算快，簡單，缺點復雜項目時各種全局函數調用非常頭疼，無法區分關系。