NOP --- 下一代软件生产范式

作者： Canonical

什么是NOP？NOP是Nop is nOt Programming 以及 Nop Oriented Programming的递归缩写，它代表了一种以可逆计算理论为指导，采用非编程的方式，通过人机智能协作，批量化进行软件定制生产的下一代软件生产范式。NOP的目标是在提升10倍生产率的同时提升10倍软件质量，在软件开发、测试、文档、部署、维护的全生命周期内降低10倍人力需求，为智能时代实现软件全面普及化奠定基础。

一. 智能时代的软件需求

大数据和人工智能的发展带来了第四次工业革命（工业4.0）的曙光，工业4.0所描绘的图景应该是万物互联、自主协同、实时感知、在线演化，而这一切智能都需总酚要由软件来赋予，软件就是智能时代的电力和能源。2017年中国国际软件博览会全球软件产业发展高峰论坛的主题就是“软件定义未来”。但是软件定义未来，谁来定义软件？

反观软件生产自身，我们不得不正视一个令人尴尬的事实：软件研发一点都不智能，它是严重依赖大量程序员手工劳动的一种效率极其低下的过程。即使是一名高级工程师，一整年能输出的有效代码量也很难超过2万行，软件儿童奶粉排名研发的成本让世界顶级奢侈品都相形见绌。

软件的经济学与物质生产具有本质不同：构造成本很高，但是复制成本近乎为0，在完全不修改的情况下没有折旧一说，增加一个使用者的边际成本极低。如果投入大量人力物力维护唯一的软件产品，让所有人都使用同样的功能集，那么软件的生产成本可以被摊薄，创造出远超物质生产的价值产出，这是互联网经济的内在技术逻辑。

但是随着互联网进入下半场，to B市场的逻辑开始挑战to C市场的成功经验。互联网巨头们都在强调千人千面，展现给每位用户的都是针对该用户通过AI算法”精心优化“的界面。但是千人千面，却没有一面是用户可以随意指定的一面，没有一面是用户真正能够掌控的一面。

企业客户不是沉默的看客，而是需要为生存拼尽全力的主动猎食者。企业软件需要实现客户需求，而客户需求就是客户为适应自身商业环境所需要特化的逻辑。现在的AI可以识别、可以预测，但却不能产生新的逻辑。一个有趣的现象是，大数据和人工智能公司在真正项目实施时投入大量人工，所做的却都是普通开发工作（这里编个接口，那里做个界面），与大数据和人工智能没有半点关系。

企业软件面临的现实是，任何一个功能点的潜在用户数都是极其有限的，而所有投入都要量入而出。大部分企业用不起定制软件，用得起的也多半养不起。就算软件开发商倒闭了，相关硬件绝版了，企业软件的用户一般也是宁肯操作系统降级、软硬件型号绑死，也坚决不升级。智能要进入企业市场成为一门挣钱的生意，难度要远超消费者市场。即使是SalesForce那样可扩展的云端SAAS应用，它的二次开发成本以及支持用户自定义逻辑的深度，也是远远不足以支撑工业4.0的目标蓝图的。

二. 智能时代的软件生产

如果我们做一点逆向思维，假设智能时代已经实现，想象一下此时的软件生产场景。

首先，人类社会传统的专业分工将会发生根本性改变，人与人之间靠着专业化、熟练度形成的隔离将被打破。未来的分工首先是人与机器之间的分工，所有依赖经验性的、可机械化的工作将由机器承担，人所负责的是创造性、探索性的工作。限制我们的，是每个人的想象力和他可以输出的逻辑要求，而不是这种逻辑的具体实现方式。

第二，劳动生产率的大幅提升使得小团队即可掌控复杂产品，传统软件工程为了控制人这一最复杂、最不确定的生产要素所提出的按功能细分纵向划分成多个团队的组织原则将变得不再有意义。

