众人落座之后，冒号鸣锣开场：“上两节课为大家介绍了多种编程范式，虽未将所有类型尽囊其中，但最具代表性的均在其列。我们也不必贪多求全，俗话说得好：贪多嚼不烂啊。现在给大家一个知识反刍的机会。”

问号正感求之不得：“总算可以喘口气了。我们就像观光客，被导游带着从一个景点赶往另一景点。一天下来，虽然大开眼界，但都是走马观花，无法充分领略各地的风光。”

“你说得没错，我就是那个不近情理的导游。”冒号哈哈一笑，“类似时下流行的欧洲N国M日游，大部分人的收获就是一堆照片和日渐模糊的记忆。不出多日，如果不看标注，八成连照片上的背景是在法国还是在意大利都分不清了。”

逗号颇有同感：“差不多，目前我的收获就是一堆幻灯片和似懂非懂的概念。”

冒号料有此果：“这一点也不奇怪。别说几天游一个国家，单一个罗马，没有一个月是不可能深入了解的。至于编程范式，单一个OOP，没有两年以上的实践和思考，是难以真正领会其精髓的。”

叹号深表怀疑：“OOP需要两年以上才能领会？！”

“那还得看你是否有足够的勤奋和悟性。”冒号加强了语气，“前面说过，单靠记忆只能触及知识之表，单靠练习只能深入知识之里，唯有培养方能渗透知识之根。编程范式正处知识的根部，你们又怎能奢望只听几堂课即豁然贯通呢？”

引号表达自己的感受：“虽然学了不少东西，但也存了不少疑惑，搁在心里有点不舒服。”

“我明白你的意思。凡事追根究底是一种良好的学习习惯，也是一种可贵的学习精神。” 冒号表示理解和肯定，“但学习如打仗，除了要有直线式的纵深攻击，还要有曲线式的迂回包抄。回顾我们中学的课堂，往往是每引入一个概念或理论，便围绕其作深入的学习和反复的练习。在此过程中的种种疑惑，随着学习的深入都会烟消云散。这样稳扎稳打、层层推进，学得扎实，心里也踏实。但这种方法并不总是最好的，尤其在面临动态的、开放的知识体系时，难免左支右绌。为此，我们必须学会适度地容忍无知。请注意，容忍无知不是放任无知，而是一种学习的技巧，让无知成为求知的动力而不是障碍。容忍无知能使我们既不沮丧气馁，也不急于求成。在学习时不妨略过一些细节或难点，先概览全貌以获取感性认识，然后在逐步积累中升华为理性认识。要而言之，我们不仅需要强调钻劲和深度的‘钉子精神’，还需要强调磨功和广度的‘刨子精神’。我一口气兜售这么多编程范式，就是为了刺激大家求知欲，同时为大家进行第一道刨磨。”

引号得到一些安慰：“看来今后我们还会故地重游的。”

“不仅会重游，而且会‘深度游’。” 冒号肯定地说，“此番我们一路行色匆匆，若能感受到途中景色带来的感官冲击，便算是不枉此行了。其实，把编程范式类比旅游景点并不十分准确，或许比作当地的风俗文化更确切些。”

句号立刻会意：“景点是具体的，背后的风俗文化是抽象的；编程语言是具体的，背后的编程范式是抽象的。”

“此乃其一。”冒号右手伸出食指，“其二，如果不了解景点的历史文化和风俗人情，仅仅满足于表面的奇观异景，一切很快便会淡忘。比如说，你若不了解圣经文化、不了解文艺复兴史，则欧洲之行至多只是视觉的盛宴，而非文化的洗礼，收获将是有限的，印象将是肤浅的。同样，如果你不了解编程范式，那么眼中的编程语言只是语法、语义、核心库、规范等组成的集合，写出的代码虽能编译、能工作，却会显得生硬、别扭。就像中式英语，语法正确、表达也正确，可就是不正宗、不地道。其症结我们在第一节课中已经提过了，即所谓的语感缺失。”

问号实话实说：“可我还是不明白编程范式如何提高我们的编程语感。”

