程序原本（七）：像大师们一样思考

编者按：本文节选自周爱民著《程序原本》一书中的部分章节。

算盘用了几千年，谁问过“算盘为什么能算东西”？算珠、进位、栏，这些东西是不是基本的存储结构？用算盘的“我们”，是不是计算单元？珠算表是不是运算规则？那些珠子表达出来的“0~9”的排列，是不是输入输出的界面？

“我们+算盘”就是一个完整的计算系统。这样的计算系统的完整性，图灵用了一个假想加以说明。图灵不过是用一个假想描述了一个事实，而这个事实“看起来”能被机器实现。于是，我们的计算机时代就开始了。

图灵是否证明过“大笨象吃意大利面条为什么是一个完备的计算机系统”呢？不，最初等的问题，往往最难于证明。往往，他的证明过程，或应用过程，只是触发了一个想象。

对计算机根本问题的思考，许多会追溯到哲学思想层面。IOPD 和 PDIO 的问题、“算法 + 数据结构 = 程序”的问题等，就属于这一类。还有一些会追溯到人类行为学、语言学等层面，例如语言、语法、语义，以及像有没有语用这样的问题。大多数时候，真正推动计算机发展的，不是对具体问题的推理求解，而是对问题本身的抽象。在 Dijkstra 的叙述中，抽象更像是终极武器。按照 Brooks 的观点：

数据的表现形式（数据结构，抽象的结果之一）是编程的根本。

而按照 Dijkstra 的引述：

引用未解释过的名词阐述公理或定理和作用于未解析过的操作数的（命了名的）运算两者之间有着某种平行的相似性。

无论如何，我们“做一个计算机”，原始的目的不外两个：其一是“让它计算数学”，其二是“让它像人一样思考”。请注意，我的确是说“计算数学（即算数）”。数学是人类的理论学科，“怎么算”以及算的内容等，都是由我们自己设定的。而计算机的能力，只是计算“数学”这个它未知的对象而已。事实上，我们现在讲的“命令式”、“函数式”或“说明式”，只是我们为计算机设定的“最基础的运算方式”。在这个“运算系统”中，“数学”并不是最初设定的。

命令式如何计算，函数式如何计算……诸如此类的问题了解清楚了，我们对这类语言也就了解了。至于什么高阶函数（higher-order function）、克里化（Currying）、延续（Continuation）或发生-迭代器（Generator-Iterator）之类，那已经是具体语言的表象，而非“这一类语言”的本质。举例来说，JavaScript 1.5 还没有实现过“生成器对象”（Generator Object），但并没有人否认它是函数式语言。反过来说，“Generator Object”原本就不是函数式语言的必备要素。

LISP 表达了函数式语言的全部“必备要素”，然而 LISP 七个原子运算也只是针对 LIST 这个结构抽象来说的。对于一个“（顺序的）表”，这七个原子运算是必需的，而对于另一个“（关系的）表”就未必如此了。所以某些原子运算，也不必放在函数式的必备要素中。像 LUA 这样的函数式语言实现方法的出现，也证明了这一点。¹

¹ LISP 的基础数据结构是索引数组（表，LIST），而 LUA 的基础数据结构是关联数组（表，MAP）。

那么函数式还剩什么？

要真正理解函数式的秘密，是要一个语言一个语言地学习下去吗？是要一种运算法一种运算法地学习下去吗？我们听完人家说“延续”，于是就开始了解延续，而没有去追问延续为什么出现在函数式里面，或它是不是函数式的必备要素，又或是函数式运算系统的自身的“问题”。我们正是迷失于种种语言和概念的表象，而最终没能像大师一样去思考“计算机不过是大笨象吃意大利面条”这样的抽象层面的问题。

我们要改变的是思想，我们要增强的是能力。大多数人只是增强能力，而不改变思想。这就是我们大多数人不是大师的原因。

图书简介：https://www.ituring.com.cn/book/2429

相关阅读

程序原本（一）：应用开发基础

程序原本（二）：应用开发技术

程序原本（三）：开发视角下的工程问题

程序原本（四）：系统的基础部件

程序原本（五）：海量数据运算中公开的秘术

程序原本（六）：继承与混合，略谈系 统的构建方式