第三，机器与机器之间存在大量的直接交互，不再需要人作为中介参与。软件接口的设计原则向机器容易理解的方向倾斜，而不单纯强调适合人类的阅读理解。理想的软件接口应该具有多种展现形式，方便人和机器选择各自适合的方式进行处理，便于双方协作。

目前主流的软件开发技术所考虑的受众都只有人，认为只有人是软件生产的参与者和理解者。大部分程序语言以及领域特定语言（DSL）的设计强调类似自然语言（其实只是类似英语语法），并不利于机器解析和扩展。

互联网开发因为团队庞大，很多人推崇polyglot多语言编程，方便不同背景的程序员在实现特定业务功能时选择采用最适合的编程语言和开发工具，但是如果原本需要50人协作开发的产品最终交由一个5人团队完成，多语言开发就不可能成为一个合适的选择。

其实仔细思考一下人在软件开发中所承担的工作内容，就可以发现为什么我们需要如此多的人工。大部分程序工作并不是去建立新的抽象（编写复杂的组件、算法、框架），而是在做某种逻辑等价的形式转换。比如，将用户的查询请求转换成数据库可以理解的SQL语言，将流程流转逻辑适配到工作流引擎带来不便所要求的接口格式等。

同样的软件功能，会ios开发的一般并不会android开发，反之亦然。在某种意义上，很多程序员的工作其实类似于古时候代人写信的秀才，他们负责将人类普遍理解的逻辑翻译成计算机所理解的API调用，而且每个人掌握了回字的不同写法，写出来的东西也五花八门。

第一次工业革命发明了蒸汽机，将化石能源转化为热能再转化为机械能，推动机器代替了手工劳动。而第二次工业革命发明了电，经由电这个媒介，能量可以在各类形态之间发生自由转化，促使生产方式发生了进一步变革。智能时代的驱动力是信息，但目前信息却经常固化在特定的表达形式中, 只有受过专门训练的程序员才能理解软件中的信息并转化信息的表达形式。

近20年来软件世界的繁荣离不开开源软件的贡献，借助于人这一最高级别的智能转化媒介不断的对已有信息进行理解和改写，信息终于可以在各个公司之间、各种技术应用场景之间、各种表达形态之间发生流动了。使用单一公司提供的产品会发生供应商锁定问题，如果供应商倒闭，不仅仅供应商本身的软件功能无法使用，更重要的是我们基于供应商的软件所表达的业务逻辑也被锁定为固定形态而无法继续向前发展了。

使用开源软件避免了供应商锁定，但是仍然无法避免技术形态锁定。我们花费了巨额开发成本，基于某种技术开发的应用随着技术升级换代将会迅速过时，很多新兴技术自身的生存周期只有1-3年，而我们的业务逻辑却需要长久的存在下去，这就造成了循环往复的形态转化需求。

面向未来的软件生产范式应该是支持信息自由转化，支持人与机器更好的分工协作，支持用户特定的逻辑很自然的融入系统、驱动系统运行的。

三. NOP --- 让信息无界流动

NOP是以可逆计算理论为指导，综合利用模型驱动、差量编程、大数据和人工智能等技术所实现的一种新型软件生产范式，它致力于满足未来智能社会的软件生产需求。

目前企业软件的开发模式一般采用我们所谓编程（Programming）的方式：

使用适用于所有业务领域的通用开发语言（例如Java/C#）和开发框架（如SpringBoot/dotNet Core）开发团队成员包括项目经理、需求人员、架构师、UI设计、程序员、测试和文档编写人员等开发过程一般由项目经理组织架构师、UI设计和需求人员进行沟通、讨论，确定界面展现形式和业务功能点对应的业务逻辑规则等。设计人员和需求人员讨论完毕后，编写出需求规格说明书、软件功能设计说明书等。开发人员拿到需求文档和设计文档后，理解文档编写人员的意图，使用熟悉的开发语言和开发框架，将其翻译为具体的技术实现代码。开发人员开发完毕之后，由测试人员负责进行初步的需求验证和正确性检查等，待产品功能基本完备后提交需求人员进行试用和验收。文档人员根据交付软件功能编写使用手册等。开发过程中发现实现出现偏差或怀孕多久可以用试纸测出来者需求发生变化，则由相关人员提交对应测试文档、需求变更文档、设计修改文档等，重新交由上游人员按照流程处理。