“那就让我们再说说范式吧。”冒号并不着急，“范式可以粗略理解为模范、模型、模式、风格、流派等等。软件中的范式除了编程范式外，还有架构范式^[1]、数据库范式^[2]等。比如，对象导向式（Object-Oriented）可以应用于编程、架构和数据库中，分别成为OOP（Object-Oriented Programming）、OOA（Object-Oriented Architecture）和OODB（object-oriented database）；类似地，事件驱动式（Event-Driven）可以是一种编程范式，可以是一种架构模型，也可以是一种设计模式。总之，每种范式都代表着一套独特而有效的解决问题的思想和方法。掌握范式对编程语感的提高至少有两层作用：首先，编程语言的语法、语义等都是从编程范式的树根衍生而出的枝叶，把握了这种脉络和节奏，代码才会如音乐舞蹈般韵律有致；其次，每种范式擅长的问题领域不尽相同，只有博闻广识，方可扬长避短，程序才会如行云流水般流畅自然。”

逗号添油加醋：“武功练至化境，一定是博采众长，就像杨过融合了东邪、西毒、南帝、北丐、中神通等各派武功，才能随心所欲地打出黯然销魂掌来。”

提起武侠人物，众人俱是逸兴遄飞，哪能体会到半点黯然消魂之伤？

冒号道：“天下之理，殊途同归。我们停止玄玄之论，用实例来说明吧。谁来介绍一下快速排序法（quicksort）？”

众人飞舞的思绪渐渐收敛，终于由引号作答：“快速排序法的思想是：在列表中找一个基准元素，将所有小于它的元素划归一个子列，置于其前；将所有大于等于它的元素划归另一子列，置于其后。然后递归地对前后两个子列作同样处理，直至最终。”

“很好，让我们用Java来实现一下该算法。”冒号显示出一段代码——

/** 快速排序法的Java实现 */
public class Sorter
{
    public static <T extends Comparable<? super T>> void qsort(T[] list)
    {
        qsort(list, 0, list.length - 1);
    }

    private static <T extends Comparable<? super T>> void qsort(T[] list, int low, int high)
    {
        if (low >= high) return;

        int i = low - 1, j = high + 1;
        T pivot = list[low]; // 基准元素

        for ( ; ; )
        {
            do { ++i; } while (list[i].compareTo(pivot) < 0);
            do { --j; } while (list[j].compareTo(pivot) > 0);

            if (i >= j) break;

            // 交换
            T tmp = list[i]; list[i] = list[j]; list[j] = tmp;
        }

        // 找到分割点j，递归
        qsort(list, low, j);
        qsort(list, j + 1, high);
    }
}

“请问这里用到了哪些编程范式？”冒号提问。

叹号心想，有何难哉？遂答：“既然是用Java实现的，自然少不了OOP。同时为了使算法更具普适性，还用到了泛型编程。”

“你好像忘记了最重要的过程式，反倒是OOP的色彩极淡。”冒号显然不满意他的答案。

叹号不解：“不是说Java是100%的OOP语言吗？”

冒号颇为不屑：“不要轻信这种浮浅之论。且不说Java的基本类型（primitive type）不属于类（class），本就不是100%的OOP，即使是100%的OOP，那与过程式也不矛盾啊。此例中的Sorter类连一个实例成员（instance member）也没有，唯一与OOP沾边的是作为interface的Comparable，在C中也可用函数指针代替。如果不考虑泛型式的特征，本例无论用Java还是用C，并没有本质差别。事实上，对于这类纯算法的问题，OOP范式本无太多用武之地。换句话说，quicksort虽然是通过以OOP著称的Java来实现的，但用的主要还是过程式的思想和方法。”

问号赶紧问道：“还能用其他范式来实现吗？”

此问正合冒号之意：“我们改用纯函数式语言Haskell来试试——”

-- 快速排序法的Haskell实现 
qsort :: (Ord a) => [a] -> [a]  --函数声明
qsort[] = []                    --递归终点 
qsort(pivot : rest) = qsort[x| x <- rest, x < pivot]         --对前面的子列递归
                          ++ [pivot]
                          ++ qsort[x| x <- rest, x >= pivot] --对后面的子列递归

叹号几不能信：“竟然可以如此精炼？”

“上面的Java代码很难再精简了，但与Haskell代码相比还是太冗长了。后者省去了所有的赋值、迭代和流程控制，只有单纯的递归，反映了典型的函数式特征。”冒号解说着，“鉴于你们对Haskell不太熟悉，我稍微解释一下。第一步，声明函数类型^[3]：同类型列表之间的变换，其中Ord可类比Java中的Comparable，以保证列表元素之间能进行比较；第二步，声明递归终点：空列排序后仍是空列；第三步，描述递归原则：基准元素pivot与剩余子列rest进行排序后的列表，正是将小于基准的子列和超过基准的子列分别排序，中间插入基准元素后的结果。”

