如何評價王垠的《編程的宗派》？

12-31

其實我覺得他說的很對。在我眼中，Java 是最務實和有誠意的語言，Python 是能解決潔癖需求的語言。scheme 做教學用可以，但他操作符的數學偏執讓我無法忍受。C++可選擇的太多還不如沒有。objective C 過於啰嗦，乾的活還不如Java

本來就是實用就好。很多人看到新語言新特性就頂禮膜拜了，無非就是大腦享受那一種被征服或者征服的感覺，承認自己不如計算機。許多人讚歎數學之美，無非也是這樣。越是犄角旮旯，刁鑽，無用的數學，越能吸引人的挑戰和征服欲，越能培養一群信徒，跪拜在數學分支的腳下。這是人的學習本能，值得讚賞。當我看懂或者親手寫一段特別複雜的scheme 程序的時候，我也有這樣的感覺。這麼複雜，但我卻可以理解，說明他其實本質簡單，這就是美了。然後反覆回味我是如何理解的，或者反覆回味計算機的處理步驟，深陷其中而不能自拔。程序員腦殘，大概就是這麼來的

看起來，所有程序員都成立一個腦殘神教比較好

希望下次的題目是，如何評價王垠的技巧/功夫/尺寸/口活。。。

我非常喜歡這篇文章。應該說，關於編程語言的文章里最喜歡的一篇。

我們編程，核心目標就是如何更好、更快的寫出程序，其它的一切努力都應該服務於這個核心目標，而回望過去這幾十年軟體業的發展，本末倒置的事出現的太多，比如設計模式的濫用，過度工程化等等。

就王垠本人來說，我覺得他越來越睿智, 當然傲嬌的毛病估計這輩子就這樣了，但我還是越來越欣賞他了（或者說他的智慧）。

對那些討厭王垠的朋友，我的建議是，只要能獲取智慧就好，不要太苛求其它。看他的文章不代表你要同意他的所有觀點，也不代表你要欣賞他的性情，關注其中的智慧之處即可。

為毛他每寫一篇文章都會有人來提這種無聊的問題？

fold的問題在於，它定義了一個遞歸函數，卻沒有給它一個名字。

可惜我們小學四年級的時候就知道了，如果你同一個 fold f i 重複了兩遍，就應該定義一個新函數了。

int f(int x) { int y = 0; int z = 0; y = 2 * x; z = y + 1; return z / 3; }
很多函數式程序員可能看到那幾個賦值操作就皺起眉頭，然而他們看不到的是，這是一個真正意義上的「純函數」，它在本質上跟Haskell之類語言的函數是一樣的，也許還更加優雅一些。

大概王先生遇到的皺眉頭的 FPer 是弱智吧……三歲小孩也知道那是純函數。

函數式語言的幫眾沒有看清楚的另一個重要的東西，是數據結構的根本性和重要性。

我很傷心，作為一個正在研究如何用 Haskell 寫各類數據結構的半本科生，我竟然連「函數式語言的幫眾」都算不上了……

在這種數據結構下，很簡單的像length或者append之類函數，時間複雜度都是O(n)！

在我們那個年代，分析鏈表的時間複雜度似乎是六年級暑假的內容。我們初一就知道表結構是怎麼通過指針來實現的了（沒辦法小學學 Logo 當時感覺表比數組方便好多）。現在小學生都搞 OI 了，我覺得 append 和 length 是 O(n) 的操作，算得上是常識了吧。

「你們的編譯器已經可以生成跟我的Chez Scheme媲美的代碼，然而Chez Scheme不止生成高效的目標代碼，它的編譯速度是你們的700倍以上。它可以在5秒鐘之內編譯它自己！」

以前隨手寫了一段代碼，把 LaTeX 生成的 PDF 拷貝出來的內容做一個處理（比如說省略號會變成六個句點），然後慢死掉了，因為當時圖省事用了尾遞歸加 append，時間都坑在了 GC 上，後來改成了 foldr（當然我對 foldr 做了進一步封裝，我說了小學生都知道要這麼做，方便 declarative 地寫轉換規則嘛！），速度大概也是提升了好幾百倍。這點我很同意。