以上生产过程在生产每一个功能点时都涉及到多处信息传递，而且都需要人的参与，人将信息编写为文档，再由另外的人理解文档，反向抽取信息再加工成机器可理解的信息（代码）。整个生产是一个相当复杂的过程，从需求人员提出需求到他可以直观的看到系统运行结果，一般至少需要一周以上的时间。

编程是我们非常熟悉的生产范式，无论是敏捷开发还是更传统的瀑布式开发，它所依赖的都是人与人之间的协调，而它的瓶颈也就在于人。人的不精确性和复杂性也会渗入到生产过程中，增加生产的困难。例如，一般情况下，软件需求文档、设计文档、使用文档和具体系统实现之间会逐渐出现偏离，最终可能完全相互脱离，文档失去参考价值。

NOP是一种非编程的生产范式，它强调的是开发人员、需求人员和机器三者之间协同工作，信息采用中立形式表达不再需要人工传递和转换。从编程到NOP需要经历所谓的范式转移过程，这意味着软件整体开发思想、开发架构、开发工具等都要经过彻底的改造，在新的技术思想指导下重构所有相关概念。

根据可逆计算理论，软件的构造可以被分解为两个相对独立的步骤：

使用领域模型所构成的特征向量来描述业务需求 业务需求 = [Biz, 权限, 流程, 报表...] 领域模型经过生成器转换以及差量描述调整后，产生最终所需的软件产品 App = Biz \oplus G1\langle 权限\rangle \oplus G2\langle 流程\rangle \oplus G3\langle 报表\rangle \oplus ...

NOP不是编程，也不是不编程，它实际上是两种工作之间的一种新的相互配合方式。

用户所能直观理解的逻辑，也就是用户需要自己控制的业务需求，它们通过所谓的领域模型来表达，而领域模型可以通过可视化工具来进行自助式设计。需求人员是有足够的逻辑能力来表达自身需求的，他们只是不熟悉具体程序开发所需要的语言和工具而已。比如说，一般的需求人员都能转融通熟练使用Excel、Visio等工具，并能够通过Excel公式、决策表、流程图等形式表达业务处理规则。

开发人员的工作可以看作是面向NOP编程（Nop Oriented Programming），他们所编写的不是对应具体需求的业湖南特产有哪些务代码，而是对整个业务领域进行生石花模型抽象，为业务用户提供可视化设计工具，并编写转换代码将领域模型映射为底层技术实现。对于部分很难进行直观展现的业务需求，开发人员能够通过差量编程的方式对已有模型进行补充和增强。

NOP的核心是具有可逆语义的领域模型空间。NOP以可逆计算为指导理论，它在各个层面上都强调可逆性。领域模型的可逆语义指的是机器在不需要人工参与的情况下，可以自动从领域模型中抽取信息高斯定理（部分或全部），自动将其转换为所需形式，并自动应用到所需场景。

人工参与的本质原因在于系统自身不具备可逆性，因此需要补充系统之外的信息，例如我们世界的背景个人档案存放知识，存在于其他文档中的全局设计信息，以及只存在于程序员头脑中的经验和设计思想等。一段通中考失利用语言编写的代码很可能无法通过工具自动分析得出其精确的设计意图，只有通过人这种最高级别的智能分析才可以实现逆向工程，反向抽取出其内在语义。但是如果采用精心设计的领域模型，则机器就可以很容易的理解模型语义，并在多种场景下以不同的方式使用同一信息。