句号思有所得，不禁喜形于色：“我明白了，这两段代码生动地反映了命令式编程与声明式编程之间的差别：前者需要指定计算的过程，后者只需指定计算的原则。一个着重微观的细节，一个着重宏观的方向，自有繁简之别。”

冒号亦有所慰：“非常好！类似的话我以前也说过，但你们自己说的才是真正的收获啊。我们还提过，过程式与函数式的差别同时也是机器思维与数学思维的差别。不妨对比Haskell表达式与数学中的集合表达式，它们是多么地相近！”

黑板上出现两行式子——

数学表达式：   {x| x ∈ rest, x < pivot} 
Haskell表达式：[x| x <- rest, x < pivot] 

逗号仔细打量着：“嗯，的确像，跟哥俩似的，连符号<-都是仿照集合属于符（∈）的。”

“还有另一种表达方法。”冒号又添加了一行——

Haskell表达式2 ：(filter (< pivot) rest) 

“虽然与前一表达式的简洁度相差无几，但可读性更强。filter即是过滤，将列表rest中的元素进行筛选，条件是小于基准元素。”冒号讲解道。

问号略感迷惑：“（< pivot）的用法看起来有点怪异。”

“它是一个函数，也是filter的第一个参数，用来判断第二个参数rest的元素是否合格，即 < pivot。这体现了函数式的一个重要特征：函数是头等公民（first-class citizen）——可作为传递参数、可作为表达式的值、可嵌入数据结构、也可与某变量绑定，与普通的基本数据类型毫无二致。这类函数更数学化的叫法是高阶函数（higher-order function），它是函数式编程简洁而强大的重要根源。”冒号细加解释，“大家还记得上节课谈到的回调函数吧？callback无非是将函数作为参数来传递，本质上是将代码当数据来使用，回调机制的巨大威力均拜此高级用法所赐。”

众人又一段经脉被打通了。

引号提出一个很实际的问题：“函数式编程的确很酷，可Java并不支持。如果采用Haskell之类的函数式语言，会不会带来系统集成上的困难？”

冒号打消了他的疑虑：“Java平台下已经集成了不少的支持函数式编程的语言，如JRuby、Jython、Groovy、Scala等，甚至Haskell在JVM下也有相应的Jaskell。其中，Groovy与Java的结合最为自然。此外，C#3.0引入了lambda表达式，也能方便地支持函数式。我们看一下它们是如何实现quicksort的——”

/** 快速排序法的Groovy实现 */
def qsort(list) {
    if (list.size() <= 1) return list

    def pivot = list[0]
    return (qsort(list.findAll{x -> x < pivot})
          +             list.findAll{x -> x == pivot}
          +    qsort(list.findAll{x -> x > pivot}))
} 

/** 快速排序法的C#3.0实现 */
IEnumerable<T> qsort<T>(IEnumerable<T> list) where T : IComparable<T>
{
    if (list.Count() <= 1) return list;

    var pivot = list.First();
    return qsort(list.Where(x => x.CompareTo(pivot) < 0))
                .Concat(list.Where(x => x.CompareTo(pivot) == 0))
                .Concat(qsort(list.Where(x => x.CompareTo(pivot) > 0)));
} 

“以上两种方法如出一辙，虽然比Haskell的代码略长了些，并且还带着过程式的烙印，但总体思想还是函数式的。”冒号紧扣本质，“函数式还有一个重要特征：无副作用或尽量减少副作用^[4]。所谓无副作用，是指一个函数在被调用前后保持程序的状态不变。无副作用的函数不会改变非局部变量的值，不会改变传入的参数，也没有I/O操作。”

逗号脱口而出：“什么状态都不变，那这样的函数有什么用？”

冒号不以为奇：“你的这种想法源自根深蒂固的命令式思维。我们曾把命令式程序比作状态自动机，其运行过程就是在不断地修改机器的状态。而函数式程序则是进行表达式变换，一般不会改变变量的值。其实函数式并非完全不改变内存，只不过改变的是栈内存（stack）罢了。换言之，无副作用函数的作用关键在于其估值结果，按过程式的说法是返回值。刚才的quicksort不正是如此吗？”

