作为一个程序语言的研究者，我深深的知道这种心理产生的根源。程序语言里面其实有着非常简单，永恒不变的原理。看到了它们，就可以在很短的时间之内就能学会并且开始使用任何新的语言，而不是花费很多功夫去学习一个又一个的语言。

对程序语言的各种误解

学习程序语言的人，经常会出现以下几种心理，以至于他们会觉得有学不完的东西，或者走上错误的道路。以下我把这些心理简要分析一下。

1. 程序语言无用论。这是国内大学计算机系的教育常见的错误。教授们常常对学生灌输：“用什么程序语言不重要，重要的是算法。”而其实，程序语言却是比算法更加精髓的东西。任何算法以及它的复杂度分析，都是相对于某种计算模型，而程序语言就是描述这种计算模型的符号系统。算法必须用某种语言表述出来，通常算法设计者使用伪码，这其实是不严谨的，容易出现推理漏洞。算法设计再好，如果不懂得程序语言的原理，也不可能高效的实现。即使实现了，也可能会在模块化和可扩展性上面有很大问题。某些算法专家或者数学家写出来的程序极其幼稚，就是因为他们忽视了程序语言的重要性。

2. 追求“新语言”。基本的哲学告诉我们，新出现的事物并不一定是“新事物”，它们有可能是历史的倒退。事实证明，新出现的语言，可能还不如早就存在的。其 实，现代语言的多少“新概念”不存在于最老的一些语言里呢？程序语言就像商品，每一家都为了拉拢程序员作广告，而它们绝大多数的设计都可能是肤浅而短命 的。如果你看不透这些东西的设计，就会被它们蒙蔽住。很多语言设计者其实并不真的懂得程序语言设计的原理，所以常常在设计中重复前人的错误。但是为了推销 自己的语言和系统，他们必须夸夸其谈，进行宗教式的宣传。

3. “存在即是合理”。记得某人说过：“不能带来新的思维方式的语言，是没有必要存在的。”他说的是相当正确的。世界上有这么多的语言，有哪些带来了新的思维 方式呢？其实非常少。绝大部分的语言给世界带来的其实是混乱。有人可能反驳说：“你怎么能说 A 语言没必要存在？我要用的那个库 L，别的语言不支持，只能用 A。”但是注意，他说的是存在的“必要性”。如果你把存在的“事实”作为存在的“必要性”，那就逻辑错乱了。就像如果二战时我们没能打败希特勒，现在都做 了他的奴隶，然后你就说：“希特勒应该存在，因为他养活了我们。”你的逻辑显然有问题，因为如果历史走了另外一条路（即希特勒不存在），我们会过上自由幸 福的生活，所以希特勒不应该存在。对比一个东西存在与不存在的两种可能的后果，然后做出判断，这才是正确的逻辑。按照这样的推理，如果设计糟糕的 A 语言不存在，那么设计更好的 B 语言很有可能就会得到更多的支持，从而实现甚至超越 L 库的功能。

4. 追求“新特性”。程序语言的设计者总是喜欢“发明”新的名词，喜欢炒作。普通程序员往往看不到，大部分这些“新概念”其实徒有高深而时髦的外表，却没有实 质的内涵。常常是刚学会一个语言 A，又来了另一个语言 B，说它有一个叫 XYZ 的新特性。于是你又开始学习 B，如此继续。在内行人看来，这些所谓的“新特性”绝大部分都是新瓶装老酒。很多人写论文喜欢起这样的标题：《XYZ：A Novel Method for …》。这造成了概念的爆炸，却没有实质的进步。

5. 追求“小窍门”。很多编程书喜欢卖弄一些小窍门，教你如何让程序显得“短小”。比如它们会跟你讲 “(i++) – (++i)” 应该得到什么结果；或者追究运算符的优先级，说这样可以少打括号；要不就是告诉你“if 后面如果只有一行代码就可以不加花括号”，等等。殊不知这些小窍门，其实大部分都是程序语言设计的败笔。它们带来的不是清晰的思路，而是是逻辑的混乱和认 知的负担。比如 C 语言的 ++ 运算符，它的出现是因为 C 语言设计者们当初用的计算机内存小的可怜，而 “i++” 显然比 “i=i+1″ 少 2 个字符，所以他们觉得可以节省一些空间。现在我们再也不缺那点内存，可是 ++ 运算符带来的混乱和迷惑，却流传了下来。现在最新的一些语言，也喜欢耍这种语法上的小把戏。如果你追求这些小窍门，往往就抓不住精髓。