===

黑 OOP 的部分我不熟悉，但我覺得科班狗肯定都不會那麼傻，培訓班的我就不知道了；黑 FP 的部分太傻了。嗯，就是這樣。

我以前一直好奇為什麼王先生不搞一個 RSS，今天我突然想通了。

。。。不知道為什麼。。。我越來越喜歡王垠的文風了。。。我是不是病了。。。誰快救救我。。。

至少裡面有幾個說法還是挺同意的

一、純函數

Haskell 要求所有東西都是純的，但其實吧，一個只在內部做賦值的函數，對外界來說仍不失「純」性。所以這個問題里(如何用函數編程方法寫一個字元計數程序? - Python)本來用局部副作用很容易就解決、效率 O(n) 的問題，用 Haskell 寫就得繞點兒彎子。

二、「不管看起來多麼酷的語言或者範式，如果必須繞著彎子才能表達程序員心目中的模型，那麼它就不是一個很好的語言或者範式。」

list - Nested chunksOf in Haskell?

這個問題裡頭，用 Python 很簡單可以做到的事情，用 Haskell 卻得多寫一堆東西來討好編譯器。(當然，也可以說是 Python 迴避了這個問題；不過我覺得 Haskell 的做法也不是最漂亮的，扯遠了)

中肯的說，這篇文章寫得很好。

雖然嘴上說OOP和FP都不太行，但還是可以看出他心裡更傾向與OOP一點，而且這篇文章也有「總結編程本質」的抽象概念在裡面，我甚至認為這是他少有的適合新手看，並且能真正增加對編程理解到文章。

至於樓上，fold什麼的可讀性不強都能洗地就沒道理了，不管再怎麼「手熟」我就不信能寫得比普通遞歸更容易理解；況且，這種寫法並沒有讓性能有本質上的提升，而且還需要讀你代碼的人和你一樣付出「手熟」的時間。而OOP為了OOP而進行很多冗餘的操作也是該黑。

其實之所以有那麼多的語言和流派，歸根結底還是每個人的興趣不同，或者是對某各方面偷懶的產物。用十全十美去要求一門語言本身就是不切實際的，這也是Yin語言註定無法實現的原因。

有些地方講得對，有些地方我個人不是很認同，感覺王同學對haskell可能有些誤解

01 純函數

純函數不是為純而純，王同學把純函數特性當成某種「意識形態」的產物不符合事實

之所以要純函數，是因為：對模塊化的追求導致-&> 惰性求值的出現導致-&> 純函數的要求

這和設計師的喜好與立場沒關係，純粹是一個技術上的原因

02 數據結構

王同學對list的吐槽沒什麼問題，簡單的list一般是當棧來使用的，你不能讓它承受太多功能，fp社區常使用各種樹形不可變結構，絕大部分時候性能和命令式語言差異小得可以忽略不計。在沒有合適的樹形結構的情況下，偶爾也使用數組這樣的可變結構，這就涉及到接下來的副作用了

03 副作用

函數式語言是有副作用的

haskell只是用類型系統把副作用和純函數隔離開，實際上haskell還對副作用進行細分，只讀，只寫，io……曾經有人說haskell是最好的命令式語言……

04 fold

fold的正確用法是把它當作定義其他函數的「母函數」，比如

sum = foldr + 0

product = foldr * 1

對於「用戶」來說，sum和product會清晰很多，對於「設計師」來說，fold可以節省很多時間，而且還不容易犯錯

王同學的觀點照顧了用戶，但是忽視了設計師：很多時候fold不是在一個簡單表上的fold，而是在一個很複雜的樹上進行fold

05 其他就不一一點評了