逗号如梦初醒。

冒号旋即补充：“当然，在涉及流程控制、顺序操作、状态维护、I/O运算等问题时，没有副作用是很不方便的。函数式语言一般也会提供变通的方式，比如Haskell、Ruby、Python、Scala等语言支持的monad便是这样一种机制。”

问号仍有疑问：“药物最好没有副作用，函数没有副作用的好处是什么？”

冒号嘴一咧：“好处太多了。首先，没有副作用的函数易于重构、调试和单元测试。其次，代码有效性与函数顺序无关，方便并发处理和优化处理。举个简单的例子，计算两个函数的乘积：f(x) * g(y)。由于无副作用，f(x) 和g(y)的估值过程是独立的，估值顺序也不重要，因此理论上可以对二者并行计算。另外，还可利用惰性求值（lazy evaluation）^[5]：如果算出f(x)为零，那么不用计算g(y)便可知乘积为零了。”

叹号忍不住赞叹：“听起来真不错！”

冒号突然扭头写下一行字，然后提问：“请问这个unix命令表示什么意思？”

grep the BigFile.txt | head 

引号回答：“这是要打印出文件BigFile.txt中包含字符串‘the’的十行文字。”

冒号点头：“没错，这是unix管道（pipe）的用法。它由两个命令组成：grep和head，前者的输出是后者的输入。一个有趣的事实是，后者不用等到前者执行完毕才启动。更有趣的是，只要后者获取了足够的数据，前者便会停止执行。故而当grep在给定文件中找到含有给定字符串的十行文字后，即可功成身退，因为那已是head的全部所需。假如没有管道机制，那就只能这样——”

grep the BigFile.txt > tmpfile; head tmpfile 

“这样不仅产生了多余的临时文件，而且效率大大降低。这与惰性求值有关吗？”句号隐隐明白了冒号的用意。

“类似地，通常要计算f(g(x))的值，需要计算完g(x)后才能将所得值代入函数f。有了惰性求值机制，g(x)的计算完全由函数f的需求来驱动，避免做无用功。此乃其惰性之所在。”

逗号挑起大拇指：“这个懒偷得真聪明！”

“惰性求值不仅能节省有限的时间，还能超越无限的时间——g(x)甚至可以永不退出，从而可能产生无穷的输出结果集供函数f使用。这可是在过程式编程中想都不敢想的事啊。”冒号言犹未尽，“最后，没有副作用的函数是引用透明的（referential transparency），即一个表达式随时可以用它的值来替换^[6]，正如数学中的函数一样，保证了数学思维的贯彻和运用。”

引号自感获益颇丰：“前面介绍范式时，觉得函数式最为神秘。现在总算有了些感性认识了。”

冒号道出缘由：“函数式编程不仅有许多独特的概念和方法，还有很深的数学背景——λ-演算（lambda calculus）。如果一开始便倾囊相授，你们必会望而却步，我岂不是打草惊蛇了？”

众人始觉：老冒狡猾狡猾的，原来在诱敌深入啊。

“尽管函数式有这么多优点，运算能力从理论上比诸过程式也毫不逊色^[7]，但一直没有成为主流范式。”冒号话锋一转，“细究之，至少有两方面的原因：主观上，程序员更习惯机器风格的过程式思维和现实风格的OOP思维，不容易接纳数学风格的函数式思维；客观上，函数式语言在表现力和运行效率^[8]等方面与过程式和OOP语言也有一定的差距。饶是如此，支持它的语言还是越来越多，其简洁精巧的特性也为越来越多的人所青睐。它的整体应用虽然主要集中于数学计算、人工智能等领域，但局部应用早已遍地开花了。”

逗号好奇地问：“还有其他类型的编程范式吗？”

“不但有，而且有很多。”冒号喝了一口水，悠悠地说，“并发式编程（concurrent programming）就是其中之一。”

叹号有些惊讶：“并发式编程也算一种范式？它似乎更像是提高运行效率的一种手段。”