6. 针对“专门领域”。很多语言没有新的东西，为了占据一方土地，就号称自己适合某种特定的任务，比如文本处理，数据库查询，WEB编程，游戏设计，并行计算。但是我们真的需要不同的语言来干这些事情吗？其实绝大部分这些事情都能用同一种通用语言来解决，或者在已有语言的基础上做很小的改动。只不过由于各种政治和商业原因，不同的语言被设计用来占领市场。就学习而言，它们其实是无关紧要的，而它们带来的“学习负担”，其实差不多掩盖了它们带来的好处。其实从一些设计良好的通用语言，你可以学会所有这些“专用语言”的精髓，而不用专门去学它们。

7. 宗教信仰。很多人对程序语言有宗教信仰。这跟人们对操作系统有宗教信仰很类似。其实如果你了解程序语言的本质，就会发现其实完全没必要跟人争论一些事情。某个语言有缺点，应该可以直接说出来，却被很多人忌讳，因为指出缺点总是招来争论和憎恨。这原因也许在于程序语言的设计不是科学，它类似于圣经，它没法被“证伪”。没有任何实验可以一下子断定那种语言是对的，那种是错的。所以虽然你觉得自己有理，却很难让人信服。没有人会去争论哪家的汉堡更好，却有很多人争论那种语言更好。因为很多人把程序语言当成自己的神，如果你批评我的语言，你就是亵渎我的神。解决的办法也许是，不要把自己正在用的语言看得太重要。你现在认为是对的东西，也许不久就会被你认为是错的，反之亦然。

如何掌握程序语言

看到了一些常见的错误心理，那么我们来谈一下什么样的思维方式会更加容易的掌握程序语言。

1. 专注于“精华”和“原理”。就像所有的科学一样，程序语言最精华的原理其实只有很少数几个，它们却可以被用来构造出许许多多纷繁复杂的概念。但是人们往往 忽视了简单原理的重要性，匆匆看过之后就去追求最新的，复杂的概念。他们却没有注意到，绝大部分最新的概念其实都可以用最简单的那些概念组合而成。而对基 本概念的一知半解，导致了他们看不清那些复杂概念的实质。比如这些概念里面很重要的一个就是递归。国内很多学生对递归的理解只停留于汉诺塔这样的程序，而 对递归的效率也有很大的误解，认为递归没有循环来得高效。而其实递归比循环表达能力强很多，而且效率几乎一样。有些程序比如解释器，不用递归的话基本没法完成。

2. 实现一个程序语言。学习使用一个工具的最好的方式就是制造它，所以学习程序语言的最好方式就是实现一个程序语言。这并不需要一个完整的编译器，而只需要写 一些简单的解释器，实现最基本的功能。之后你就会发现，所有语言的新特性你都大概知道可以如何实现，而不只停留在使用者的水平。实现程序语言最迅速的方式就是使用一种像 Scheme 这样代码可以被作为数据的语言。它能让你很快的写出新的语言的解释器。我的 GitHub 里面有一些我写的解释器的例子（比如这个短小的代码实现了 Haskell 的 lazy 语义）。

几种常见风格的语言

下面我简要的说一下几种常见风格的语言以及它们的问题。

1. 面向对象语言

事实说明，“面向对象”这整个概念基本是错误的。它的风靡是因为当初的“软件危机”（天知道是不是真的存在这危机）。 设计的初衷是让“界面”和“实现”分离，从而使得下层实现的改动不影响上层的功能。可是大部分面向对象语言的设计都遵循一个根本错误的原则：“所有的东西 都是对象（Everything is an object）。”以至于所有的函数都必须放在所谓的“对象”里面，而不能直接被作为参数或者变量传递。这导致很多时候需要使用繁琐的设计模式 (design patterns) 来达到甚至对于 C 语言都直接了当的事情。而其实“界面”和“实现”的分离，并不需要把所有函数都放进对象里。另外的一些概念，比如继承，重载，其实带来的问题比它们解决的 还要多。

“面向对象方法”的过度使用，已经开始引起对整个业界的负面作用。很多公司里的程序员喜欢生搬硬套一些不必要的设计模式，其实什么好事情也没干，只是使得程序冗长难懂。

那 么如何看待具备高阶函数的面向对象语言，比如 Python, JavaScript, Ruby, Scala? 当然有了高阶函数，你可以直截了当的表示很多东西，而不需要使用设计模式。但是由于设计模式思想的流毒，一些程序员居然在这些不需要设计模式的语言里也采用繁琐的设计模式，让人哭笑不得。所以在学习的时候，最好不要用这些语言，以免受到不必要的干扰。到时候必要的时候再回来使用它们，就可以取其精华，去其糟粕。

2. 低级过程式语言

那么是否 C 这样的“低级语言”就会好一些呢？其实也不是。很多人推崇 C，因为它可以让人接近“底层”，也就是接近机器的表示，这样就意味着它速度快。这里其实有三个问题：