在可逆语义假设下，我们很容易实现同一信息的多种展现形式，可视化设计仅仅是可逆语义的一个简单应用。

可视化界面 = 界面生成器(DSL)\\ DSL = 数据提取(可视化界面)\\ DSL = 界面生成器^{-1}\cdot界面月之阴面生成器(DSL)

领域模型采用领域特定语言（DSL）来描述，界面生成器可以理解DSL，从中抽取信息将其转换为可视化界面，同时界面生成器提供了对应的逆向信息提取机制，可以从生成的可视化界面中反向提取出DSL模型信息。所谓的可视化设计不过是模型的两种表现形式（representation）之间的可逆转换而已。

NOP要求每一个领域模型都能进行可视化设计，这表面上看起来是一个非常大的工作量，因为我们需要为每个领域模型都要提供相应的可视化设计工具。但是可逆计算理论指出可逆性可以复合，我们只需要构建一个通用的设计器的设计器，即所谓的元设计器，使用它就可以无限量的生成针对特定DSL的可逆的可视化设计器。

为了保证模型语义的可逆性，可视化设计器必须允许用户扩展，将用户特定的业务逻辑直接在DSL层面进行表达。否则，头脑简单的机器将无法直接理解复杂的用户逻辑。NOP中的设计器的设计器正是传统模型驱动架构（MDA）所缺失的部分。

NOP生产范式下的生产过程：

需求人员与机器协作完成业务建模：需求人员不需与技术人员沟通，直接使用类似Office的可视化工具对业务逻辑进行描述。人工智能可以在这一过程中扮演辅助角色，例如分析多个数据样本与指定领域模型的匹配情况，从而自动建立初步的模型描述等。 需求人员与机器协作完成业务验证：业务建模的结果是直接可以运行的系统，需求人员可以立刻从系统得到反馈，验证自己的业务设计。 机器自动录制测试用例，执行测试用例，完成回归测试和压力测试：因为业务系统根据领域模型自动生成，所以机器掌握了系统内在的很多大学生支教逻辑信息，它可以将用户的业务验证操作步骤直接录制为可以直观理解的测试脚本，作为回归测试用例和压力测试用例。机器也可以自动进行探索式测试，并将测试路径以用户可以直观理解的步骤形式展现出来。 机器跟踪用户操作过程，结合用户录入的模型信息，推知用户意图，从而自动生成相应操作手册和文档等。并且可以录制用户操作过程，作为在线教程。系统运行出现异常时，也可以录制用户操作步骤，便于技术人员复查。 机器根据领域模型，自动生成数据库设计、概要设计、详细设计等设计文档。 程序员在业务模型基础上补充分布式部署架构等纯技术层面信息。 程序员使用差量编程完成少部分特殊需求的代码实现。如果需求很常见，程序员使用元设计器（设计器的设计器）改进可视化工具，从而减少自己未来的工作量。 机器根据领域模型，自动生成相应运维监控指标，并对关键性数据进行采集q币有什么用和记录。 机器在系统运行过程中，利用大数据和人工智能对运行数据进行分析，自动进行局部程序优化，例如SQL执行计划、数据分布策略等。 机器根据领域模型，自动发布对外服务接口，并根据转换模型自动实现集成数据格式转换等。

借助于具备可逆语义的领域模型空间，通过NOP方式生产的软件不再是一个封闭的黑箱，而是打破了信息载体的形式边界，使得信息可以在人和机器，以及机器与机器之间自由流动。

NOP将会带来新的工作分工方式，更多的非软件专业人员可以参与到业务逻辑的构建过程中来，扩大软件的应用领域，加快软件的演化速度。NOP极大简化了机器眼中的软件构造，使得人工智能和大数据更容易和具体应用相结合，可以快速推进AI技术落地。

NOP生产是从简单到复杂的一个连续进化过程，通过不断补充对领域模型的解释方式，细化领域模型的描述粒度，我们可以不断改进已有的软件。

四. NOP的本质