“大谬不然。”冒号摇摇头，“真正的并发式编程，绝不只是调用线程^[1]API或使用synchronized、lock之类的关键字那么简单。从宏观的架构设计，到微观的数据结构、流程控制乃至算法，相比通常的串行式编程都可能发生变化。随着硬件性能和用户需求的双重提升，并发式编程已成为不可回避的主题。毫不夸张地说，并发式编程是继OOP之后又一场思想和技术上的革命。只是相比OOP，尽管年龄相仿，但语言上不够支持，标准上不够统一，理论上不够完善，因而这场革命更具破坏性和建设性。现在我们来看一个例子，比较两种烧水泡茶的方案。”

说着冒号在黑板上写下——

引号见多识广：“我记得这好像是运筹学中的例子，显然方案二更佳。从编程的角度来看，方案一是串行式编程，方案二是并发式编程——烧水的线程与洗茶杯放茶叶的线程是同时进行的。”

“如果方案一也用并发式编程呢？”冒号追问。

引号一愣，随即道：“必须先洗茶杯后放茶叶，洗茶杯放茶叶的同时也没法烧水，至于泡茶，更得等水开之后了。”

句号明白了冒号的用意：“这就是说，单凭并发式编程并不能保证提高程序性能，还必须在程序设计上下功夫。”

问号继续深究：“即便如此，如果硬件不支持，并发式编程也未必能提高效率啊。比如在一台单处理器的主机上，多个线程只能是模拟的、逻辑上的并行，而非真正物理上的并行。”

“这话有一定道理。”冒号有限度地表示赞同，“但设计者应该未雨绸缪，总不能等到有了多处理器才想到并发式编程吧？再者，没有多处理器，是不是可以利用多台单处理器的主机同时运算呢？退一步讲，即使在一台单处理器的情况下，并发式编程有时也是必不可少的。它能保证不同用户、不同程序之间的公平竞争，这对多用户、多任务的系统而言尤为重要。此外，采用并发式编程同样可能提高性能。最典型的一个例子：当一个线程因为等待某种资源而被堵塞时，可以切换到其他线程而不至让CPU闲置。更重要的一点是，难道除了缩短程序运行时间外，并发式编程就没有别的好处吗？譬如打开一个网页，你是希望浏览器边下载边显示网页呢，还是下载完成后再显示？”

“当然是边下载边显示啦。” 叹号毫不犹豫地说，“如果每个网页都是下载完成后再显示，那还不把人给憋坏了！”

逗号加了一句：“浏览器加载文字和加载图像也应分开在不同的线程，如果用户对文字部分不感兴趣，不等图像显示就可直接关闭网页了。”

“如果网页被提前关闭，那也是假用户之手变相缩短了程序运行时间。”冒号接过话来，“还有一个常见的例子，包括浏览器在内的许多应用软件在运行中都会显示一个进程条。该进程条的更新需要一个单独的线程，从效率上看它起的作用是负面的，但大大提高了用户体验，是软件人性化的表现。再举一例，媒体播放器一般都会提供暂停、快进、倒退、快放、慢放等按钮，如果不采用多线程，它们将形同虚设。此处并发式编程的作用在于提高了软件的响应能力，也改善了用户体验——有谁愿意驾驶一辆启动后不能刹车、不能倒车、不能变速、油尽方停的汽车呢？”

“岂止是不愿意，简直是恐怖！”叹号加重了语气。

“对于操作系统、各种实时系统和诸如数据库、网络服务器等基于服务的系统来说，在响应用户请求的时间上和资源的合理分配上有着极高的要求，并发式编程更是不可或缺。”句号接着补充。

问号紧接着又问：“并发式编程还有其他用处吗？”

冒号应道：“不同编程范式采用不同的视角和方法来设计和开发软件。并发式编程以进程为导向（Process-Oriented）、以任务为中心将系统模块化。我们都知道，模块化在编程中是个好东西。”

引号心存疑惑：“过程式中引入了函数模块，对象式中引入了对象模块，但并发式似乎没有在语法上引入新型模块，比如C和Java中的线程其实不过是函数或方法的包装而已。”

“我猜你的意思是：在定义一个线程之前，其主函数已经模块化了，不能把功劳记在并发式编程上，对吧？”冒号笑问，“你不能孤立静止地看待每个模块，还要考虑到模块之间的相互关联和作用。相比串行式，并发式在模块之间引入了新的通讯和控制方式。也就是说，原先的一些模块的定义和划分一定是建立在线程机制的基础上的。如果失去线程的支持，它们的合理性自然会打上问号，说不定整体设计都会受到牵连。这也体现了编程范式的渗透性和全局影响力。”

