https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

不謝邀（

他寫這篇文章的時候 Scheme 裏的確沒有這些東西啊

  1. 沒有 Pattern Matching 的確是 pain in ass，所以在 Racket 裏是作為標準的一部分存在的，在 Common Lisp 裏有至少十個不同的庫實現（辣雞 CL 裏沒有這種東西不是很正常嘛）（天國的 MLisp 2 / Lisp 70）
  2. 他後面用了很長的篇幅去說 Miranda 那個語法比 S 表達式怎麼怎麼優越，（對於初學者來說）一個是前綴表達式會造成一定的困擾（說不定愛爾蘭人還覺得很舒服呢（逃，一個是用列表去表示程序和數據會造成混淆，但是這隻能說是設計思路的區別而已，你看他就沒說在 Miranda 裏怎麼玩 meta-programming 不是（逃
  3. 我資瓷靜態類型，自定義類型在 Scheme 之外的 Lisp 方言裏幾乎都有
  4. 用宏實現個 delay / force 很難？ 而且你在 Scheme 裏都有 first class continuation 了，Okasaki 的 Call-by-need and Continuation-passing Style 瞭解一下？

他後面舉的例子裏很多都是因為早期的 Scheme 並沒有很好的組織結構的能力導致的，比 Scheme 還早一點的 ZetaLisp （也有另外一個分支叫 Lisp Machine Lisp，很大程度上影響了 Common Lisp 的設計）甚至都已經有對象系統了

這篇文章發表的時候 Scheme 標準還沒確定呢（IEEE 1178-1990 是 1990 年才制定的）

不是 little lisper/schemer/prover/typer... 哈哈（typer 是新書，下面會說到）

我在初看的時候，我甚至覺得裡邊很多東西是因為 taste 生出的偏見，比如 quote 什麼的，是可以用學習來克服的，另外，我們也可以 argue 很多語言裏都有有趣但是 tricky 的部分。

但是跟 @楊雙成 觀點完全相反的，我覺得唯一的痛點就是 pattern matching。當然我們可以用 Scott encoding（有些想要小 kernel 的語言就是這麼做的），但我還是覺得像 Coq 做成 primitive 比較好。

至於 s-exp，我有兩種完全對立的想法。語言的一種特徵（甚至不是特性）常常引領著其開發者把它往不同的方向推進。

大家都知道，s-exp 恐怕是最自然的讓人往 meta programming 的方向走的特徵了。而在 academia 裏未必受到很多關注的「語言的使用感」方面，Lisp 系也還有這幾樣好處：做 code formatter 真的 trivial； tab 跟 space 的問題被 define 掉了；切整個 s-exp 下來完全沒有額外的心智壓力。

我甚至還要說，寫好複雜的類型時，用 s-exp 都很自然。Sigma 和 Pi 就是跟 let 長一樣：

(let ((a 1) (b 2)) some-exp)
(Π ((a A) (b B)) some-term)

我們再也不用被提醒 ightarrow 是 Pi 了，就因為 ightarrow 也（被逼著）寫成 prefix 的關係。一成串的箭頭還可以搞成這樣，真的簡潔

(→ a b c d e)

「沒有一個 theorist 可以拒絕這樣的契合的感覺」，我是這樣想的，然後我試了一下這個：the-little-typer/pie，一門 dependent typed 的 Racket。可是這類型吧，我覺得真的太多括弧了。當然相反的，我們也可以想像，這樣一門語言對廣大想要玩一下「高級的」類型系統的 lisper，是多麼有吸引力。大家可以從這裡感受一下：The Pie Reference。但是故事到這裡還沒完，RedPRL/sml-redprl 的開發者顯然還是沒有放棄這樣精巧的對應關係（當然也可能這樣做起來簡單），它的 object language 就用的 s-exp。需知，RedPRL 是用 Standard ML 開發的（MLer 對自己用的語言的外貌可超有自信的）。

利益相關：Haskell只用於XMonad，學過SICP，平時用Scheme解析一些東西

要問Lisp到底有什麼好，不妨看看sxml，即xml的sexp等價表示。如果用ML系的Haskell來實現，先不說元素和attr是不是相同類型的問題，想構造一個haskell-xml可沒那麼直接，比如有內容的div和沒有內容的div，是不是要加以區分，是不是不能用[]而只能用()？用lisp的話就直接多了，quote、quasiquote之類的用上去就好了

至於Haskell的效率問題，王垠曾經提過thunk妨礙優化，不過這篇文章講的是為何Miranda的某些特性有利於教學，所以lazy在這方面的代價就忽略了。Lisp的實現Chez Scheme的速度倒是望塵莫及。

其他的 @開源哥 已經詳細描述了，不再展開

全文總結就是wadler吐槽scheme少4樣東西：模式匹配，語法設置，靜態類型，默認的惰性求值。不應該拿來做教學

有得必有失，除了模式匹配比較贊同以外，其他三樣都是要加重初學者學習負擔的，本來sicp的定位就是入門學習材料，scheme的定位就是用最少的語法和語義實現最多的語言功能，我覺得沒必要搞那麼複雜。何況那麼簡單的東西，還未必能搞懂

而且，動態類型和靜態類型，惰性求值和嚴格求值，只能說各有千秋吧，誰也取代不了誰，sicp第二版後來也有關於流（惰性求值）的內容

只能說wadler那時候正年輕，恰逢惰性求值語法最激情燃燒的年代，想法比較激進很正常。現在知乎上已經有人在問惰性求值是不是一個錯誤了

pattern matching 真不是什麼痛點。

倒是他提到的，quote 容易迷惑人，倒是真的。

好多lisp沒入門的人，以為自己懂得 quote是什麼，其實不懂。

強答一個。

其實這兩派最終還是殊途同歸：

Racket中已經不存在列出的這幾條問題了。Miranda以後的一系列語言也幾乎都自帶了完善的Parser Generator/Combinator工具鏈，在你還macro-expand/READ-EVAL的時候我這兒解釋器都運行起來了。

所以這個結果不是更好麼（

有點想邀請Rich Hickey來答，可惜他看不懂中文也不上知乎。最近看幾個他的演講，然後嘗試自己強行借鑒他的觀點。

http://www.softwarepreservation.org/projects/LISP (不少老前輩業已去世，若後人真想了解史況的話，請補補功課吧！)

院校學者們和行業工程師羣體都對於編程語言存在著謎之熱情，GitHub上的「後起之秀」也是五花八門，僅憑「書生意氣」「自編自導」一種「新」編程語言便妄圖揮斥方遒，指點江山？

推薦閱讀：
查看原文 >>
相關文章