生产力决定生产关系，生产关系反作用于生产力。第四次工业革命意味着生产力新的飞越，伴随它的必然是生产关系的根本性变革。智能时代的本质是机器智能的崛起，机器不再是被动的工具，而是能力与日俱增，逐步成长为生产活动的主动参与者。同时，面对越来越复杂的应用场景，直接面对需求变化的相关人员也逐渐成熟起来，他们不再接受固定的软件功能，而是有着自己特定的利益诉求，希望能够主动参与到软件构造过程中，主导软件在应用过程中的调整和演化。

在这种背景下，NOP生产范式本质上所体现的正是生产关系的一种新的变化，它所强调的是开黑翼之巢发人员、需求人员和机器三者之间的协同工作，或者说三者合作完成最终软件功能的实现和调整，每一方都有自己的价值和活动空间。

传统的软件生产其核心只有开发人员，所有最终的生产活动都是围绕开发人员组织实施的，这种单纯依靠编程（Programming）的生产模式将所有压力集中在程序员身上，导致程序员不堪重负(不996干得过来吗？)。

另一方面，人工智能的火热发展让人们浮想联翩，采用“人工智能写代码”看似是一条解决问题的捷径。但问题在于，目前的人工智能只是所谓的浅层智能，可以解决简单的判断、识别问题，无法进行更加复杂的逻辑组织，在可预见的未来，人工智能写代码还只是一个美好的设想，没有真正能够落地的技术方案。

实际上，目前计算机科学对于程序结构的理解过于简单，只有简单的函数、类、对象等概念，明显是无法支撑复杂逻辑的自动化构建的（对比物理学就可以知道，夸克、原子、分子、固体、液体、气体、凝聚态、等离子体...，我们掌握了多少物质形态和物理规律才创造了现代工业化生产体系）。

为了使得机器和非专业技术人员也能够平等的参与软件生产，我们必须要建立一种新的逻辑抽象方式，使得逻辑可以按照复杂性分级，简单的可以被直观理解的逻辑，以及简单的可以被机器自动识别处理的逻辑需要被明确分离出来。可逆计算理论为实现这种逻辑分离提供了一条可行的技术路线。特别是可逆概念的系统化应用将构建一个信息转化友好的逻辑世界，使得智能更容易产生和成长。

NOP是面向未来的软件生产范式，在强人工智能诞生之前，它代表了机器智能、专业开发知识以及其他领域的人类智能相互协作的一种典型方式。在追寻强人工智能的漫长旅途中，我们需要加深对软件所处的逻辑空间内在构造规律的认知，智能社会的实现不可能是一蹴而就的，NOP的发展将是人工智能不断扩大应用范围的必经之路。

五. NOP不是什么（一）NOP不是可视化编程

可视化仅仅是NOP的一个副产品，并不是NOP的目标。NOP首先是采用创新的技术思想，基于领域模型和可逆性的概念极大降低了软件结构构造的复杂性。在NOP中，通过领域模型的抽象，我们对于软件结构的认知更加深刻了，表达同样的业务逻辑，相比于传统的编程方式，我们所需要传递的信息总量大大下降了。即使完全不使用可视化设计工具，我们的生产效率可以出现指数级的上升。

一般的可视化编程强调的是模型的可视化语义，导致程序语义只能通过可视化界面来理解。如果可视化设计器出错了，则我们没有任何其他途径可以越过可视化设计器来直接修改业务代码。如果我们对现有的可视化设计器不满意，没有任何技术手段可以对可视化设计器本身进行定制修改。当我们在多个业务场景中需要有不同形式的可视化设计器来设计同一底层模型时，也没有规范化的方案来保证多个设计器语义之间的一致性。

更为严重的问题是，一般的可视化编程为了降低自身实现难度，会要求业务代码的实现结构也针对可视化设计器做大量侵入性的修改。业务代码中能够使用的抽象手段受到极大限制，阻碍了业务模型的深度复用。同时，可视化设计器自身的升级修改也可能导致业务代码需要进行相应的调整。

