冒号迅速转移了话题：“下面我们来谈谈与命令式编程相对的声明式编程（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所示）——”

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

第二课伊始，冒号开门见山：“首先介绍一下最原始也是我们最熟悉的编程范式：命令式编程（imperative programming）。用命令式编写的程序由命令序列组成，即一系列祈使句：‘先做这，再做那’，强调‘怎么做’。更学术点说，命令式编程是电脑——准确地讲，是冯•诺伊曼机（von Neumann machine）——运行机制的抽象，即依序从内存中获取指令和数据然后去执行。从范式的角度看，其世界观是：程序是由若干行动指令组成的有序列表；其方法论是：用变量来储存数据，用语句来执行指令。”

逗号小声嘟囔着：“我们用的编程语言不都是命令式的吗？”

“应该说绝大多数语言是命令式的，但非命令式的语言也是存在的。关于后者，我们稍后再议。” 冒号纠正道，“这也在情理之中。语言的演化是渐进的，大多数语言追根溯源是汇编语言的升级，而作为与机器语言一一对应的汇编语言自然是命令式的，因而这种范式最为传统和普及。”

不料问号竟穷追不舍：“为什么机器语言就一定得是命令式呢？”

“我很欣赏你这种打破砂锅问到底的精神，不过你可以问到底，我却不敢保证能答到底哦。”冒号有些逗趣地说。

问号略带腼腆地笑了。

“从理论上而言，完全可以有非命令式的机器语言存在，前提是计算机采用了特殊的硬件实现，比如非冯•诺伊曼结构的数据流机（dataflow machine）和归约机（reduction machine）。但这类计算机并未流行于市，相应的机器语言自然罕见了^[1]。”冒号还是给出了理由。

引号问：“命令式编程与人们常说的过程式编程是一回事吗？”

“严格说来，过程式编程（procedural programming）是指引入了过程（procedure）、函数（function）或子程序（subroutine/subprogram）的命令式编程。但由于现代的命令式语言均具备此特征，故二者往往不加区分。”冒号回应道。

句号认为：“由于常用的语言基本上都是命令式的，其思想也与计算机的运行机制相符，一切对我们来说，似乎都是自然而然的事。”

“单纯的命令式思想的确很朴素，毋庸赘述。” 冒号承认，“但有必要提一下结构化编程（structured programming或简称SP），它是在过程式编程的基础上发展起来的。其本质是一种编程原则，提倡代码应具有清晰的逻辑结构，以保证程序易于读写、测试、维护和优化。可别小瞧它，在上世纪六十年代首次爆发的软件危机中，它曾起着中流砥柱的作用，就像后来的OOP一样。Pascal正是遵循结构化编程原则而设计的一种教学语言，当年也是风光无限。为直观起见，我们用图来表现程序的结构化特征——”

图2-1. 非严格的结构化程序框图

“这是一个流程图（flowchart），或称程序框图，它描述了一个简单程序：用户从标准输入中键入算术表达式，程序打印出结果，如此循环往复，直到用户输入字符‘q’为止。”冒号解释道，“若以纯粹的结构化编程的标准来衡量，该流程图并未达标。”

叹号有些惊讶：“这个图不是再清晰不过了吗？”

“根据结构化定理（structured program theorem）^[2]，任何程序都可用顺序（concatenation）、选择（selection）和循环（repetition）等三种基本控制结构来表示。”冒号画了几幅图——

图2-2. 三种基本控制结构：顺序、选择和循环

冒号指点着黑板：“结构化编程就是在三种基本结构的基础上进行嵌套组合。如果将每个基本结构看作基本电器元件，编程就是将这些元件组装成复杂的电路。请注意，所有基本元件都满足‘单入口、单出口’（single entry, single exit，简称SESE）的原则，这使得电路井井有条，不会串线缠绕。”

引号已经看出：“上面的流程图无法用基本结构来组合，所以不是标准的结构化程序。”

冒号提出要求：“你能改造一下吗？”

引号走上讲台，在前图的基础上作了些许调整——

图2-3. 严格的结构化程序框图

“嗯，不错。这下流程图可以拆解为基本结构了。”冒号表示认可，“二者的区别在于前者利用了break语句，在循环途中退出，后者通过引入quit标志（flag）保证了循环的完整性。”

逗号的脸上写下一个大大的问号：“难道连break语句都不能用吗？”

“break语句只是在循环体内部的跳转，合理地使用它能简化代码，不致影响整体结构，大可不必拘泥于教条。但goto语句可以跳到程序过程中的任一点，造成静态程序（static program）与动态进程（dynamic process）之间的差异，影响程序可读性，是要竭力避免的^[3]。”冒号如是说道，“结构化编程的思想包括两方面。在微观上，主张循规守矩，采用顺序、选择和循环三种逻辑结构，摒弃或限制goto语句^[4]，以避免杂乱无章的代码。在宏观上，主张分而治之（divide and conquer），采用‘自顶向下（top-down）’ ^[5] 的设计，通过模块化将一个较为复杂的系统分解为若干相对简单的子系统，每个子系统可以独立地进一步分解，直到容易编码实现为止。这两方面是互为因果、互为保障的——由基本结构拼装而成的系统一定是模块清晰、层次分明的；反之，系统逐步分解到最后，一定会演化成基本结构。”

叹号产生一个想法：“能从程序的流程图上看出结构化编程与非结构化编程之间的区别吗？”

“一个按结构化编程思想设计的流程图，每个模块大小适中、模块之间关系简明、模块内部线路清晰，单从视觉上就会给人一种美感。相反，如果采用非结构化的设计，流程图往往结构如杂草般松散紊乱、脉络如迷宫般错综复杂、箭头如线头般剪不断理还乱，情节严重的会导致读者头晕目眩乃至抓狂吐血。”冒号极尽夸张之能事。

众人掩口失声。