另外，数据库中的“原子事务”也值得一看，思想很类似，只是粒度更粗——从来没有破坏什么，也不用竞争条件，新的版本以一种非破坏性的方式创建出来。其中有了版本的历史。

　　“时间是个好主意”，直播，这是关键的一点——我们想要它，想用安全、合理的方式处理它——而这些方式中绝大部分（如果不是全部的话）都可以是处于稳定世界线状态序列之间的纯函数式事务。

　　“刚刚计算来的稳定状态”非常有用。它再也不会改变——因此它代表了系统模拟中的一个“版本”——且可以在产生下一个稳定状态的函数式转换中充当源数值。它还可以充当数据源，为那一刻的世界创建视觉效果。历史信息则可用于调试、撤消、回滚等需要。

　　在这种模型中，“稳定状态之间时间并不存在”：“时钟”只在新状态完成时走表。就程序而言，CPU本身并不充当时钟。对于具有内在、干净时间模型的确定性关系，这种思想带来一种非常简易的处理方式。

　　出于很多理由（但没有一个好的）这种维持安全的方法在上世纪60年代输给了在命令式编程中使用竞争条件，然后再通过可怕的、可能导致死锁的信号量来保护它们的做法。

　　某些时候，任何了解Lisp且对对象间的消息传递感兴趣的人都必然“运用”并注意到一种对象（一个lambda的“东西”，可以是一个闭包）可以捆绑到一组参数上（看起来有点像消息）。如果一个人知道Lisp 1.5是如何基于新式的延迟绑定参数求值来实现的，理解还会更深入。这里指的是FEXPR，而不是EXPR——未求值的表达式可作为参数传递，之后再求值。这使得不太优雅的“特殊形式”四处充斥，它们本来可以写成漂亮的惰式函数。

　　使用前述的时态建模，可以松掉“求值－应用”的耦合，通过安全的消息传递来获得时间层之间的函数式关系。于是，由于我一直喜欢从系统模拟的视角看待计算，我便把“对象”和“函数”看作两种互补的思想，它们并不冲突。

　　术语一旦成为宗教或更加严格的选择与风格，便会失去它们的意义。这里说的自然是“面向对象”和“函数式编程”这两个术语。我不会将“函数式编程”的一般概念跟任何特定语言等同起来。我坚持认为“函数思想”是一种可靠的映射。类似的，我也不会把“面向对象”的一般概念同任何特定语言等同起来。如今这两个术语被“殖民”了，意思也变了。

　　还有一个大问题是“对象”和“抽象数据类型”的混淆，以及对“数据”和“赋值语句”的固执。如果真正强化了封装，对象就可以根据需要处理设计参数（包括保存历史信息）。

　　分布式环境中的对象

　　有朋友问我现在如何理解分布式环境中的对象和系统模拟的，是否依然认为有可能构造一种系统，它既有互联网那样可以有机增长的规模，又有类似于虚拟时间的良好的、可预测的语义？

　　好问题。这里面有好几组问题及其权衡关系。二十世纪70年代Dave Reed（编者注：美国计算机科学家，UDP协议设计者）最初思考的是面向整个互联网的操作系统应具有什么样子。在他提出的许多有趣想法中，其中之一是通过由虚拟时间（pseudo-time）组织起来的分布式克隆计算来处理长延时和海量潜在用户的问题，然后慢速的互联网仅用于输入和偏差同步。这就是我们本世纪00年代早期在Croquet中实现的东西，那时互联网上一次典型的、还算不错的ping来回大约80到100毫秒。这已经好到可以无需任何服务器而创建《魔兽世界》这样的大规模并行游戏（甚至飞行仿真游戏）了，只要有玩家正在用着的那些机器就够了（分布式）。后来的版本做得更多更全面。

　　插一句，去掉实时图形和交互的Croquet便自动提供了一种分布式的面向对象数据库。虚拟时间是背后的大理念，保护着数据库中的分布式原子事务。

　　而且多年来人们一直在讨论。它能否实现？需要在哪些领域做多少工作？等等。

　　我们在Parc做过的与对象有关的工作就是ARPA/Parc社区中发生的网络思维的一部分，它最终产生了思考更高层网络实体的倾向。“网络层实体”的一个相当不错的、过渡性的实现是Gerry Popek在Parc花了一年时间思考“网终系统应有的样子”之后，和他在UCLA的团队一起完成的LOCUS系统。那是建立在异构机器类型之上的一种迁移式的负载平衡思想，与虚拟时间概念形成高度的互补。