在NOP中，强制要求所有领域模型都具有可逆语义，因此同一个模型很自然的可以具有多种展现形式，可视化设计仅仅是可逆语义的一个简单应用而已。在NOP中，不需要针对每一个领域模型单独编制其对应的可视化设计工具，元设计器可以利用模型的可逆语义自动的生成对应的设计器。

（二）NOP不是代码生成工具

NOP依赖于内置的代码生成器（Generator）来推导产生大量的衍生代码，但这种代码生成是一个抽象的概念，它类似于反复应用不同的数学定理来推导产生新的定理，具体实现中可以对应很多种不同的实现手段。

一般概念中的代码生成工具都是单向的、一次性的脚手架生成器。程序员设计好模型后，手工运行代码生成工具，根据模型生成脚手架代码，然后程序员再手工调整生成出来的代码，填充更多的细节等。如果模型发生变动，重新运行代码生成工具时将导致已生成的代码被覆盖，手工调整的部分将会丢失。在这种开发模式中，代码是第一位的，而模型是相对次要的、仅起参考作用的。当代码和模型冲突时，胜出的永远是代码。

NOP中，模型是第一位的，代码必须永远与模型保持一致。因此，NOP中的代码生成机制应该采用类似C++模板元编程（Template Metaprogramming）的编译期模板展开技术来实现。当模型发生变化时，由编译器自动重新生成代码，无需程序员手工操作。同时，基于可逆计算理论，NOP是支持增量模型变化的，当模型变动时不会覆盖程序员手工编写的代码，而只会传播模型的增量变化部分，同时自动实现模型代码和程序员手工编写代码之间的差量合并。

（三）NOP不是零代码开发

零代码（zero-code/no-code）开发平台的目标用户不是专业程序员，而是具有一定技术理解力的业务人员，它强调的是普通人经过简单培训即可独立实现业务软件模块的机车美女快速开发。为了尽量减少对业务人员的技术储备要求，同时尽量降低业务人员在操作过程中出错的可能性，零代码开发平台唯一的选择就是尽可能多的替用户做决定，呈现给用户尽量少的技术选项。因此，零代码开发平台如果好用、易用，就必然是用途非常狭窄的、功能固化的。它一般只针对小型系统，很少考虑架构层面的可扩展性，也很少考虑性能、安全性等非功能性需求。

为了克服零代码开发的弊端，最近几年还出现了一种所谓的低代码开发（Low-code Development）模式，它通过可视化设计结合少量编码的方式极大扩充了自身适用的应用范围。

NOP面向的群体是专业程序员以及业务人员，它能够支持从简单的小型应用（如普通的OA和MIS系统）到复杂的大型关键性应用（如银行核心系统）之间的连续演化，可以有效的实现专业程序员和业务人员之间的分工协作。专业程序员的核心价值在于建立领域抽象，将业务领域中常见的逻辑组织模式通过领域特定语言（DSL）和业务组件的方式固化下来。业务人员在已经确定的技术范围之内，就可以使用可视化设计工具创建和修改领域模型（使用DSL来表示），从而实现业务功能模块的开发。

NOP不仅仅不是零代码开发，它也不是低代码开发。零代码开发是完全没有扩展能力，低代码开发是允许开发人员编写第三方组件和插件，在一定程度上扩展可视化开发工具的能力。但是低代码开发平台的扩展能力仍然是非常受限的，这典型的就表现为low code开发平台本身并不是使用low code开发技术开发出来的，而且low code开发平台一般会给扩展代码增加大量限制性要求，这对于开发人员而言，意味着他所能动用的技术武器库是有着明显倒退的。

而NOP与low code的不同之处在于，NOP的理论基础是可逆计算理论而不是模型驱动架构（MDA）和组件/构件理论，它从本质上摆脱了现有主流技术体制对软件构造过程的基本限制。在NOP中，所有的领域模型设计器都是基于可逆计算原则利用元设计器逐步构建出来的。

