用写文章的方式写程序--“三维度”逻辑编程语言的设计（1）
1、 前言
前几个月，看到园子里面一篇介绍逻辑编程语言的文章《逻辑式编程语言极简实现（使用C#）》，觉得作者写得很有趣，用讲故事的方式来讲述了一个极简逻辑编程语言的设计，于是我也萌生了写一篇有关逻辑编程语言的文章。说实话，我很早就接触了逻辑编程的概念，最开始学编程的时候就想着有朝一日搞搞AI，当年在AI界机器学习还仅仅是一个概念，最火的莫过于被称呼为“第五代编程语言”的逻辑程序语言--Prolog。可惜工作中始终没有机会实战这种编程语言，对Prolog也只是一知半解。直到2013年，我提出《业务分析三维度（场景+角色+时间）理论》后，思考如何将这个理论在编程上进行落地，才发现逻辑编程的概念非常符合这个三维度理论，而且这个理论跟DCI架构殊途同归，思想上是很类似的，具体内容可以参考我最近写的新书《SOD框架“企业级”应用数据架构实战》里面的【6.3.3 业务分析三维度理论 】，如下图。
2、编程的症结
回到本文标题，大家可能有疑问，写文章和写程序是一回事吗？怎么能用写文章的方式来写程序！
的确，写文章跟写程序有很大的不同，然而这种不同是基于我们天天使用的面向对象编程语言（OOPL）上的一种感受，OOPL其实跟面向过程编程都是属于“命令式”编程，也就是程序员必须告诉计算机每一步要如何做，细化到做这一步是用分支语句还是用循环语句的语言细节，这样解决问题就需要大量的编码，有时候代码量太大而不得不依靠各种架构或者设计模式来帮助人们理解复杂的程序行为，然而这些架构或设计模式却并不是软件工程师之外的人非常容易理解的事物，尽管工程师声称他们有详细的文档，也有“统一的模型语言”--UML，但事实证明UML并不成功。
我们说话的方式可以分为命令式、陈述式是虚拟式（参见原文）。命令式是说话人施加给他人的意志；陈述式是如实的反映不以人的意志为转移的客观事实；虚拟式表达人的主观意志或者判断。例如，一篇文章中如何描述有关“国家的印象”，不同的语式分别如下：
- 命令式：
- “给我讲讲你们对这个国家的印象”。
- 陈述式：
- “他给我讲了他们对这个国家的印象”。
- 虚拟式：
- “我希望你给我们讲一下你们对这个国家的印象”。
在实际的对话中，命令式交谈有点像领导让下级汇报工作，领导会不断问下级各种工作细节；陈述式交谈有点像一个朋友倾听你讲的一个故事，你只管讲，我听着就行；虚拟式是你希望了解某个事情但又不能以命令的口吻，你们之间是一种平等的关系，所以只能用这种委婉的语气，实际谈话过程与命令式交谈是类似的，只不过语气不同。所以，我们重点只需要区分命令式和陈述式两种说话风格，命令式关注你怎么做（要不怎么反映你的意志），陈述式关注你做了什么，或者你将要做什么，也就是更加关注做事情的结果。所以，你写一篇文章，或者写一本书，为了激起读者的阅读欲望，就应该更加关注你写的文章“要写什么“，“写了什么”，“主人公做了什么”，虽然你也会用很多篇幅去详细描述这个问题具体是如何做的，但一定要用特别的段落、醒目的标题去表达前者。这恐怕是现在程序员觉得写程序跟写文章最大的区别之处：无法直接通过程序源码表达这个程序要做什么或做了什么，源码也没有什么“程序标题”，那是“需求说明文档”干的事情。
上面这个问题，是我们在编程中遇到的一个根本问题。我们深陷于编程的代码细节，而不能直接告诉计算机我们想要什么。它们要求你去描述如何做，而不是做什么。在你能叫得出名字的任何一种语言里，程序是一个对能计算出你想要的东西的处理过程的描述，而不是一个对你想要的东西的描述。作为程序员，我们用代码解决问题。我们应该能够用代码来表达我们想要的结果，而不是想要达到这种结果需要的过程。这才是症结所在。这段话来自于《也谈编程改革》，我们是应该面向过程，还是面向结果的编程。而提出这个问题的作者Jon Beltran是一个西班牙程序员，作家，企业家，他说：“I want to fix programming - 编程改革”。
3、编程范式
这个问题是一个编程“范式”问题。与说话的方式或者写文章的方式对应，我们的编程范式也可以分为“命令式编程”、“申明式编程”、“函数式编程”、“逻辑式编程”等。
- 命令式编程--主要思想是关注计算机执行的步骤，即一步一步告诉计算机先做什么再做什么。
- 声明式编程--是以数据结构的形式来表达程序执行的逻辑。它的主要思想是告诉计算机应该做什么，但不指定具体要怎么做。SQL 语句就是最明显的一种声明式编程的例子，HTML，CSS也是这样的例子。
- 函数式编程--和声明式编程是有所关联的，因为他们思想是一致的：即只关注做什么而不是怎么做。但函数式编程不仅仅局限于声明式编程。
- 逻辑式编程--设定答案须符合的规则来解决问题，而非设定步骤来解决问题，过程是事实+规则=结果。
有关内容请参见《编程范式：命令式编程(Imperative)、声明式编程(Declarative)和函数式编程(Functional)》。个人觉得，LINQ有申明式编程的特点，VS编译器将LINQ编译成一些列对象的函数调用，背后又是函数式编程的风格。SOD框架的ORM查询语言--OQL也采用了函数式编程的风格，通过一些列的对象函数链式调用实现，具体可以参见《ORM查询语言（OQL）简介--概念篇》一文。
4、三维度理论
我在 2013 年提出了《业务分析三维度（场景+角色+时间）理论》，尝试从场景维度、 角色维度和时间维度来分析问题，从而提出了一套分析业务的方法论，以下简称“三维度理 论”。其实这个方法就是记叙文三要素（环境，人物，主要内容）的进一步抽象总结。我发现，记叙文三要素的环境类似于场景概念，人物类似于角色概念，事件的主要内容就是角色在场景中交互的各种数据。这个过程跟DCI架构的理念很相似的，如果从这个角度来看，那么 DCI 架构就是我们写记叙文的模式了。既然DCI架构是一种程序架构，那么反过来说，我们用写记叙文的方式来写程序也是完全可能的。 在记叙文三要素的基础上，有记叙文六要素的概念，指的是时间，地点，人物，事情的 起因，经过，结果。我对此进一步抽象总结，提出了“三维度理论”，场景就是六要素中 的地点，角色就是人物，时间对应六要素的时间，记叙文中事件的起因、经过和结果，就是 场景、角色在时间维度上面的投影。如下图所示。
我们用这三个维度来分析业务系统，这种业务分析视角，更符合人的一般思维模式，让 人容易理解，因为人本身就是在不断地扮演各种角色做事情的，因此，业务专家也很喜欢这 样的工作方式，做业务分析，然后跟受众讲解业务细节问题，这个“工具”，就像是业务专 家手里的三维“显微镜”一样。场景、角色、时间，这 3 个维度，就抽象、立体的把业务描 述清楚了！这个道理可能太浅显了，所以很少看到有人系统的来论证它，我把这个东西总结 为“业务分析三维度（场景+角色+时间）理论”，后面简称为“三维度理论”。
人们总是局限于事情的表象，制造出很多复杂的事情而又无法掌控这些事情。如果要化 繁为简，就需要深入事务背后的机制；要找到这种机制，就需要进行较高层次的抽象，通俗 的说法就是形而上学， 由点到面，由一般到特殊这些思维方法。这个过程抽象出来的模型， 可以用场景，角色，时间三个维度去观察，分析；甚至，直接用这三个维度去为这个抽象建模。 有关三维度理论的详细内容，请参考笔者的博客文章《业务分析三维度（场景+角色+时 间）之程序员坐禅论道》。
5，三维度编程模式
上面说到三维度理论是一个用来进行业务分析的理论，如果业务分析的结果能直接对应一套抽象模型，而这个模型又能用程序代码表达，那就意味着我们完全可以用写文章的方式来写程序，即这样一种程序：描述业务中的对象、描述业务场景、描述参与场景的对象角色、描述角色对象或者场景在时间中的相互作用，回答系统中有关的问题，角色参与场景活动的开始、经过和结果，回答角色相互之间的关系。。。用这种方式来写程序，跟写一篇记叙文就很相似了，写记叙文可是每个小学毕业的人都会的技能，这样差不多人人都可以写程序了。
总结一下，上面理想中的写程序的过程其实就是在定义规则、描述事实与提出问题，这种方式正是"逻辑编程"的范式。为了实现这个目标，我将要“发明”一套“三维度”逻辑编程语言，不管算不算发明，先打个引号再说。今天的话题设计了太多的编程理论概念，需要读者先消化一下这些概念，在下一篇，我将以一个“游戏人生”的故事，来详细介绍这门“编程语言”的设计，先放图，敬请期待。
注：此图内容来自于笔者今年出版的新书《SOD框架“企业级”应用数据架构实战》中的【6.3.3 业务分析三维度理论 】内容，已经购书的朋友可以抢先看到这部分内容，还没有购书的朋友可以点击前面书名链接了解。