教室上空弥漫的疑云一消而散。

冒号进一步指出：“除了用户主观上的需求和硬件客观上的可能外，并发式显得格外重要的另一深层原因是：许多程序是现实世界的模拟，而我们生活的世界不折不扣是并发式的。从某种意义上看，并发式的模拟比对象式的模拟更贴近世界。”

引号再次提问：“并发式编程在设计上有什么要求？”

“并发式编程以资源共享与竞争为主线——又是对当今世界形势的一个逼真模拟。这意味着程序设计将围绕进程的划分与调度、进程之间的通讯与同步^[2]等等来展开。合理的并发式设计需要诸多方面的权衡考量。”冒号说着，放出一段幻灯片——

叹号蹙眉：“并发式编程好是好，就是太复杂。”

“天下没有免费的午餐。有所得，必有所失。” 冒号淡淡地说，“并发式编程当然不容易，但也并非难以掌握。最重要的是，作为一个程序员，你不得不面对它。即使你不直接用并发式编程，你依赖的代码和依赖你的代码也可能用到；即使现在没有用并发式，将来也可能用到。如果采取避而不理的鸵鸟政策，早晚会被人点中你的死穴。虽然目前不会对并发式编程作更深入的探讨，但希望能引起你们足够的重视。”

句号谈及他的感受：“相比OOP在语言上得到的支持，并发式的支持力度好像很不够。”

冒号点头称是：“这是由并发式的复杂性和成熟度决定的。另外，在究竟是在语言级别上支持并发、还是交由操作系统处理的问题上，仁者见仁，智者见智。Ada、Java和C#等选择前者，在语法上对并发式编程有一定的支持；C和C++等选择后者，除了关键字volatile外，主要靠库函数支持。专门为并发式而设计的语言大多仅限于学术研究而非商业应用，Erlang语言^[3]是少数的例外。顺带提一下，前面提到的声明式语言具有无副作用的特性，尤其适合于并发式编程。”

问号提了一个听似奇怪的问题：“并发式与前面提到的对象式有无共通之处？”

“并发式与对象式虽是互相正交的两种范式，倒真有些相通呢。”冒号回答，“它们均与三大核心范式正交，并且越来越广泛地向它们渗透着；均为传统编程的一种推广——并发式进程的个数为一时即为传统的串行式编程，对象的方法个数为为零即为传统的数据类型；均将整个程序系统分解为若干独立的子系统，不同的是一个以任务为单位，一个以对象为单位；子系统之间均能交流与合作，不同的是一个以竞争为主题，一个以服务为主题。如果将程序系统视作公司，那么并发式系统是产品型公司，每个进程是一名工人，其职责是执行单一任务；对象式系统是服务型公司，每个对象是一名服务员，其职责是提供系列服务。由此可见，一名优秀的程序设计师也应该是一名优秀的管理者。”

句号提出：“迄今为止我们谈到了五种范式，能否对它们简单概括一下？”

“你提问的时机把握得不错嘛。”冒号开始如数家珍，“为便于记忆，我们不妨用‘一二三四五’来概括编程范式之最：最传统的一个是命令式；最基本的两个是命令式和声明式；最核心的三个是命令式、函数式和逻辑式；最主要的四个是命令式、函数式、逻辑式和对象式；最重要的五个是命令式、函数式、逻辑式、对象式和并发式。最后，我们来对比一下五大范式。”

少顷，黑板上出现几行排比句——

“说回并发式编程，它要求我们摆脱以往习惯的按部就班的思维方式，对编程提出了更高的挑战。程序世界与现实世界一样，呈百舸争流、千帆竞发之势，不进则退啊！”言讫，冒号宣布，“第二堂课到此为止，欢迎下次光临。”

冒号迅速转移了话题：“下面我们来谈谈与命令式编程相对的声明式编程（declarative programming）。顾名思义，声明式编程由若干规范（specification）的声明组成的，即一系列陈述句：‘已知这，求解那’，强调‘做什么’而非‘怎么做’。声明式编程是人脑思维方式的抽象，即利用数理逻辑或既定规范对已知条件进行推理或运算。”

问号询问：“声明式产生的背景是什么呢？”

