学习程序语言是每个程序员的必经之路。可是这个世界上有太多的程序语言，每一种都号称具有最新的&特性&。所以程序员的苦恼就在于总是需要学习各种稀奇古怪的语言，而且必须紧跟&潮流&，否则就怕被时代所淘汰。
　　作为一个程序语言的研究者，我深深的知道这种心理产生的根源。程序语言里面其实有着非常简单，永恒不变的原理。看到了它们，就可以在很短的时间之内就能学会并且开始使用任何新的语言，而不是花费很多功夫去学习一个又一个的语言。
　　对程序语言的各种误解
　　学习程序语言的人，经常会出现以下几种心理，以至于他们会觉得有学不完的东西，或者走上错误的道路。以下我把这些心理简要分析一下。
　　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 anobject）。&以至于所有的函数都必须放在所谓的&对象&里面，而不能直接被作为参数或者变量传递。这导致很多时候需要使用繁琐的设计模式(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 的这篇《》，现在看来真是谬误百出。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 Interpretationof Computer Programs》(SICP)：TheLittle Schemer 其实是比较难的读物，所以我建议把它作为下一步精通的读物。SICP 比较适合作为第一本教材。但是我需要提醒的是，你最多只需要看完前三章。因为从第四章开始，作者开始实现一个 Scheme 解释器，但是作者的实现并不是最好的方式。你可以从别的地方更好的学到这些东西。不过也许你可以看完 SICP 第一章之后就可以开始看 TLS。
　　《A Gentle Introduction to Haskell》：对于 Haskell，我最开头看的是 A GentleIntroduction to Haskell，因为它特别短小。当时我已经会了 Scheme，所以不需要再学习基本的函数式语言的东西。我从这个文档学到的只不过是 Haskell 对于类型和模式匹配的概念。
　　过度到面向对象语言
　　那么如果从函数式语言入门，如何过渡到面向对象语言呢？毕竟大部分的公司用的是面向对象语言。如果你真的学会了函数式语言，就会发现面向对象语言已经易如反掌。函数式语言的设计比面向对象语言简单和强大很多，而且几乎所有的函数式语言教材（比如 SICP）都会教你如何实现一个面向对象系统。你会深刻的看到面向对象的本质以及它存在的问题，所以你会很容易的搞清楚怎么写面向对象的程序，并且会发现一些窍门来避开它们的局限。你会发现，即使在实际的工作中必须使用面向对象语言，也可以避免面向对象的思维方式，因为面向对象的思想带来的大部分是混乱和冗余。
　　深入本质和底层
　　那么是不是完全不需要学习底层呢？当然不是。但是一开头就学习底层硬件，就会被纷繁复杂的硬件设计蒙蔽头脑，看不清楚本质上简单的原理。在学会高层的语言之后，可以进行&语义学&和&编译原理&的学习。
　　简言之，(semantics)就是研究程序的符号表示如何对机器产生&意义&，通常语义学的学习包含 lambda calculus 和各种解释器的实现。编译原理(compilation)就是研究如何把高级语言翻译成低级的机器指令。编译原理其实包含了计算机的组成原理，比如二进制的构造和算术，处理器的结构，内存寻址等等。但是结合了语义学和编译原理来学习这些东西，会事半功倍。因为你会直观的看到为什么现在的计算机系统会设计成这个样子：为什么处理器里面有寄存器(register)，为什么需要堆栈(stack)，为什么需要堆(heap)，它们的本质是什么。这些甚至是很多硬件设计者都不明白的问题，所以它们的硬件里经常含有一些没必要的东西。因为他们不理解语义，所以经常不明白他们的硬件到底需要哪些部件和指令。但是从高层语义来解释它们，就会揭示出它们的本质，从而可以让你明白如何设计出更加优雅和高效的硬件。
　　这就是为什么一些程序语言专家后来也开始设计硬件。比如 Haskell 的创始人之一 Lennart Augustsson 后来设计了 BlueSpec，一种高级的硬件描述语言，可以 100% 的合成 (synthesis) 为硬件电路。Scheme 也被广泛的使用在硬件设计中，比如 Motorola, Cisco 和曾经的 Transmeta，它们的芯片设计里面含有很多 Scheme 程序。
　　这基本上就是我对学习程序语言的初步建议。以后可能会就其中一些内容进行更加详细的阐述。The Little Schemer 中文版 - 简书
The Little Schemer 中文版
The Little Schemer 中文版
前言五项规则car的规则car只对非空列表有定义。
cdr的规则cdr只对非空列表有定义。任何非空列表的cdr是另外一个列表。
cons的规则cons有两个参数。cons的第二个参数必须是一个list，结果也是一个list。
Null的规则Null仅为list定义。
eq的规则eq有两个参数。每一个参数都是非数值atom
The Little Schemer第四版Daniel P. FriedmanIndianna University Bloomington, IndianaMatthias FelleisenRice University Houston TexasThe MIT Press Cambridge, Massachusetts London, England
此前言是第三版The Little LISPer 的前言。经过作者的允许，我们把它放在这里。1976年，我在学习摄影入门。大多数学生（包括我）学习这们课程是为了变得跟有创造力——拍摄出我敬仰的艺术家 Edward Weston 那样的艺术作品。第一天，老师耐心的讲解了我们这学期将要学习到的技术技巧。重点是Ansel Adams的“Zone System”，用来预可视化冲印照片的值（打印的亮度）和在场景中获得他们的光照强度。为了获得这种技术，我们必须学会使用曝光计测量光的强度和曝光时间的使用和发展的时间来控制的黑色层次和图像的对比度。而这需要耕地层次的技术比如装底片，开发及冲印，混合化学品。摄影师必须学会仪式化敏感材料制定的过程中，使 多年的工作，得到一致的结果。第一次进实验室，满是滑湿的手感，定影液臭气熏天。但是创意成分呢？为了有创造力，你必须要能控制媒介。没有这些必备的技能是不可能拍摄出伟大的摄影作品的。工程技术，其他的创造性的艺术，我们必须学习分析来支持综合的成果。一个人不可能没有钢铁泥土的知识和计算结构的数学技术去建造一座华丽和实用的桥梁。同样一个人不可能不深入理解如何“预可视化”他/她写的程序产生的进程而构造出精巧的的计算机系统。一些摄影师选择8×10格而其他人选择35mm的片，这各有各的有缺点。如同摄影，编程序需要选择媒介。Lisp是一种自由和富有弹性的媒介。Lisp 是为递归论和符号代数而构造的理论体系。它已经发展成为一个独一无二的强大和灵活的软件开发工具的家庭体系，Lisp 为快速原型软件系统提供 wrap-around 支持。与其他语言一起，Lisp 为了使用用户社区提交的各种巨大的库当作胶水语言。Lisp 中，procedures是一等数据，被当作参数，返回值，存储在数据中。这种弹性是有价值的，并且更重要的是它提供了通用模式使用必不可少的工程设计——idioms——的正式设立，命名和简化的机制。另外，Lisp 程序可以很容易地操控Lisp程序。这是一个推动程序合成和分析工具大力发展的功能，例如交叉引用。The Little Lisper 方法独特以培养读者在 Lisp 中基础的创意的编程技能。它循序渐进的包含了学习构造递归和操作递归数据结构所需要的训练和练习。The Little LISPer 对与学生学习 Lisp 程序犹如 Hanon 的指法练习或者 Czerny 的练习曲对于学生学习钢琴弹奏一样。Gerald J. SussmanGambridge, MassachusettsPreface
为了庆祝Scheme的20周年纪念，我们修订The Little LISPer第三次，给了一个更加准确的名字The Little Schemer，和续集The Seasoned Schemer.程序接受数据和产生数据。设计程序需要对数据有透彻的理解；好的程序反映了数据的结构。大多数数据和大多数程序是递归的。递归是定义一个对象或者靠自己解决解决一个问题的行为。本书的目的是教会读者递归。第一个问题是使用何种程序来交流这种概念，三种选择：自然语言，如英语；正式数学；或者程序语言。自然语言时含混的不精确的，有时还笨拙冗长。这些是一般交流的优势，但是有时这对交流一些概念，如递归很不简洁。数学与自然语言相反：使用极少的符号就可以表达出强大且正式的想法。不幸的是，数学语言常常是隐蔽的，没有特殊训练几乎不能运用。技术和数学的联姻给我们第三中选择，一个几乎完美的选择：程序语言。我们认为程序语言时是最好的描述递归的方法。他们分享了数学给符号以正式意义的能力。但是与数学不同的是，程序语言是可以直接体验的——你可以拿着本书中的程序，观察他们的行为，修改他们，体验这些修改的效果。也许教授递归的最好程序语言就是Scheme。Scheme语言本质上是符号性的——程序员不需要考虑他的自已的语言的符号之间的关系以及计算机中表示的关系。递归是Scheme天生的运行机制；程序的初始行为是（潜在的）创建递归定义。Scheme语言的实现主要是交互的，程序员可以立即参与和观察他的程序的行为。另外，这本书中最重要的是，Scheme程序的结构和这些程序操作的数据之间有着直接的对应。尽管Scheme可以被描述的很正式，理解Scheme却不需要特别的数学角度。实际上，The Little Schemer 是基于向没有编程经历和承认不喜欢任何数学的学生在两周内介绍Scheme快速入门的演讲稿。许多这些同学准备公共事业作为职业。我们认为写Scheme的递归程序本质上就是简单的模式匹配。既然我们唯一考虑的是递归编程，我们仅仅限定处理Scheme特性的一些“为什么”：car, cdr, cons, eq?, null?, zero?, add1, sub1, number?, and, or, quote, lambda, define, 和cond。确实，我们的语言是理想化的Scheme。The Little Schemer 和 The Seasoned Schemer将不会引导你实际的编程，但是掌握书中的这些概念会让你理解计算的本质。
阅读本书需要读者：认得字，认识数，会算术。
感谢*(略了)
不要快速略读本书。要细细的读；有意义的提示散布在课文中。阅读本书不要少于3次settings。系统地读。如果你没有完全读懂一章，下一章你懂得更少。问题难度渐增；前边的问题不能解决，遇见后边的将束手无策。本书是以对话的形式套路你有趣的Scheme程序例子。如果你可以，读书的时候做作习题。Scheme是可用的。尽管Scheme的不同实现有微小的语法变化（主要是特殊函数的名称和domain的拼写），所有的Scheme都是一样的。为了使用Scheme，你需要定义atom?, sub1, 和add1。我们在The Little Schemer中介绍：(define atom? (lambda (x) (and (not (pair? x)) (not (null? x)))))
为了找出你的Scheme是否定义了正确的atom?, 尝试(atom? (quote ()))然后确保它返回#f。实际上，这在现代Lisp，如Common Lisp中是自带的。为了使用Lisp，你还需要添加函数atom?:(defun atom? (x) (not (listp x)))
另外你需要做一些程序的修改。特别的，只需要微小的修改。如何尝试修改这些程序的建议在framenotes中。Framenotes中有“S：”的是Scheme相关的，那些有”L:”的是Lisp相关的。第四章中我们将会从add1，sub1和zero？三种操作中获得基本的算术。Scheme本身没有提供add1和aub1，你必须用内建的基元定义加法和减法。为了避免circularity我们的算术加法和减法我们必须分别使用不同的符号：+和-。在本书中我们没有给出任何的正式定义。我们认为你得到你自己的定义然后理解记忆他们比我们写给你的好。但是要确信使用前你得透彻理解规则。学习Scheme的关键是“模式匹配“，戒律指出了你看到过的模式。本书中初期，概念简化了；后期，概念得以拓展和限定。记住本树种所有的东西都是Scheme。Scheme本身具有一般普遍性，它包涵了远远多于我们书本中介绍的内容。你掌握了这本书后，就可以阅读更加综合性的Scheme书了。我们整个的文本中使用了一些符号约定，主要是对不同类别的符号有字体的变化。变量和基本操作符的名称使用斜体。基本数据包括数和真假值是用sans serif。如define, lambda, cond, else, and, or和quote是粗体。当你尝试程序时注意framenotes而应忽略字体。为了突出字体的作用，framenotes中的程序使用打字机字体。当到第十章我们忽略这种字体的区分，在那里我们把程序和代码一视同仁。最后，Webster把“punctuation”定义为“断句”行为；特别是，为了分隔语句和语句元素使其易懂明了，而使用标准标记来书写和打印的行为。我们已经从字面上采取了这一定义。为了使意思更清晰，我们已经放弃了一些熟悉的使用标点符号。具体来说，当在程序中时，我们丢弃在左栏标点符号的使用。食品在我们的例子当中出现了很多次。首先，食物比起抽象符号更加容易形象化。（这书作为在消化的时候的读物可不适合 。可别吐一地：)我们希望食物可以帮助你理解我们使用的例子和概念。第二，我们想给你分分心。我们知道这门课程让人多沮丧，分心帮你保持理智。你可以开始了。祝好运！我们希望你能够享受接下来的挑战。Bon appetit !Daniel P. FriedmanMatthias Felleisen
Powered by
| Copyright 2014 - 2014 by
一个会写诗的程序员。