1) 接近“底层”是否是好事？
2)“速度快的语言”是什么意思？
3) 接近底层的语言是否一定速度快？

对于第一个问题，答案是否定的。其实编程最重要的思想是高层的语义(semantics)。语义构成了人关心的问题以及解决它们的算法。而具体的实现 (implementation)，比如一个整数用几个字节表示，虽然还是重要，但却不是至关重要的。如果把实现作为学习的主要目标，就本末倒置了。因为 实现是可以改变的，而它们所表达的本质却不会变。所以很多人发现自己学会的东西，过不了多久就“过时”了。那就是因为他们学习的不是本质，而只是具体的实 现。

其次，谈语言的“速度”，其实是一句空话。语言只负责描述一个程序，而程序运行的速度，其实绝大部分不取决于语言。它主要取决于 1)算法 和 2)编译器的质量。编译器和语言基本是两码事。同一个语言可以有很多不同的编译器实现，每个编译器生成的代码质量都可能不同，所以你没法说“A 语言比 B 语言快”。你只能说“A 语言的 X 编译器生成的代码，比 B 语言的 Y 编译器生成的代码高效”。这几乎等于什么也没说，因为 B 语言可能会有别的编译器，使得它生成更快的代码。

我举个例子吧。在历史上，Lisp 语言享有“龟速”的美名。有人说“Lisp 程序员知道每个东西的值，却不知道任何事情的代价”，讲的就是这个事情。但这已经是很久远的事情了，现代的 Lisp 系统能编译出非常高效的代码。比如商业的 Chez Scheme 编译器，能在5秒钟之内编译它自己，编译生成的目标代码非常高效。它可以直接把 Scheme 程序编译到多种处理器的机器指令，而不通过任何第三方软件。它内部的一些算法，其实比开源的 LLVM 之类的先进很多。

另外一些 函数式语言也能生成高效的代码，比如 OCaml。在一次程序语言暑期班上，Cornell 的 Robert Constable 教授讲了一个故事，说是他们用 OCaml 重新实现了一个系统，结果发现 OCaml 的实现比原来的 C 语言实现快了 50 倍。经过 C 语言的那个小组对算法多次的优化，OCaml 的版本还是快好几倍。这里的原因其实在于两方面。第一是因为函数式语言把程序员从底层细节中解脱出来，让他们能够迅速的实现和修改自己的想法，所以他们能 够迅速的找到更好的算法。第二是因为 OCaml 有高效的编译器实现，使得它能生成很好的代码。

从上面的例子，你也许已经可以看出，其实接近底层的语言不一定速度就快。因为编译器这种东西其实可以有很高级的“智能”，甚至可以超越任何人能做到的底层优化。但是编译器还没有发展到可以代替人来制造算法的地步。所以现在人需要做的，其实只是设计和优化自己的高层算法。

3. 高级过程式语言

很早的时候，国内计算机系学生的第一门编程课都是 Pascal。Pascal 是很不错的语言，可是很多人当时都没有意识到。上大学的时候，我的 Pascal 老师对我们说：“我们学校的教学太落后了。别的学校都开始教 C 或者 C++ 了，我们还在教 Pascal。”现在真正理解了程序语言的设计原理以后我才真正的感觉到，原来 Pascal 是比 C 和 C++ 设计更好的语言。它不但把人从底层细节里解脱出来，没有面向对象的思维枷锁，而且有一些很好的设计，比如强类型检查，嵌套函数定义等等。可是计算机的世界 真是谬论横行，有些人批评 Pascal，把优点都说成是缺点。比如 Brain Kernighan 的这篇《Why Pascal is Not My Favorite Programming Language》，现在看来真是谬误百出。Pascal 现在已经几乎没有人用了。这并不很可惜，因为它被错怪的“缺点”其实已经被正名，并且出现在当今最流行的一些语言里：Java, Python, C#, ……

4. 函数式语言

函数式语言相对来说是当今最好的设计，因为它们不但让人专注于算法和对问题的解决，而且没有面向对象语言那些思维的限制。但是需要注意的是并不是每个函数式语言的特性都是好东西。它们的支持者们经常把缺点也说成是优点，结果你其实还是被挂上一些不必要的枷锁。比如  OCaml 和 SML，因为它们的类型系统里面有很多不成熟的设计，导致你需要记住太多不必要的规则。

5. 逻辑式语言

