一叶见秋--编程语言能力的差异

最近在看被一些人称作“传道书”的《黑客与画家》。

好看是自然的，看这些跟计算机有些关系的却有着更多“人文关怀”色彩的经典书籍对我来说亦是一种偷懒。

毕竟《设计模式》这样的书看起来还是费劲啊。

书中作者极其推崇lisp，这点之前看阮一峰的博客便有些了解。

书中有好几章都提到了一个论点，即： 不同的编程语言的编程能力真的是有差异的，而lisp是处在金字塔顶尖的语言 。

看《SICP》过程中了解过一些Scheme的语法，其函数式令人惊叹，我曾尝试着用更通用的表达函数范式亦不错的JavaScript重写书上的实现，后来发现有前人的确做过类似的事情。

结合“传道书”等词句，我本以为作者的说法只是一种迷信，直到看到了书中的示例，并拿着几种语言去折腾了一下，却发现诚然如作者所说！

例子很简单：

写一个函数，它能够成生累加器。

即它接受一个参数n，然后返回另一个函数，后者接受参数i，然后返回n增加了i后的值。多次调用要获得累加的效果。

书中列出了各种不同语言的实现，我且拿三种我看得懂的去实践了一下。

Common Lisp没学过，此处是Scheme版本：

(define (foo n)
    (lambda (i) 
        (set! n (+ n i)) n))

还有磨人的小妖精JS:

let foo = function (n) {
    return function (i) {
        return n += i}}

书中认为：JavaScript的写法比Lisp稍微长一些，因为：

JavaScript依然区分 语句 和 表达式 ，所以需要明确指定return语句来返回一个值。

这里说的是lisp的另一点独特之处：它的语法是由它自身的数据结构链表表示的，语法解析并不是由解释器进行，或者说:

它一开始便形成于 程序员 的脑子里。

最后是 Python 的版本，可以看到，因为其lambda语法的限制，其不得不在其内部重新声名一个函数bar:

def foo(n):
    s = [n]
    def bar(i):
        s[0] += i
        return s[0]
    return bar

这三个版本输入相同的参数，运行结果是一样的，但Python明显比较冗长。

我开始不能理解为何要把n放到一个列表中然后让s指向它这种做法。以为只是一个简单的闭包，后又尝试了其他两种实现，三种结果各不相同，见下图：

这三个图中的的代码写法很相似，却得到了完全不同的结果：

一、二图的差别容易分辨，两者都实现了闭包，图二直接报错。

而一、三图的差别在于后者并未实现累加，体现了我的疑惑的点的确是内藏玄机。

分析后，会发现， 被闭包进入内部函数的外部变量在Python中无法再被改变 ，而这正是所需要函数所要的功能（真的是很简单的一个需求）。

用专业词汇来讲叫做， Python不完全支持 lexical variable 。

这也是为何使用 s=[n] 而不是 s=n ，在第一幅图中，使用了一个讨巧的写法，在Python中，数组是可变的，当其内部n改变时，s的id并不会改变。

此外，作者还给出了另外两种Python实现，一种是写一个类，另一种是在一个函数中写一个类，均是 利用Python的特点（它已支持的），来实现它还不支持的（lexical variable） 。

而这，即是编程能力的差异。

其实早在学习JS ES6语法的时候便发现所谓它的新特性，不过是实现了几十年前Lisp中早已存在的东西罢了。包括一些语法糖，及尾递归优化。

作者原话如下：

当然，我说使用其他语言无法解决这个问题，这句话不完全正确。所有这些语言都是图灵等价的，这意味着严格地说，你能使用它们之中的任何一种语言写出任何一个程序。那么，怎样才能做到这一点呢？就这个小小的例子而言， 你可以使用这些不那么强大的语言写一个Lisp解释器就好了 。

还有个比较有趣儿的“格林斯潘第十定律”，一并附上：

任何C或Fortran程序复杂到一定程度之后，都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是bug的、运行速度很慢的Common Lisp的实现。

最后，是昨晚看到的一个知乎回答及评论：