也就是说，我们将上述模型中的“P-D关系”理解为某种数据层的提供方案，进而将服务对底层数据的存取变成一组分布逻辑，并将这些分布规则(rule)通过语言(例如MapReduce等)固化在对数据层的存储界面中——将界面理解为对规则的封装。

如此一来，一种面向底层数据的分布式框架就形成了。类似地，我们也可以规划“P-P关系"。例如我们可以讨论会话服务是否存有较多的业务逻辑、是否依赖实时响应等限制条件，并据此来选择合适的语言或执行环境。一种可能的情况

在这样的模型下，我们讨论的是在不同的层间所采用的领域方案，以及在这些领域交互界面上的可行性、安全性与系统代价。在不同的层间，由于所关注的系统性质不同，因而候选的标准与工具也不同，其数据的格式与存储要求也存有差异，但总体来说，是对PDIO四个方面的综合考虑，例如逻辑(P)的复杂度、数据(D)的量级、IO的频度等。

除开这些在分布、部署、调度等技术细节上的分析与选择，我们要讨论的将是这些层间的规划与层间关系的模型，以及如何通过系统化方法来实现这些层间(也就是领域间)的协作开发。而这些将部分会是本书下一篇所涉及的内容。

【“主要编程范式”及其语言特性关系】

Peter将一个最重要的概念“state”引入进来。而这个state也是Peter对语言进行分类并考察其变化的主要依据。但Peter所使用的state概念以及专用名词“cells”都相当地令人困惑。所以在这个图的补充说明中，Peter对此专门做了解释：“状态是记忆信息的一种能力，更精确地说，是及时存贮值序列的能力。”yipindushu.com

你觉得这个概念像什么?对了，的确，非常像是"变量"。事实上，状态在编程核心概念的“数据-逻辑”抽象中，表明的正是“数据的可变性”。也就是说，数据的可变性表现为状态。更进一步地，当数据被命名时，它称为变量或常量；当数据未被命名时，它成为游离的、无名称的、时序含义的存储单元，即“cells”。这也是Peter使用“cells”这个专用名词的原因：在本图的讨论中，需要从“变量/常量”这样的概念中，剥离掉“未命名或命名的、确定的或非确定的，以及串行的或并发的”这三个方面的性质。

当不考虑一个存储位置上的命名特性时，它就既非变量或常量，也非某个确定的运算对象(例如“对象”等高级的抽象概念),而只是一种更加泛义的“状态”;同时存储这个状态本身的事物，由于没有位置、时序等概念，所以被称为“cells”。

【二】

《程序设计语言：实践之路》这本书解释过命令式语言的本质特性，即用算法改变数据。如果用两个以上的逻辑(例如两行代码)去影响同一个存储位置(cells),使①节选自博客文章“‘主要的编程范式’及其语言特性关系”(2009年10月)。文章对Peter Van Roy的“主要编程范式”一图进行了解读，Peter Van Roy的原文参见：www.info.ucL.ac.be/~pvr/paradigms.html它的状态改变，并最终在该cell产生运算结果，那么它就是一种命令式语言。

再简单一点(但没有上面这样严谨)地说：在程序中不断地重写变量，变量值即是程序的最终结果。所以在本图中，Peter把这个衍生关系表达为：命令式=纯数据+算法+状态维护。

无论是在串行还是在并发的编程中，命令式编程范式对“状态”的理解都是：共享状态。在串行(例如单线程)的编程中，状态是时序相关的。因为不断地重写“状态(数据/cells/变量)”,所以前一行和后一行所面对都是同一个共享状态的不同的值/副本。在这个过程中，正因为状态与时序相关，所以前一分钟与后一分钟的状态是不确定的。但是在同一时刻，这个状态是确定的。

与上面相类似地，在多线程中，同一时刻，不同线程也将面临这个值/副本。但正是因为多线程(并发)中，线程A与线程B对于同一个cell,在同一时刻所得到的状态也是不确定的——我们可以假想为多核CPU在对同一个内存地址读写(于是就出现了我们所谓的“同步”问题，进而也就出现了“锁”的问题)。所以在这个分支中，当加入“线程”概念之后，新的编程范式全都变成了“可观测的非确定性”为“yes”的情况。

我们显然可以发现，问题出在由于多个线程都在“写cell”。在命令式的解决方案中，采用的方法是“加锁”;持锁存取的最经济的方法之一是“多读单写”,即保证同时只有一个线程能“写cell”。