逻辑式语言（比如 Prolog）是一种超越函数式语言的新的思想，所以需要一些特殊的训练。逻辑式语言写的程序，是能“反向运行”的。普通程序语言写的程序，如果你给它一个输入，它会给你一个输出。但是逻辑式语言很特别，如果你给它一个输出，它可以反过来给你所有可能的输入。其实通过很简单的方法，可以不费力气的把程序从函数式转换成逻辑式的。但是逻辑式语言一般要在“pure”的情况下（也就是没有复杂的赋值操作）才能反向运行。所以学习逻辑式语言最好是从函数式语言开始，在理解了递归，模式匹配等基本的函数式编程技巧之后再来看 Prolog，就会发现逻辑式编程简单了很多。

从何开始

可是学习编程总要从某种语言开始。那么哪种语言呢？就我的观点，首先可以从 Scheme 入门，然后学习一些 Haskell (但不是全部)，之后其它的也就触类旁通了。你并不需要学习它们的所有细枝末节，而只需要学习最精华的部分。所有剩余的细节，会在实际使用中很容易的被填补上。现在我推荐几本比较好的书。

《The Little Schemer》(TLS)：我觉得 Dan Friedman 的 The Little Schemer 是目前最好，最精华的编程入门教材。这本书很薄，很精辟。它的前身叫《The Little Lisper》。很多资深的程序语言专家都是从这本书学会了 Lisp。虽然它叫“The Little Schemer”，但它并不使用 Scheme 所有的功能，而是忽略了 Scheme 的一些毛病，直接进入最关键的主题：递归和它的基本原则。
《Structure and Interpretation of Computer Programs | 计算机程序的构造和解释》(SICP)：The Little Schemer 其实是比较难的读物，所以我建议把它作为下一步精通的读物。SICP 比较适合作为第一本教材。但是我需要提醒的是，你最多只需要看完前三章。因为从第四章开始，作者开始实现一个 Scheme 解释器，但是作者的实现并不是最好的方式。你可以从别的地方更好的学到这些东西。不过也许你可以看完 SICP 第一章之后就可以开始看 TLS。
《A Gentle Introduction to Haskell》：对于 Haskell，我最开头看的是 A Gentle Introduction to Haskell，因为它特别短小。当时我已经会了 Scheme，所以不需要再学习基本的函数式语言的东西。我从这个文档学到的只不过是 Haskell 对于类型和模式匹配的概念。

过度到面向对象语言

那么如果从函数式语言入门，如何过渡到面向对象语言呢？毕竟大部分的公司用的是面向对象语言。如果你真的学会了函数式语言，就会发现面向对象语言已经易如反掌。函数式语言的设计比面向对象语言简单和强大很多，而且几乎所有的函数式语言教材（比如 SICP）都会教你如何实现一个面向对象系统。你会深刻的看到面向对象的本质以及它存在的问题，所以你会很容易的搞清楚怎么写面向对象的程序，并且会发现 一些窍门来避开它们的局限。你会发现，即使在实际的工作中必须使用面向对象语言，也可以避免面向对象的思维方式，因为面向对象的思想带来的大部分是混乱和冗余。

深入本质和底层

那么是不是完全不需要学习底层呢？当然不是。但是一开头就学习底层硬件，就会被纷繁复杂的硬件设计蒙蔽头脑，看不清楚本质上简单的原理。在学会高层的语言之后，可以进行“语义学”和“编译原理”的学习。

简言之，语义学(semantics) 就是研究程序的符号表示如何对机器产生“意义”，通常语义学的学习包含 lambda calculus 和各种解释器的实现。编译原理 (compilation) 就是研究如何把高级语言翻译成低级的机器指令。编译原理其实包含了计算机的组成原理，比如二进制的构造和算术，处理器的结构，内存寻址等等。但是结合了语义学和编译原理来学习这些东西，会事半功倍。因为你会直观的看到为什么现在的计算机系统会设计成这个样子：为什么处理器里面有寄存器 (register)，为什么需要堆栈(stack)，为什么需要堆(heap)，它们的本质是什么。这些甚至是很多硬件设计者都不明白的问题，所以它们的硬件里经常含有一些没必要的东西。因为他们不理解语义，所以经常不明白他们的硬件到底需要哪些部件和指令。但是从高层语义来解释它们，就会揭示出它们的本质，从而可以让你明白如何设计出更加优雅和高效的硬件。

这就是为什么一些程序语言专家后来也开始设计硬件。比如 Haskell 的创始人之一 Lennart Augustsson 后来设计了 BlueSpec，一种高级的硬件描述语言，可以 100% 的合成 (synthesis) 为硬件电路。Scheme 也被广泛的使用在硬件设计中，比如 Motorola, Cisco 和曾经的 Transmeta，它们的芯片设计里面含有很多 Scheme 程序。

这基本上就是我对学习程序语言的初步建议。以后可能会就其中一些内容进行更加详细的阐述。