“声明式编程发轫于人工智能的研究，主要包括函数式编程（functional programming，简称FP）和逻辑式编程（logic programming，简称LP）。其中，函数式编程将计算描述为数学函数的求值，而逻辑式编程通过提供一系列事实和规则来推导或论证结论。其实支持它们的语言出现得并不比命令式的晚多少——最早的函数式语言Lisp（LISt Processor）已有半个世纪的历史，最早之一的逻辑式语言Prolog（PROgramming in LOGic）也与C同龄。只是由于大多数更多地用于学术研究而非商业应用，颇有些‘养在深闺人未识’啊。”冒号有些惋惜，“起源的不同决定了这两大类范式代表着迥然不同的编程理念和风格：命令式编程是行动导向（Action-Oriented）的，因而算法是显性而目标是隐性的；声明式编程是目标驱动（Goal-Driven）的，因而目标是显性而算法是隐性的。为便于说明，我们分别用三种代表性的语言来实现阶乘（factorial）运算。”

冒号在黑板上打出投影——

    int factorial(int n) 
    {
        int f = 1;
        for (; n > 0; --n) f *= n;
        return f;
    }

    (defun factorial(n)
      (if (= n 0)
        1                               //  若n等于0，则n!等于1
        (* n (factorial(- n 1)))))      //  否则n!等于n* (n-1)

    // 0! 等于1
    factorial(0,1).
    // 若M等于N-1且 M!等于Fm且F等于N*Fm，则N! 等于F
    factorial(N,F) :-   M is N-1, factorial(M,Fm), F is N * Fm. 

冒号提问：“撇开语法细节，大家说说以上三段代码区别在哪里？”

句号沉思片刻，答道：“C明确给出了阶乘的迭代算法，而Lisp仅描述了阶乘的递归定义，Prolog则陈述了两个关于阶乘的断言。”

冒号很满意：“一针见血！第二个问题：你们更习惯哪一种思维方式？”

逗号不加思索：“当然是第一种！”

冒号微笑着说：“这证明你至少是受过一定训练的程序员。大家回想一下，当你们初学编程时，是否习惯这种思维方式？”

叹号沉吟道：“好像不太习惯i = i + 1之类的语句。”

“对！”冒号的一嗓子吓了众人一跳，“我们最早接触的变量是代数方程中的x、y、z等，本质上是抽象化的符号，变量值是该符号在给定约束条件下的允许值。而命令式编程中的变量本质上是抽象化的内存，变量值是该内存的储存内容。通俗地说，前者好比姓名，所指之人是固定的；后者好比住址，所住之人是变化的。此外，等号在代数中是一种约束，而在许多命令式语言中则表示赋值。因此i = i + 1可以在命令式编程中出现，但绝不可能在数学推理中出现^[1]——除非在反证法中。”

叹号又道：“现在回头再看代数，反倒有些不习惯了。”

“这就是思维的定势效应。”冒号感慨道，“声明式编程让我们重回数学思维：函数式编程类似代数中的表达式变换和计算，逻辑式编程则类似数理逻辑推理。其中的变量也如数学中的一样，是抽象符号而非内存地址，因此没有赋值运算，不会产生变量被改写的副作用（side-effect），也不存在内存分配和释放的问题。这既简化了代码，也减少了调试——不妨想一想，有多少bug是由于某个变量被意外改写或内存管理不慎而造成的？”

问号问道：“声明式语言与命令式语言看来是两个世界的产物，它们是否有相通之处？”

冒号答道：“首先，所有高级语言都建立于低级语言之上，最终转化为机器语言，声明式语言也不例外。其次，声明式语言与命令式语言并非泾渭分明，而是互相交叉渗透的。一些‘非纯粹’ 的声明式语言也提供变量赋值和流程控制，而一些命令式语言也在逐渐发展，通过利用其他程序或增加新的语言特征来实现声明式编程。总的说来，在命令式语言中融入声明式的元素应当是一种趋势。尤其是函数式，它的一些特征已经在许多命令式语言中得到了支持。比较而言，声明式编程重目标、轻过程，专注问题的分析和表达而不致陷入算法的迷宫，其代码也更加简洁清晰、易于修改和维护。从这种意义上说，声明式语言天然地就比命令式语言更高级。上节课提到的前三代计算机语言基本上都是命令式的，而后两代基本上都是声明式的，由此可见一斑。”

句号一拍脑袋：“命令式是模拟电脑的，声明式是模拟人脑的，人脑当然比电脑高级啦。”