ps1：王同學雖然批判了宗派思想要不得，但從字裡行間我分明看到了一個scheme程序員指點江山的氣魄 _(:з」∠)_

ps2：最近王同學被人比作「路邊的狗屎」，我覺得這實在太過分了，祝願王同學一切安好，不要受到這些人身攻擊的影響

讀後感：王垠沒有看過F#。

首先，宗派是存在的。這太正常了。就像各種東西都有自己的粉絲團一樣。

第二，這種宗派存在有一些合理的原因。畢竟爭論應當是允許的。

除了最後吹Yin語言毫無營養之外，這是一篇很不錯的批判型文章。不是所有人都能從本質出發分析問題的。佛分佛教和佛學，佛教是給眾生的，我覺得題目《編程的宗派》很妙。從哲學的角度看，儒釋道一家，從宗派看，各不相同。如果把編程語言看作是programming language taxonomy的根節點的話，那麼它的子樹門自然是各種宗派。想要站在根節點來看問題，不就是張無忌學太極，學一點，忘一點。到底要學什麼，各有各的需求。我是被點名的好好先生。雖有不甘，想了想，還是當好好先生吧，沒有能力成宗師，就學點兒皮毛，省下嘴仗，好好生活吧。

我覺得王垠提到的OO只是在談Simula一派的OO，並不是拿了圖靈獎的那個Alan Kay的那個OO。只提了封裝一個方面，並沒有提消息機制，特別是對對象的method有很深的成見。

x 2 * 1 + 3 /

估計是人名氣大了，收到的郵件各種檔次——半桶水居多——不吐不快吧。

函數式語言的擁鱉們

看來他不僅要搞新的編程語言，還要搞新的漢語方言。

看到黑 fold 的時候，我聯想起日本到底有多好？ - 孫杭東的回答

中 @哈不斯基的評論：

記得很久以前，在國內，坐計程車的時候，看見路邊等車的人在排隊。當時排隊還很少見。計程車司機和我說，這些人虛偽得讓他起一身雞皮疙瘩。忽然想，遠古的人看見我們出門穿衣服，會不會也一身雞皮疙瘩

因為自己看 fold (+) 0 需要一秒，從而覺得別人也需要一秒以上，從而認為別人在裝B

這到底是自負呢，還是偏激呢？

適應範式可能需要一點時間，因為要從一種習慣變成另一種習慣，我認為其實就是，無她，唯手熟矣。

就目前來說，任何語言都需要一些範式。yin 語言會是怎樣的呢？拭目以待。

===========================================================

說到宗派，個人認為宗派是必然存在的，譬如，讓變數只讀，一般上能讓代碼邏輯更加清晰、安全，但是會失去一定的靈活性，有時候要繞著來做事，於是就產生兩派，只讀和不只讀的。由此產生的，「盡量讓變數只讀」「讓所有變數不只讀」「默認讓變數只讀」「默認讓變數不只讀」，諸如此類，不歸楊即歸墨，只是五十步和一百步問題。我想 yin語言要避開這個，唯一的辦法就是沒有變數。

另外，「無」境界的人當然認為，該只讀時候只讀，不該只讀時候不只讀。一般這些高人，我們稱為飄逸派。能夠這樣但是不增加Bug的人少，而能夠完整讀完這種代碼還很愉快的人就更少了。

解救辦法就是，總結出相當的場景，什麼時候該用只讀，什麼時候不該用只讀，立下規矩，這樣，懂得這規矩的人，寫的時候安全，讀的時候也愉快了，這是什麼，這就叫開宗立派，這個宗派有沒有傾向也還很難說。

綜上所述，宗派是必然存在的，宗派就是一種風格，同一份代碼里貫徹同一種風格是很好的事。

至於，宗派出來罵架則是另一回事，即使罵架也不一定是壞事，不爭論過，就很難總結出什麼時候怎麼做有什麼優勢，有什麼劣勢。我知道有個人，不是幾乎每一種語言都罵過了嗎？