什么是“对用户友好”
可以把机器和人看作同一个系统：
- 这个系统有多个模块，包括机器模块和人类模块。
- 机器模块之间的界面使用通常的程序接口。
- 人机交互的界面就是机器模块和人类模块之间的接口。
- 每个界面必须提供一定的抽象，用于防止使用者得到它不该知道的细节。这个使用者可能是机器模块，也可能是人类模块。
- 抽象使得系统具有可扩展性。因为只要界面不变，模块改动之后，它的使用者完全不用修改。
GTF - Great Teacher Friedman
推荐了三本书
The Little Schemer
Essentials of Programming Languages
A Little Java, A Few Patterns
什么是语义学
解释器接受一个“程序”(program)，输出一个“值”(value)。
所以“语义学”，基本上就是研究各种解释器。
专门讲语义的书很少，现在推荐一本我觉得深入浅出的：《Programming Languages and Lambda Calculi》。只需要看完前半部分（Part I 和 II，100来页）就可以了。这书好在什么地方呢？它是从非常简单的布尔表达式（而不是 lambda calculus）开始讲解什么是递归定义，什么是解释，什么是 Church-Rosser，什么是上下文 (evaluation context)。在让你理解了这种简单语言的语义，有了足够的信心之后，才告诉你更多的东西。比如 lambda calculus 和 CEK，SECD 等抽象机 (abstract machine)。理解了这些概念之后，你就会发现所有的程序语言都可以比较容易的理解了。
怎样写一个解释器
非常好的文章。直接原文...
怎样写一个解释器
TeXmacs：一个真正“所见即所得”的排版系统
推荐排版系统TeXmacs
解密“设计模式”
破除对设计模式的迷信。
所谓设计模式，本质上仍然是一些基本原则的组合，如抽象等。
其中极少数值得一提的“模式”，也许是 visitor 和 interpreter。
所谓的 visitor，本质上就是函数式语言里的含有“模式匹配”（pattern matching）的递归函数。
谈语法
语法其实只是对语言的本质结构，“抽象语法树”（abstract syntax tree，AST），的一种编码。一个良好的编码，应该极度简单，不引起歧义，而且应该容易解码。在程序语言里，这个“解码”的过程叫做“语法分析”（parse）。
为什么我们却又需要语法呢？因为受到现有工具（操作系统，文本编辑器）的限制，到目前为止，几乎所有语言的程序都是用字符串的形式存放在文件里的。为了让字符串能够表示“树”这种结构，人们才给程序语言设计了“语法”这种东西。
Scheme(Lisp)中S表达式的美感。
程序语言的常见设计错误(1) - 片面追求短小
应在语义和逻辑层面追求清晰高效短小，而不是在语法上死抠几行代码。绝不会为了程序显得短小而让它变得难以理解或者容易出错。
“解决问题”与“消灭问题”
解决问题之前，先从高层次上思考问题为什么存在，可否消灭。
Chez Scheme 的传说
Chez Scheme是高性能的Lisp 编译器
解释器之所以大部分时候比编译器慢，是因为解释器“问太多的问题”。每当看到一个构造，解释器就会问：“这是一个整数吗？”“这是一个字符串吗？”“这是一个函数吗？”…… 然后根据问题的结果进行不同的处理。这些问题，在编译器的理论里面叫做“解释开销”（interpretive overhead）。编译的本质，其实就是在程序运行之前进行“静态分析”，试图一劳永逸的回答这些问题。于是编译后的代码根本不问这种问题，它直接就知道那个位置肯定会出现什么构造，应该做什么事，于是它就直接去做了。
什么是“脚本语言”
脚本语言的设计初衷是“批量式”的执行命令，你在一个文件里把命令都写进去，然后执行这个文件。
我们应该尽一切可能避免使用脚本语言。在没有办法的情况下（比如老板要求），也应该在脚本里面尽可能的使用通常的程序设计原则。
函数式语言的宗教
我们完全没有必要追求什么“纯函数式语言”，因为我们可以在不引起混淆的前提下使用赋值语句，而写出真正的“纯函数”来。可以自由的对变量进行赋值的语言，其实超越了通常的数理逻辑的表达能力。
惰性求值
“惰性”却在另外一方面带来了巨大的开销，这就是“问问题”的开销。每当看到一个变量，Haskell 都会问它一个问题：“你被求值了没有？”即使这变量已经被求值，而且已经被取值一百万次，Haskell 仍然会问这个问题：“你被求值了没有？”问一个变量这问题可能不要紧，可是 Haskell 会问几乎所有的变量这个问题，反复的问这个问题。这就累积成了巨大的开销。跟我在另一篇博文里谈到的“解释开销”差不多，这种问题是“运行时”的，所以没法被编译器“优化”掉。
为什么惰性求值会跟并行计算的目标相冲突。这其实很明显，它的原因就在于“惰性求值”的定义。惰性求值说：“到需要我的时候再来计算我。”而并行计算说：“到需要你的时候，你最好已经被某个处理器算出来了。”所以你看到了，并行计算要求你“勤奋”，要求你事先做好准备。而惰性求值本来就是很“懒”，怎么可能没事找事，先把自己算出来呢？由于这个问题来自于“惰性求值”的定义，所以这是不可调和的矛盾。
所以，惰性求值不管是在串行处理还是在并行处理的时候，都会带来效率上的大打折扣，它是一个很鸡肋的语言特征。
虽然惰性求值不能给我们带来直接的益处，但它背后的理论思想却可以启发另外的设计。
Currying 的局限性
currying 会给读者带来认知上的负担，而在写者表达稍复杂些的函数构造时，显得很鸡肋。尽量不要再写程序时用currying，以“笨办法”不变应万变。
谈程序的“通用性”
在设计程序的时候，我们最好是先把手上的问题解决好。如果发现这段代码还可以被用在很多别的地方，到时候再把框架从中抽象出来也不迟。
程序语言的常见设计错误(2) - 试图容纳世界
动态语言，容易产生很多bug