（四）NOP不是更强大、更高级的程序语言

从汇编到Fortran，到C/C++语言，再到Java/C#语言，一路走来，程序语言的抽象层次在不断提高，越来越多的通用逻辑结构被内置到语言中，语言变得越来越强大。一些现代高级语言不断追求代码形式的表现力，如号称综合了面向对象和函数式编程等多种编程范式的Scala语言，往往一句话可以顶传统编程语言的n句。所谓第四代程序语言（4GL）更是内置了数据库管理、界面布局等大量针对特定领域的语言结构，使得开发专项应用时如鱼得水。

NOP的核心并不是一个单一的、与现有编程语言相比更加强大的高级程序语言，它强调的是由大量不同的领域特定语言（DSL）所共同构建的领域模型空间，以及领域模型空间中所需要满足的可逆性原则。如果仔细回顾一下历史，我们会发现，传统的编程语言都是图灵完备的通用程序语言。通过不断引入强大的通用语言结构，我们在所有业务领域都免费获得了新的更高层次的抽象能力，每一代的程序语言都相当于是更好的、更强大的图灵机。

但是正如摩尔定律终将走到尽头，通用程序语言的这种免费的抽象提升也逐渐陷入停滞，这表现为主流程序语言内置的语言特性开始出现加速趋同的倾向。不同的语言具有类似的语言特性，它们在某种意义上是完全等价的，差别仅仅是语法形c92式上的，或者说是文化习惯上的。

可逆计算理论指出可以定义一个新的通用语言结构：可逆的差量运算，从而再一次为所有领域免费提供了抽象提升的机会。但这一概念真正的重要性在于，它打开了一条与此前完全不同的抽象上升通道。可逆计算将领域特定语言（DSL）推到了应用前台网站怎么赚钱，而DSL相比于通用语言不是更强大，只是更有用。

在可逆计算理论中，DSL需要超越通用语言提供针对特定领域的更有效的逻辑表达形式，同时在结构层面需要满足某种可逆性要求，DSL为了将某一方面推进到极致就必须放弃很多其他方面的能力，导致它往往不是图灵完备的！

NOP中，大量图灵不完备的、只针对特定领域的DSL构成一个语言森林，我们不再依赖单一的、固定的语法结构，而是直面世界的复杂性，开始构建细腻丰富的结构层次。同时，NOP中需要根据领域模型推导生成衍生代码，这在DSL层之下开辟了一个新的战场：编译器所在的元模型空间。传统上，程序语言的语法规则是固定的，即使是内置领域相关结构的第四代程序语言（4GL），也是不允许程序员定制和选择编译规则的。NOP中，代码生成规则也只是普通的代码，程序员可以自由的定制和扩充，整个编译规则空间是图灵完备的。NOP打破了旧世界对程序员创造力的桎梏，就像一句口号所鼓吹的，未来“只有想不到，没有做不到”。

（五）NOP不是人工智能

NOP虽然致力于解决智能时代的软件生产力瓶颈问题，但是它并不依赖于人工智能的概念和技术，它与人工智能是一种相辅相成的关系。

人工智能可以作为庞大的充满不确定性的世界和确定性的小型模型空间之间的一个桥梁。

用户画像模型 = AI（海量数据）\\随机推荐输出= AI（用户画像模型）

或者作为更加人性化的输入输出接口

业务模型 = AI（自然语言输入）\\ 自然语言输出 = AI（业务模型）

NOP通过可逆的领域模型简化了人工智能所需要处理的逻辑结构，并可以利用人工智能来与人类世界以及大数据世界交互英文儿歌歌词。人工智能负责解决的问题往往是局部性的非常困难的技术问题，它要发挥最大作用还需要和周边系统和人员发生协同作用，而NOP所提供的正是一种整体解决方案。