冒号另有佐证：“早在命令式语言引入函数从而进化为过程式语言时，就已经开始向声明式过渡了。何以见得？比方说调用一个函数的语句：doWhat()，这不正是在声明‘what to do’吗？至于‘how to do’，即函数的具体实现细节，则不劳调用者费心。这种声明式的风格，提高了语言的抽象能力和开发效率，促成了语言的升级。”

逗号仍然有些疑惑：“既然声明式编程有这么多好处，为什么命令式语言不仅占大多数，而且流行程度也不减呢？”

冒号回答：“编程语言的流行程度与其擅长的领域关系密切。声明式语言——尤其是函数式语言和逻辑式语言——擅长基于数理逻辑的应用，如人工智能、符号处理、数据库、编译器等，对基于业务逻辑的、尤其是交互式或事件驱动型的应用就不那么得心应手了。而大多数软件是面向用户的，交互性强、多为事件驱动、业务逻辑千差万别，显然命令式语言在此更有用武之地。”

大家频频颔首。

“值得指出的是，声明式编程并不仅仅局限于函数式和逻辑式。”冒号旋即补充道，“比方说，C#中的attribute、Java中的annotation和XDoclet库等采用的也是具有声明式特征的属性导向式编程（Attribute-Oriented Programming，简称@OP）。再比如，Prograph^[2] 、SISAL^[3]等数据流语言（dataflow language）采用的数据流式编程（Dataflow Programming）与函数式编程有不少共同点，同样属于声明式的范畴。还有一些语言如Oz、CHIP等支持与逻辑式编程相交的约束式编程（Constraint Programming）^[4]。此外，大家熟悉的数据库语言SQL，样式语言XSLT、CSS，标记语言HTML、XML、SVG，规范语言IDL（Interface Description Language）等等都是声明式的。算上它们，声明式语言所占的比例也是非常可观的。此前之所以没有提及，一方面，不少声明式语言采用的范式并没有专门的名称；另一方面，这些语言大多是领域特定语言，并且不少并非图灵完备的，有的连运算都没有。毕竟，目前我们的重点还是放在通用编程语言上。”

问号突然想到了什么，指着投影问：“这里用Lisp实现阶乘的方法不也可以用在C上吗？”

冒号点点头，写下一段代码——

int factorial(int n) 
{
    return n == 0 ? 1 : n * factorial(n - 1);
}

“这是C的递归实现。”冒号娓娓道来，“除了细微的语法差别外，二者的确很相似，这说明用命令式语言也可以讲出声明式的味道。实际上，命令式语言提倡迭代而不鼓励递归，早期的Fortran 甚至都不支持递归。一则迭代比递归更符合命令式的思维模式，因为前者贴近机器语言而后者贴近数学语言；二则除尾递归（tail recursion）^[5]外，一般递归比迭代的开销（overhead）大。相反，声明式语言提倡递归而不支持迭代^[6]。就语法而言，它不允许迭代中的循环变量；就视角而言，迭代着眼微观过程而递归着眼宏观规律。”

叹号轻叹：“原来貌似普通的迭代和递归有那么多道道！”

“任何语言都难脱命令式或声明式的窠臼。事实上，凡是非命令式的编程都可归为声明式编程。因此，命令式、函数式和逻辑式是最核心的三种范式。为清楚起见，我们用一幅图来表示它们之间的关系。”说罢，冒号换了一个幻灯片——

图2-4. 编程范式的简单分类

末了，冒号归纳道：“归根结底，编程是寻求一种机制，将指定的输入转化为指定的输出。三种范式对此提供了截然不同的解决方案：命令式把程序看作一个自动机，输入是初始状态，输出是最终状态，编程就是设计一系列指令，通过自动机执行以完成状态转变；函数式把程序看作一个数学函数，输入是自变量，输出是因变量，编程就是设计一系列函数，通过表达式变换以完成计算；逻辑式把程序看作一个逻辑证明，输入是题设，输出是结论，编程就是设计一系列命题，通过逻辑推理以完成证明。绘成表格如下（如表2-1所示）——”

冒号见众人微显难色，宽慰道：“这部分理论性稍微强了些，对函数式和逻辑式也仅作了描述性说明，并未深入展开。不解之处，大可不必介怀，撒下的种子总有一天会萌动。先休息片刻，不要走开，广告之后更精彩。”