先統一一下概念，我們有兩種編程方式：命令式和聲明式。
我們可以像下面這樣定義它們之間的不同：
- 命令式編程：命令“機器”如何去做事情(how)，這樣不管你想要的是什么(what)，它都會按照你的命令實現。
- 聲明式編程：告訴“機器”你想要的是什么(what)，讓機器想出如何去做(how)。
聲明式編程和命令式編程的代碼例子
舉個簡單的例子，假設我們想讓一個數組里的數值翻倍。
我們用命令式編程風格實現，像下面這樣：
- var numbers = [1,2,3,4,5]
- var doubled = []
- for(var i = 0; i < numbers.length; i++) {
- var newNumber = numbers[i] * 2
- doubled.push(newNumber)
- }
- console.log(doubled) //=> [2,4,6,8,10]
我們直接遍歷整個數組，取出每個元素，乘以二，然后把翻倍后的值放入新數組，每次都要操作這個雙倍數組，直到計算完所有元素。
而使用聲明式編程方法，我們可以用 Array.map 函數，像下面這樣：
- var numbers = [1,2,3,4,5]
- var doubled = numbers.map(function(n) {
- return n * 2
- })
- console.log(doubled) //=> [2,4,6,8,10]
map 利用當前的數組創建了一個新數組，新數組里的每個元素都是經過了傳入map的函數(這里是function(n) { return n*2 })的處理。
map函數所作的事情是將直接遍歷整個數組的過程歸納抽離出來，讓我們專注于描述我們想要的是什么(what)。注意，我們傳入map的是一個純函數；它不具有任何副作用(不會改變外部狀態)，它只是接收一個數字，返回乘以二后的值。
在一些具有函數式編程特征的語言里，對于list數據類型的操作，還有一些其他常用的聲明式的函數方法。例如，求一個list里所有值的和，命令式編程會這樣做：
- var numbers = [1,2,3,4,5]
- var total = 0
- for(var i = 0; i < numbers.length; i++) {
- total += numbers[i]
- }
- console.log(total) //=> 15
而在聲明式編程方式里，我們使用 reduce 函數：
- var numbers = [1,2,3,4,5]
- var total = numbers.reduce(function(sum, n) {
- return sum + n
- });
- console.log(total) //=> 15
reduce 函數利用傳入的函數把一個 list 運算成一個值。它以這個函數為參數，數組里的每個元素都要經過它的處理。每一次調用，第一個參數(這里是sum)都是這個函數處理前一個值時返回的結果，而第二個參數(n)就是當前元素。這樣下來，每此處理的新元素都會合計到sum中，最終我們得到的是整個數組的和。
同樣，reduce 函數歸納抽離了我們如何遍歷數組和狀態管理部分的實現，提供給我們一個通用的方式來把一個 list 合并成一個值。我們需要做的只是指明我們想要的是什么？
聲明式編程很奇怪嗎？
如果你之前沒有聽說過map 和 reduce 函數，你的第一感覺，我相信，就會是這樣。作為程序員，我們非常習慣去指出事情應該如何運行。“去遍歷這個list”，“if 這種情況 then 那樣做”，“把這個新值賦給這個變量”。當我們已經知道了如何告訴機器該如何做事時，為什么我們需要去學習這種看起來有些怪異的歸納抽離出來的函數工具？
在很多情況中，命令式編程很好用。當我們寫業務邏輯，我們通常必須要寫命令式代碼，沒有可能在我們的專項業務里也存在一個可以歸納抽離的實現。
但是，如果我們花時間去學習(或發現)聲明式的可以歸納抽離的部分，它們能為我們的編程帶來巨大的便捷。首先，我可以少寫代碼，這就是通往成功的捷徑。而且它們能讓我們站在更高的層面是思考，站在云端思考我們想要的是什么，而不是站在泥里思考事情該如何去做。
聲明式編程語言：SQL
也許你還不能明白，但有一個地方，你也許已經用到了聲明式編程，那就是SQL。
你可以把SQL當做一個處理數據的聲明式查詢語言。完全用SQL寫一個應用程序？這不可能。但如果是處理相互關聯的數據集，它就顯的無比強大了。
像下面這樣的查詢語句：
- SELECT * from dogs
- INNER JOIN owners
- WHERE dogs.owner_id = owners.id
如果我們用命令式編程方式實現這段邏輯：
- //dogs = [{name: 'Fido', owner_id: 1}, {...}, ... ]
- //owners = [{id: 1, name: 'Bob'}, {...}, ...]
- var dogsWithOwners = []
- var dog, owner
- for(var di=0; di < dogs.length; di++) {
- dog = dogs[di]
- for(var oi=0; oi < owners.length; oi++) {
- owner = owners[oi]
- if (owner && dog.owner_id == owner.id) {
- dogsWithOwners.push({
- dog: dog,
- owner: owner
- })
- }
- }}
- }
我可沒說SQL是一種很容易懂的語言，也沒說一眼就能把它們看明白，但基本上還是很整潔的。
SQL代碼不僅很短，不不僅容易讀懂，它還有更大的優勢。因為我們歸納抽離了how，我們就可以專注于what，讓數據庫來幫我們優化how.
我們的命令式編程代碼會運行的很慢，因為需要遍歷所有 list 里的每個狗的主人。
而SQL例子里我們可以讓數據庫來處理how，來替我們去找我們想要的數據。如果需要用到索引(假設我們建了索引)，數據庫知道如何使用索引，這樣性能又有了大的提升。如果在此不久之前它執行過相同的查詢，它也許會從緩存里立即找到。通過放手how，讓機器來做這些有難度的事，我們不需要掌握數據庫原理就能輕松的完成任務。
聲明式編程：d3.js
另外一個能體現出聲明式編程的真正強大之處地方是用戶界面、圖形、動畫編程。
開發用戶界面是有難度的事。因為有用戶交互，我們希望能創建漂亮的動態用戶交互方式，通常我們會用到大量的狀態聲明和很多相同作用的代碼，這些代碼實際上是可以歸納提煉出來的。
d3.js 里面一個非常好的聲明時歸納提煉的例子就是它的一個工具包，能夠幫助我們使用JavaScript和SVG來開發交互的和動畫的數據可視化模型。
第一次(或第5次，甚至第10次)你開發d3程序時可能會頭大。跟SQL一樣，d3是一種可視化數據操作的強大通用工具，它能提供你所有how方法，讓你只需要說出你想要什么。
下面是一個例子(我建議你看一下這個演示)。這是一個d3可視化實現，它為data數組里的每個對象畫一個圓。為了演示這個過程，我們每秒增加一個圓。
里面最有趣的一段代碼是：
- //var data = [{x: 5, y: 10}, {x: 20, y: 5}]
- var circles = svg.selectAll('circle')
- .data(data)
- circles.enter().append('circle')
- .attr('cx', function(d) { return d.x })
- .attr('cy', function(d) { return d.y })
- .attr('r', 0)
- .transition().duration(500)
- .attr('r', 5)
沒有必要完全理解這段代碼都干了什么(你需要一段時間去領會)，但關鍵點是：
首先我們收集了svg里所有的圓，然后把data數組數據綁定到對象里。
D3 對每個圓都綁定了那些點數據有一個關系表。最初我們只有兩個點，沒有圓，我們使用.enter()方法獲取數據點。這里，我們的意圖是畫一個圓，中心是x 和 y，初始值是 0 ，半秒后變換成半徑為 5。
為什么我說這很有意思？
從頭再看一遍代碼，想一想，我們是在聲明我們想要的圖案是什么樣子，還是在說如何作圖。你會發現這里根本沒有關于how的代碼。我們只是在一個相當高的層面描述我們想要的是什么：
| 我要畫圓，圓心在data數據里，當增加新圓時，用動畫表示半徑的增加。 |
這太神奇了，我們沒有寫任何循環，這里沒有狀態管理。畫圖操作通常是很難寫，很麻煩，很讓人討厭，但這里，d3歸納提取了一些常用的操作，讓我們專注于描述我們想要的是什么。
現在再看，d3.js 很容易理解嗎？不是，它絕對需要你花一段時間去學習。而學習的過程基本上需要你放棄去指明如何做事的習慣，而去學會如何描述我想要的是什么。
最初，這可能是很困難的事，但經過一些時間的學習后，一些神奇的事情發生了——你變得非常非常有效率了。通過歸納提取how，d3.js 能讓你真正的專注說明你想要看到的是什么，讓你在一個個更高的層面解決問題，解放你的創作力。
聲明式編程的總結
聲明式編程讓我們去描述我們想要的是什么，讓底層的軟件/計算機/等去解決如何去實現它們。
在很多情況中，就像我們看到的一樣，聲明式編程能給我們的編程帶來真正的提升，通過站在更高層面寫代碼，我們可以更多的專注于what，而這正是我們開發軟件真正的目標。
問題是，程序員習慣了去描述how，這讓我們感覺很好很舒服——強力——能夠控制事情的發生發展，不放走任何我們不能看見不能理解的處理過程。
有時候這種緊盯著how不放的做法是沒問題的。如果我需要對代碼進行更高性能的優化，我需要對what進行更深一步的描述來指導how。有時候對于某個業務邏輯沒有任何可以歸納提取的通用實現，我們只能寫命令式編程代碼。
但大多數時候，我們可以、而且應該尋求聲明式的寫代碼方式，如果沒有發現現成的歸納提取好的實現，我們應該自己去創建。起初這會很難，必定的，但就像我們使用SQL和D3.js， 我們會長期從中獲得巨大的回報！
非常感謝@srbaker, @maniacyak and @jcoglan對這篇文章的的建議和補充。