以下为闲聊时间

TL;DR

不知诸位看官有没有发现，业内与差量（Delta）相关的概念正如同雨后春笋一样纷纷冒头。前段时间Databricks公司发布新产品，干脆直接叫作Delta Lake。搞神经网络的家伙们也沿着ResNet越走越远，最近流行的概念已经是differential programming。这反映了整个业界正在经历从全量思维向差量思维的转变，差量革命一触即发。

很多人已经敏锐的意识到了技术发展到了一个转折点，一种新的技术可能性已经出现。现在这种情形其实非常类似多年以前Ajax和Agile概念诞生的前夕，有很多独立的实践，有各种聪明的实现，但是还缺乏一个有灵魂的概念，能够把它们统摄在一个具有普遍意义的命题之下。

我的观点是差量不仅仅是简单的差别、增量、变化，可逆才是它的灵魂！可逆计算理论可以为下一代软件构造提供一个合适的理论框架，突破简单的组件式、积木式构建思想的束缚，为前端的、后端的、应用层的、系统层的等等诸多表面上形式不同的逻辑构造方案找到统一的理论解释，并推动它们的协同演化。当从细部到整体，从内部组成到外部环境，各个层面都满足可逆性要求时，软件的构造将出现真正本质性的变化。

智能时代的软件需求必然催生新的软件生产模式。国外逐渐开始出现所谓的Low Code开发模式，而国内也是一众的免编程、No Code的某某云。但是这些概念在感觉上总是差点意思。

No Code基本上就是No Brain，注定无法生产足够复杂的商业逻辑。而Low Code听着也有点"low"(谁让它的名字里就带个low字呢)，而且Code的概念是程序员圈子里的“黑话”，投资人不一定懂，万一说你这是码农思维，那还怎么从他身上扎钱呢？

其实，免编程也好，快速开发也好，直接作为生产力工具在中国的大环境里不一定有着很大的实际优势。我们有着奋斗者的精神，有996/007的福报，税务上再找点"优惠"，整体利润瓶颈不一定在人工上。再说，很多系统的建设目的本来就不是为了用的，toB市场的水，深不见底。

NOP是我们团队所提出的一个新的概念。它的核心不是简单的降低生产成本，而是可以促成新的分工方式，从而促进4k壁纸软件形态的变革，创造新的商业模式。另外，关键的关键，是它的名字起得好啊！

NP ?= P 是计算机科学的核心问题之一。 NP中间加上一个元音o之后，发音朗朗上口。 NOP是Nop is nOt Programming和Nop Oriented Programming的递归缩写，这符合黑客社区的传统。 nop在计算机领域也有空操作的意思，这符合可逆计算“正+负=空”的思想。

总之，NOP即有理论支撑，又有文化渊源，高端大气上档次有木有？总而言之，这么闪亮的概念，你值得拥有。我们的口号是You can Nop it!

码这么多字，目的就是为了传播可逆计算修改照片和NOP的思想。希望更多的架构师能够从单纯的业务系统构建过程暂停一下，喘喘气，将思考的方向从如何构建好用/高效的系统转向如何将更多的逻辑分离，如何通过差量的方式表达逻辑。它的目的不一定是提高生产力，而首先是为了加深我们对世界基本构造规律的认识。

前段时间，和 @徐飞 、 @侯振宇 等人也作了简短沟通，交流了一下业界情况和相关技术方案，发现很多队伍已经上路了，看起来还都兵强马壮的样子。欢迎有兴趣的同仁和我联系（canonical_entropy@163），共同探讨未来软件的架构模式。

支付宝现在跑得很快，一些做法可以纳入到NOP的范畴中考察。侯振宇对此作了很好的总结，很值得参考一下。

基于可逆计算理论设计的低代码平台NopPlatform已开源： gitee: canonical-entropy/nop-entropy github: entropy-cloud/nop-entropy 开发示例：tutorial