摘要：这篇文章曾经叫做《初学者程序语言的选择》，但是后来我发现，这里给出的看法其实不只是给初学者看的，甚至可能会让初学者看不懂。而就我在 Google 实习的时候的观察看来，很多写了几十年程序的资深程序员，可能也没有明白这里指出的道理。所以我把题目改了一下，并且加入了新的内容，希望对新手和老手都有所帮助。
学习程序语言是每个程序员的必经之路。可是这个世界上有太多的程序语言，每一种都号称具有最新的“特性”。所以程序员的苦恼就在于总是需要学习各种稀奇古怪的语言，而且必须紧跟“潮流”，否则就怕被时代所淘汰。
作为一个程序语言的研究者，我深深的知道这种心理产生的根源。程序语言里面其实有着非常简单，永恒不变的原理。看到了它们，就可以一劳永逸的掌握所有的程序语言，而不是只见树木不见森林。我想写一本书，试图用最简单的方式来解释程序语言（以至于计算机科学）的根本性原理，从而让人可以在非常短的时间内掌握所有程序语言的精髓。但是在还没有完成之前，我想先提出一些建议和参考书。
对程序语言的各种误解
学习程序语言的人，经常会出现以下几种心理，以至于他们会觉得有学不完的东西，或者走上错误的道路。以下我把这些心理简要分析一下，希望可以消除一些疑惑。
1. 追求“新语言”。
基本的哲学告诉我们，新出现的事物并不一定是“新事物”，它们有可能是历史的倒退。事实证明，新出现的语言，很多还不如早就存在的。正视这个事实吧，现代语言的多少“新概念”不存在于最古老的一些语言里呢？程序语言就像商品，每一家其实都是在打广告。而绝大多数的设计，包括某些最“艰深”最“理论”的语言里面的概念，都可能是肤浅而短命的。如果你看不透这些东西的设计，就会被它们蒙蔽住。过度的热情和过多的宣传，往往意味着肤浅。很多语言设计者其实并不真的懂得程序语言设计的原理，所以常常在设计中重复的犯前人犯过的错误。但是为了推销自己的语言和系统，他们必须夸夸其谈，进行宗教式的宣传。
2. “存在即是合理”。
记得某名人说过：“不能带来新的思维方式的语言，是没有必要存在的。”他说的是相当正确的。世界上有这么多的语言，有哪些带来了新的思维方式呢？其实少之又少。绝大部分的语言给世界带来的不过是混乱。有人可能反驳说：“你怎么能说 A 语言没必要存在？我要用的那个库 L，别的语言不支持，只能用 A。”但是注意，他说的是存在的“必要性”。
如果你把存在的“事实”作为存在的“必要性”，那就逻辑错乱了。就像如果二战时我们没能打败希特勒，现在都做了他的奴隶，然后你就说：“希特勒应该存在，因为他养活了我们。”显然这个逻辑有问题，因为如果历史走了另外一条路（即希特勒不存在），我们会过上自由幸福的生活，所以希特勒不应该存在。对比一个东西存在与不存在的两种可能的后果，然后做出判断，这才是正确的逻辑。按照这样的推理，如果设计糟糕的 A 语言不存在，那么设计更好的 B 语言很有可能就会得到更多的支持，从而实现甚至超越 L 库的功能。
3. 追求“新特性”。
程序语言的设计者总是喜欢“发明”新的名词，喜欢炒作。普通程序员往往看不到，大部分这些“新概念”其实徒有高深而时髦的外表，却没有实质的内涵。常常是刚学会一个语言 A，又来了另一个语言 B，说它有一个叫 XYZ 的新特性。于是你又开始学习 B，如此继续。在内行人看来，这些所谓的“新特性”，绝大部分都是新瓶装老酒。很多人写论文喜欢起这样的标题：《XYZ：A Novel Method for ...》。这造成了概念的爆炸，却没有实质的进步。可以说这是计算机科学最致命的缺点。
4. 追求“小窍门”。
很多编程书喜欢卖弄一些小窍门，让程序显得“短小”。比如它们会跟你讲 "(i++) - (++i)" 应该得到什么结果；或者追究运算符的优先级，说这样可以少打括号；要不就是告诉你“if 后面如果只有一行代码就可以不加花括号”，等等。殊不知这些小窍门，其实大部分都是程序语言设计的败笔或者历史遗留问题。它们带来的不是清晰的思路，而是是逻辑的混乱和认知的负担。比如 C 语言的 ++ 运算符，它的出现是因为 C 语言设计者们当初用的计算机内存小的可怜，而 "i++" 显然比 "i=i+1" 少 2 个字符，所以他们觉得可以节省一些空间。现在我们再也不缺那点内存，可是 ++ 运算符带来的混乱和迷惑，却流传了下来。现在最新的一些语言，也喜欢耍这种语法上的小把戏。如果你追求这些小窍门，往往就抓不住精髓。
5. 针对“专门领域”。
很多语言没有新的东西，为了占据一方土地，就号称自己适合某种特定的任务，比如文本处理，数据库查询，Web编程，游戏设计，并行计算，或者别的什么专门的领域。但是我们真的需要不同的语言来干这些事情吗？其实绝大部分这些事情都能用同一种通用语言来解决，或者在已有语言的基础上做很小的改动。只不过由于各种政治和商业原因，不同的语言被设计用来占领市场。就学习而言，它们其实是无关紧要的，而它们带来的“多语言协作”问题，其实差不多掩盖了它们带来的好处。其实从一些设计良好的通用语言，你可以学会所有这些“专用语言”的精髓。后面我会推荐一两个这样的语言。
我必须指出，以上这些心理不但对自己是有害的，而且对整个业界有很大的危害。受到这些思想教导的人进入了公司，就会开始把他们曾经惧怕的这些东西变成教条，用来筛选新人，从而导致恶性循环。
如何掌握所有的程序语言
可以老实的说，对几乎所有风格的程序语言，我都有专家级的见解。它们在我的头脑里如此简单，以至于我不再是任何语言（包括函数式语言）的“支持者”。但是我花费了太多的时间去摸索这条道路，我希望能够提取出一些“窍门”，可以帮助人们在短时间内达到这种通用的理解。具体的细节足够写成一本书，我现在只在这里提出一些初步的建议。
1. 专注于“精华”和“原理”。
就像所有的科学一样，程序语言最精华的原理其实只有很少数几个，它们却可以被用来构造出许许多多纷繁复杂的概念。但是人们往往忽视了简单原理的重要性，匆匆看过之后就去追求最新的，复杂的概念。他们却没有注意到，绝大部分最新的概念其实都可以用最简单的那些概念组合而成。而对基本概念的一知半解，导致了他们看不清那些复杂概念的实质。比如这些概念里面很重要的一个就是递归。国内很多学生对递归的理解只停留于汉诺塔这样的程序，而对递归的效率也有很大的误解，认为递归没有循环来得高效。而其实递归比循环表达能力强很多，而且效率几乎一样。有些程序比如解释器，不用递归的话基本没法完成。
2. 实现一个程序语言。
学习使用一个工具的最好的方式就是制造它，所以学习程序语言的最好方式就是实现一个程序语言。这并不需要一个完整的编译器，而只需要写一些简单的解释器，实现最基本的功能。之后你就会发现，所有语言的新特性你都大概知道可以如何实现，而不只停留在使用者的水平。实现程序语言最迅速的方式就是使用一种像 Scheme 这样代码可以被作为数据的语言。它能让你很快的写出新的语言的解释器。我的 GitHub 里面有一些我写的解释器的例子（比如这个短小的代码实现了 Haskell 的 lazy 语义），有兴趣的话可以参考一下。
几种常见风格的语言
下面我简要的说一下几种常见风格的语言以及它们的问题。注意这里的分类不是严格的学术性质的分类，有些在概念上可能有所重叠。
1. 面向对象语言
事实说明，“面向对象”这整个概念基本是错误的。它的风靡是因为当初的“软件危机”（天知道是不是真的存在这危机）。设计的初衷是让“界面”和“实现”分离，从而使得下层实现的改动不影响上层的功能。可是大部分面向对象语言的设计都遵循一个根本错误的原则：“所有的东西都是对象（Everything is an object）。”以至于所有的函数都必须放在所谓的“对象”里面，从而不能直接被作为参数或者变量传递。这导致很多时候需要使用繁琐的设计模式(design patterns) 来达到甚至对于 C 语言都直接了当的事情。而其实“界面”和“实现”的分离，并不需要把所有函数都放进对象里。另外的一些概念，比如继承，重载，其实带来的问题比它们解决的还要多。
“面向对象方法”的过度使用，已经开始引起对整个业界的负面作用。很多公司里的程序员喜欢生搬硬套一些不必要的设计模式，其实什么好事情也没干，只是使得程序冗长难懂。不得不指出，《Design Patterns》这本书，是这很大一部分复杂性的罪魁祸首。不幸的是，如此肤浅，毫无内容，偷换概念的书籍，居然被很多人捧为经典。
那么如何看待具备高阶函数的面向对象语言，比如 Python，JavaScript，Ruby，Scala？当然有了高阶函数，你可以直截了当的表示很多东西，而不需要使用设计模式。但是由于设计模式思想的流毒，一些程序员居然在这些不需要设计模式的语言里也采用繁琐的设计模式，让人哭笑不得。所以在学习的时候，最好不要用这些语言，以免受到不必要的干扰。到时候必要的时候再回来使用它们，就可以取其精华，去其糟粕。
2. 低级过程式语言
那么是否 C 这样的“低级语言”就会好一些呢？其实也不是。很多人推崇 C，因为它可以让人接近“底层”，也就是接近机器的表示，这样就意味着它速度快。这里其实有三个问题：
接近“底层”是否对于初学者是好事？
“速度快的语言”是什么意思？
接近底层的语言是否一定速度快？
对于第一个问题，答案是否定的。其实编程最重要的思想是高层的语义(semantics)。语义构成了人关心的问题以及解决它们的算法。而具体的实现(implementation)，比如一个整数用几个字节表示，虽然还是重要，但却不是至关重要的。如果把实现作为学习的主要目标，就本末倒置了。因为实现是可以改变的，而它们所表达的本质却不会变。所以很多人发现自己学会的东西，过不了多久就“过时”了。那就是因为他们学习的不是本质，而只是具体的实现。
其次，谈语言的“速度”，其实是一句空话。语言只负责描述一个程序，而程序运行的速度，其实绝大部分不取决于语言。它主要取决于 1)算法 和 2)编译器的质量。编译器和语言基本是两码事。同一个语言可以有很多不同的编译器实现，每个编译器生成的代码质量都可能不同，所以你没法说“A 语言比 B 语言快”。你只能说“A 语言的 X 编译器生成的代码，比 B 语言的 Y 编译器生成的代码高效”。这几乎等于什么也没说，因为 B 语言可能会有别的编译器，使得它生成更快的代码。
我举个例子吧。在历史上，Lisp 语言享有“龟速”的美名。有人说“Lisp 程序员知道每个东西的值，却不知道任何事情的代价”，讲的就是这个事情。但这已经是很久远的事情了，现代的 Lisp 系统能编译出非常高效的代码。比如商业的 Chez Scheme 编译器，能在5秒钟之内编译它自己，编译生成的目标代码非常高效。它的实现真的令人惊叹，因为它的作者 R. Kent Dybvig 几乎不依赖于任何已有的软件和设计。这个编译器从最初的 parser，到宏扩展，语义分析，寄存器分配，各种优化，…… 一直到汇编器，函数库，全都是他一个人写的。它可以直接把 Scheme 程序编译到多种处理器的机器指令，而不通过任何第三方软件。它内部的一些算法，其实比开源的 LLVM 之类的先进很多。但是由于是商业软件，这些算法一直被作为机密没有发表。
另外一些函数式语言也能生成高效的代码，比如 OCaml。在一次程序语言暑期班上，Cornell 的 Robert Constable 教授讲了一个故事，说是他们用 OCaml 重新实现了一个系统，结果发现 OCaml 的实现比原来的 C 语言实现快了 50 倍。经过 C 语言的那个小组对算法多次的优化，OCaml 的版本还是快好几倍。这里的原因其实在于两方面。第一是因为函数式语言把程序员从底层细节中解脱出来，让他们能够迅速的实现和修改自己的想法，所以他们能够迅速的找到更好的算法。第二是因为 OCaml 有高效的编译器实现，使得它能生成很好的代码。
从上面的例子，你也许已经可以看出，其实接近底层的语言不一定速度就快。因为编译器这种东西其实可以有很高级的“智能”，甚至可以超越任何人能做到的底层优化。但是编译器还没有发展到可以代替人来制造算法的地步。所以现在人需要做的，其实只是设计和优化自己的高层算法。
3. 高级过程式语言
很早的时候，国内计算机系学生的第一门编程课都是 Pascal。Pascal 是很好的语言，可是很多人当时都没有意识到。大一的时候，我的 Pascal 老师对我们说：“我们学校的教学太落后了。别的学校都开始教 C 或者 C++ 了，我们还在教 Pascal。”现在真正理解了程序语言的设计原理以后我才真正的感觉到，原来 Pascal 是比 C 和 C++ 设计更好的语言。
它不但把人从底层细节里解脱出来，没有面向对象的思维枷锁，而且含有函数式语言的一些特征（比如可以嵌套函数定义）。可是由于类似的误解和误导，Pascal 这样的语言已经几乎没有人用了。这并不很可惜，因为它的精髓，其实已经存在于像 Scheme 这样的函数式语言里。Scheme 也有赋值语句，所以它实质上含有 Pascal 的所有功能。所以现在的含有赋值语句的函数式语言，可以被看作是是高级过程式语言的“改良版本”。
4. 函数式语言
函数式语言相对来说是当今最好的设计，因为它们不但让人专注于算法和对问题的解决，而且没有面向对象语言那些思维的限制。但是需要注意的是并不是每个函数式语言的特性都是好东西。它们的支持者们经常把缺点也说成是优点，结果它们其实还是被挂上一些不必要的枷锁。比如 OCaml 和 SML，因为它们的类型系统里面有很多不成熟的设计，导致你需要记住太多不必要的限制。
很多人推崇“纯函数式”语言（比如 Haskell，Clean），而极力反对其它的带有“赋值”语句的语言（比如 Scheme 和 ML）。这其中的依据其实是站不住脚的。如果你写过一个函数式语言的编译器，你就会了解如何把一个纯函数式语言翻译成机器指令。这些高级的编译器变换（比如 CPS 和 ANF），其实在本质上揭示了纯函数式语言的本质。它们其实与带有赋值语句的语言没有本质上的区别，但是由于没有赋值语句，一些事情必须拐弯抹角的实现。理智的使用局部变量或者数组的赋值，会使程序更加简单，容易理解，甚至更加高效。
5. 逻辑式语言
逻辑式语言（比如 Prolog）是一种超越函数式语言的新的思想，所以需要一些特殊的训练。逻辑式语言写的程序，是能“反向运行”的。普通程序语言写的程序，如果你给它一个输入，它会给你一个输出。但是逻辑式语言很特别，如果你给它一个输出，它可以反过来运行，给你所有可能的输入。其实通过很简单的方法，可以顺利的把程序从函数式转换成逻辑式的。但是逻辑式语言一般要在“pure”的情况下（也就是没有复杂的赋值操作）才能反向运行。所以学习逻辑式语言最好是从函数式语言开始，在理解了递归，模式匹配等基本的函数式编程技巧之后再来看 Prolog，就会发现逻辑式编程简单了很多。
从何开始
可是学习编程总要从某种语言开始。那么哪种语言呢？其实每种语言都有自己的问题，以至于在我未来的书里，会使用一种非常简单的语言，它含有所有语言的精髓，却不带有多余的东西。可是在我完成这本书之前，我想先推荐一两个现成的语言。
就我的观点，首先可以从 Scheme 入门，然后学习一些 Haskell (但不是全部)，之后其它的也就触类旁通了。你并不需要学习它们的所有细枝末节，而只需要学习最精华的部分。所有剩余的细节，会在实际使用中很容易的被填补上。我后面会提一下哪些是精华的，哪些是最开头没必要学的。
从 Scheme（而不是 Haskell）作为入门的第一步，是因为：
Scheme 没有像 Haskell 那样的静态类型系统 (static type system)。并不是说静态类型不好，但是我不得不说，Haskell 那样的静态类型系统，还远远没有发展到可以让人可以完全的写出符合事物本质的程序来。比如，一些重要的概念比如 Y combinator，没法用 Haskell 直接写出来。当然你可以在 Haskell 里面使用作用类似 Y combinator 的东西(比如 fix，或者利用它的 laziness)，但是这些并不揭示递归的本质，你只是在依靠 Haskell 已经实现的递归来进行递归，而不能实际的体会到递归是如何产生的。而用 Scheme，你可以轻松的写出 Y combinator，并且实际的投入使用。
Scheme 不需要 monad。Haskell是一个“纯函数式” (purely functional) 的语言，所有的“副作用”(side-effect)，比如打印字符到屏幕，都得用一种故作高深的概念叫 monad 实现。这种概念其实并不是本质的，它所有的功能都可以通过“状态传递” (state passing) 来实现。通过写状态传递程序，你可以清楚的看到 monad 的本质。可以说 monad 是 Haskell 的一个“设计模式”。过早的知道这个东西，并不有助于理解函数式程序设计的本质。
那么为什么又要学 Haskell？那是因为 Haskell 含有 Scheme 缺少的一些东西，并且没有 Scheme 设计上的一些问题。比如：
模式匹配：Scheme 没有一个标准的，自然的模式匹配(pattern matching) 系统，而 Haskell 的模式匹配是一个优美的实现。也有些 Scheme 的扩展实现（比如 Racket）具有相当好的模式匹配机制。
类型：Scheme 把所有不是 #f (false）的值都作为 true，这是不对的。Haskell 里面的 Boolean 就只有两个值：True 和 False。Scheme 程序员声称这样可以写出简洁的代码，因为 (or x y z) 可以返回一个具体的值，而不只是一个布尔变量。但是就为了在少数情况下可以写出短一点的代码，是否值得付出如此沉痛的代价？我看到这个设计带来了很多无需有的问题。
宏系统：宏 (macro) 通常被认为是 Lisp 系列语言的一个重要优点。但是我要指出的是，它们并不是必要的，至少对于初学者是这样。其实如果一个语言的语义设计好了，你会几乎不需要宏。因为宏的本质是让程序员可以自己修改语言的设计，添加新的构造。可是宏的主要缺点是，它把改变语言这种极其危险的“权力”给人滥用了。其实只有极少数的人具有改变一个语言所需的智慧和经验。如果让普通程序员都能使用宏，那么程序将变得非常难以理解。所以其实一般程序员都不需要学习宏的使用，也不必为略过这个东西而产生负罪感。等你进步到可以设计自己的程序语言，你自然会明白宏是什么东西。
（注意，这些是我自己的观点，并不代表 Scheme 设计者们的观点。）
推荐的书籍
《The Little Schemer》：我觉得 Dan Friedman 的The Little Schemer (TLS) 是目前最好，最精华的编程入门教材。它的前身叫《The Little Lisper》。很多资深的程序语言专家都是从这本书学会了 Lisp。虽然它叫 "The Little Schemer"，但它并不使用 Scheme 所有的功能，而是忽略了上面提到的 Scheme 的毛病，直接进入最关键的主题：递归和它的基本原则。这本书不但很薄，很精辟，而且相对于其他编程书籍非常便宜（在美国才卖 $23）。
《SICP》：The Little Schemer其实是比较难的读物，所以我建议把它作为下一步精通的读物。Structure and Interpretation of Computer Programs比较适合作为第一本教材。但是我需要提醒的是，你最多只需要看完前三章。因为从第四章开始，作者开始实现一个 Scheme 解释器，但是作者的实现并不是最好的方式。你可以从别的地方更好的学到这些东西。具体在哪里学，我还没想好（也许我自己写个教学也说不定）。不过也许你可以看完 SICP 第一章之后就可以开始看 TLS。
《A Gentle Introduction to Haskell》：对于 Haskell，我最开头看的是A Gentle Introduction to Haskell，因为它特别短小。当时我已经会了 Scheme，所以不需要再学习基本的函数式语言的东西。我从这个文档学到的只不过是 Haskell 对于类型和模式匹配的概念。Real World Haskell是一本流行的教材，但是它试图包罗万象，所以很多地方过于冗长。最根本的函数式编程概念，还是 TLS 讲的透彻。
过度到面向对象语言
那么如果从函数式语言入门，如何过渡到面向对象语言呢？毕竟大部分的公司用的是面向对象语言。如果你真的学会了函数式语言，你真的会发现面向对象语言已经易如反掌。函数式语言的设计比面向对象语言简单和强大很多，而且几乎所有的函数式语言教材（比如 SICP）都会教你如何实现一个面向对象系统。
你会深刻的看到面向对象的本质以及它存在的问题，所以你会很容易的搞清楚怎么写面向对象的程序，并且会发现一些窍门来避开它们的局限。你会发现，即使在实际的工作中必须使用面向对象语言，也可以避免面向对象的思维方式，因为面向对象的思想带来的大部分是混乱和冗余。
深入本质和底层
那么是不是完全不需要学习底层呢？当然不是。但是一开头就学习底层硬件，就会被纷繁复杂的硬件设计蒙蔽头脑，看不清楚本质上简单的原理。
在学会高层的语言之后，可以进行语义学和编译原理的学习。简言之，语义学 (semantics) 就是研究程序的符号表示如何对机器产生“意义”，通常语义学的学习包含 lambda calculus 和各种解释器的实现。编译原理 (compilation) 就是研究如何把高级语言翻译成低级的机器指令。
编译原理其实包含了计算机的组成原理，比如二进制的构造和算术，处理器的结构，内存寻址等等。但是结合了语义学和编译原理来学习这些东西，会事半功倍。因为你会直观的看到为什么现在的计算机系统会设计成这个样子：为什么处理器里面有寄存器(register)，为什么需要堆栈(stack)，为什么需要堆(heap)，它们的本质是什么。
这些甚至是很多硬件设计者都不明白的问题，所以它们的硬件里经常含有一些没必要的东西。因为他们不理解语义，所以经常不明白他们的硬件到底需要哪些部件和指令。但是从高层语义来解释它们，就会揭示出它们的本质，从而可以让你明白如何设计出更加优雅和高效的硬件。
这就是为什么一些程序语言专家后来也开始设计硬件。比如 Haskell 的创始人之一 Lennart Augustsson，后来设计了 BlueSpec，一种高级的硬件描述语言，可以 100% 的合成 (synthesis) 为硬件电路。Scheme 也被广泛的使用在硬件设计中，比如 Motorola，Cisco 和曾经的 Transmeta，它们的芯片设计里面含有很多 Scheme 程序。
这基本上就是我对学习程序语言的初步建议。