為什么說面向?qū)ο缶幊毯秃瘮?shù)式編程都有問題
我不理解為什么人們會(huì)對(duì)面向?qū)ο缶幊毯秃瘮?shù)式編程做無休無止的爭論。就好象這類問題已經(jīng)超越了人類智力極限，所以你可以幾個(gè)世紀(jì)的這樣討論下去。經(jīng) 過這些年對(duì)編程語言的研究，我已經(jīng)清楚的看到了問題的答案，所以，我經(jīng)常的發(fā)現(xiàn)，人們對(duì)這些問題做的都是一些抓不住要領(lǐng)、無意義的爭論。
簡言之，不論是面向?qū)ο缶幊踢€是函數(shù)式編程，如果你走了極端，那都是錯(cuò)誤的。面向?qū)ο缶幊痰臉O端是一切都是對(duì)象(純面向?qū)ο?。函數(shù)式編程的極端是純函數(shù)式編程語言。
面向?qū)ο缶幊痰膯栴}
面向?qū)ο蟮膯栴}在于它對(duì)“對(duì)象”的定義，它試圖將所有事情就納入到這個(gè)概念里。這種做法極端化后，你就得出來一個(gè)一切皆為對(duì)象思想。但這種思想是錯(cuò)誤的，因?yàn)?/p>
| 有些東西不是對(duì)象。函數(shù)就不是對(duì)象。 |
也許你會(huì)反駁，在Python和Scala語言里，函數(shù)也是對(duì)象。在Python中，所有的含有一個(gè)叫做__call__的方法的對(duì)象其實(shí)都是函數(shù)。類似的，在Scala語言里，函數(shù)是擁有一個(gè)叫做apply方法的對(duì)象。但是，經(jīng)過認(rèn)真的思考后，你會(huì)發(fā)現(xiàn)，它混淆了源祖和衍生物的概念。函數(shù)是源祖，包含函數(shù)的對(duì)象實(shí)際是衍生物。__call__和apply它們自身首 先就是要定義的所謂“函數(shù)對(duì)象”。Python和Scala實(shí)際上是綁架了函數(shù)，把它們監(jiān)禁在“對(duì)象”里，然后打上“__call__” 和 “apply” 標(biāo)簽，把它們稱作“方法”。當(dāng)然，如果你把一個(gè)函數(shù)封裝到對(duì)象里，你可以像使用一個(gè)函數(shù)那樣使用對(duì)象，但這并不意味著你可以說”函數(shù)也是對(duì)象“。
大 多數(shù)的面向?qū)ο笳Z言里都缺乏正確的實(shí)現(xiàn)一等(first-class)函數(shù)的機(jī)制。Java語言是一個(gè)極致，它完全不允許將函數(shù)當(dāng)作數(shù)據(jù)來傳遞。你可以將 全部的函數(shù)都封裝進(jìn)對(duì)象，然后稱它們?yōu)?ldquo;方法”，但就像我說的，這是綁架。缺乏一等函數(shù)是為什么Java里需要這么多“設(shè)計(jì)模式”的主要原因。一旦有了一 等函數(shù)，你將不再需要大部分的這些設(shè)計(jì)模式。
函數(shù)式編程的問題
相似的，函數(shù)式編程走向極端、成為一種純函數(shù)式編程語言后，也是有問題的。為了討論這個(gè)問題，我們最好先理解一下什么是純函數(shù)式編程語言。出于這個(gè)目的，你可能需要閱讀一下Amr Sabry先生(他是我的博士導(dǎo)師)的What is a Purely Functional Language。概述一下就是，純函數(shù)式編程語言是錯(cuò)誤的，因?yàn)?/p>
| 有些東西不是純的。副作用是真實(shí)存在的。 |
所謂純函數(shù)，基本上就是忽略了物質(zhì)基礎(chǔ)(硅片、晶體等)表現(xiàn)的特性。純函數(shù)式的編程語言試圖通過函數(shù)——在函數(shù)中傳入傳出整個(gè)宇宙——來重新實(shí)現(xiàn)整個(gè)宇宙。但物理的和模擬的是 有區(qū)別的。“副作用”是物理的。它們真實(shí)的存在于自然界中，對(duì)計(jì)算機(jī)的效用的實(shí)現(xiàn)起著不可或缺的作用。利用純函數(shù)來模擬它們是注定低效的、復(fù)雜的、甚至是 丑陋的。你是否發(fā)現(xiàn)，在C語言里實(shí)現(xiàn)一個(gè)環(huán)形數(shù)據(jù)結(jié)構(gòu)或隨機(jī)數(shù)發(fā)生器是多么的簡單？但使用Haskell語言就不是這樣了。
還有，純函數(shù)編程語言會(huì)帶來巨大的認(rèn)知成本。如果你深入觀察它們，你會(huì)看到monads使程序變得復(fù)雜，難于編寫，而且monad的變體都是拙劣的修改。monads跟Java的“設(shè)計(jì)模式”具有相同的精神本質(zhì)。使用monad來 表現(xiàn)副作用就像是visitor模式來寫解釋器。你是否發(fā)現(xiàn)，在很多其它語言里很簡單的事情，放到Haskell語言就變成了一個(gè)課題來研究如何實(shí)現(xiàn)？你 是否經(jīng)常會(huì)看到一些有著諸如“用Monadic的方式解決一個(gè)已經(jīng)解決的問題”這樣標(biāo)題的論文？有趣的是，Amr Sabry先生一起合著了這樣一篇論文。他試圖用Haskell語言重新實(shí)現(xiàn)Dan Friedman的miniKanren，但他不知道如何構(gòu)造這些monads。 他向Oleg Kiselyov——公認(rèn)的世界上對(duì)Haskell類型系統(tǒng)知識(shí)最淵博的人——求教。而且你可能不知道，Amr Sabry先生應(yīng)該是世界上對(duì)純函數(shù)編程語言知識(shí)最淵博的人了。他們?cè)?Oleg 的幫助下解決了疑難后一起合著了這篇論文。諷刺的是，Dan Friedman——這個(gè)程序的原作者——在使用Scheme語言開發(fā)時(shí)卻沒有遇到任何問題。我在Dan的代碼基礎(chǔ)上重新實(shí)現(xiàn)了miniKanren，增 加了一個(gè)復(fù)雜的負(fù)操作。為了實(shí)現(xiàn)這個(gè)，我需要使用約束式邏輯編程和其它一些高級(jí)的技巧。鑒于用Haskell語言重寫基本的miniKanren將兩位世界級(jí)程序員都難倒了的事實(shí)，我不敢想象如果用Haskell的monads如何能實(shí)現(xiàn)這些。
有些人認(rèn)為monads的價(jià)值在于，它們“圈定”了副作用的范圍。但如果monads不能真正的使程序變得易于分析或更安全，這種“圈定”有什么用呢？事實(shí)上就是沒用處。本身就跟副作用一樣難于分析理解。沒有一種東西可以說monads能使其簡單而靜態(tài)分析辦不到的。所有的靜態(tài)分析研究者都知道這點(diǎn)。靜態(tài)分析利用了monads的本質(zhì)，但卻去除了程序員編寫monads代碼的負(fù)擔(dān)——而不是增加負(fù)擔(dān)。當(dāng)然，過度的副作用會(huì)使程序很難分析，但你也可以使用C語言寫出純函數(shù)，例如：
- int f(int x) {
- int y = 0;
- int z = 0;
- y = 2 * x;
- z = y + 1;
- return z / 3;
- }
你用匯編語言也能做到這些。純函數(shù)并不專屬于純函數(shù)式編程語言。你可以用任何語言寫出純函數(shù)，但重要的是，你必須也應(yīng)該允許副作用的存在。
回 首歷史，你會(huì)發(fā)現(xiàn)，數(shù)學(xué)上的理想主義是純函數(shù)編程語言的背后推動(dòng)力。數(shù)學(xué)函數(shù)簡單漂亮，但不幸的是，它們只是在你構(gòu)建原始純粹的模型時(shí)才好用。否者它們會(huì) 變得很丑陋。不要被“范疇論”等標(biāo)語嚇倒。我對(duì)范疇論了解很多。即使是范疇理論學(xué)家自己也稱其為“抽象無意義”，因?yàn)樗鼈兓旧暇褪怯靡环N怪誕的方式告訴 你一些你已經(jīng)知道的事情！如果你讀過Gottlob Frege的文章Function and concept，你會(huì)吃驚的發(fā)現(xiàn)，在他的這篇論文前的大多數(shù)數(shù)學(xué)家都錯(cuò)誤的理解了函數(shù)，而這僅僅是剛剛100多年前的事。事實(shí)上，數(shù)學(xué)語言上的很多事情都是有問題的。特別是微積分方面。編程語言的設(shè)計(jì)者們沒有理由要盲目的學(xué)習(xí)數(shù)學(xué)界。
不要盲目的愛上你的模型
無 論任何事情，當(dāng)走向極端時(shí)都是有害的。極端化時(shí)，面向?qū)ο缶幊毯秃瘮?shù)式編程都試圖把整個(gè)世界裝入它們的特有模型中，但這個(gè)世界是在完全不依賴我們的大腦思 考的情況下運(yùn)轉(zhuǎn)的。如果以為你有一個(gè)錘子，就把所有東西都當(dāng)成釘子，這明顯是不對(duì)的。只有通過認(rèn)清我們的真實(shí)世界，才能擺脫信仰對(duì)我們的束縛。
| 不要讓世界適應(yīng)你的模型。讓你的模型適應(yīng)世界。 |
