可逆计算理论
知乎专栏
集中收录了作者关于可逆计算理论和Nop平台实现原理的相关论述
三句话解释什么是可逆计算
- 面向对象中的继承和Rust语言中的trait不包含删除语义，而且仅表达了对象-方法这样一级关系，结构层面仅对应于Map。
- 面向对象的最强形态是带模板元编程能力的泛型对象，它在结构层面上可以看作是
Map extends Map<Map>。 - 如果将Map扩展为Tree结构，并且扩展extends算子包含减法，这样Tree就成为包含逆元的DeltaTree，整体结构将升级为
Tree x-extends Tree<Tree>。
这个抽象可以很自然的将抽象语法树和文件系统纳入自己的范畴，成为一个具有广泛应用领域，不限制于某个程序语言内部的通用计算模式，
落实为具体的技术形式就成为可逆计算理论所定义的核心软件构造公式
|
Docker和k8s中的kustomize都可以看作是可逆计算的具体实例
可逆计算: 下一代软件构造理论
对可逆计算理论的概要介绍
写给程序员的可逆计算理论辨析
从程序员熟悉的概念出发详细解释了差量与差量合并在程序实践中的具体形式和做法，并分析一些常见的对于可逆计算的理解为什么是错误的。
写给程序员的可逆计算理论辨析补遗
继续补充一些针对可逆计算理论的概念辨析，澄清对于可逆计算理论的一些常见误解
可逆计算理论中的可逆到底指的是什么？
可逆一词与物理学中熵的概念息息相关，熵增的方向确定了物理世界中时间箭头的演化方向，可逆计算理论所研究的是面向演化的粗粒度软件结构的构造规律，所以可逆正是这个理论的点睛之笔。一些没有学过热力学和统计物理的同学，对于熵的概念一无所知，看到可逆这个说法难免会感到一头雾水。可逆重要吗？软件要怎么可逆？逆向执行吗？这有什么意义？在本文中，我简单解释一下可逆计算理论中可逆到底指什么。
从可逆计算看Delta Oriented Programming
本文对比了可逆计算理论与软件工程理论界的相关工作，如面向特性编程（FOP）和面向差量编程（DOP），并指出在可逆计算视角下，这些理论还存在哪些不足之处。
从张量积看低代码平台的设计
框架设计中的多维度扩展在数学层面上可以看作是张量积空间上的线性映射函数。本文从理论层面解释了可逆计算原理如何与Loader抽象相结合。
写给程序员的差量概念辨析,以Git和Docker为例
虽然都叫做差量，但是差量和差量之间仍然有着非常深刻的区别。总的来说git和docker本质上都涉及到差量计算，但是它们所对应的差量也有着本质上不同的地方，这里的精细的差异需要从数学的角度才能解释清楚。一般人对于差量概念的理解其实是望闻生义，存在着非常多的含混的地方，所以很多的争论本质上是因为定义不清导致的，而不是这个问题本身内在的矛盾导致的。
金蝶云苍穹的Extension与Nop平台的Delta的区别
DeepSeek AI对于Delta定制概念的理解–深度超越普通程序员
通用的Delta差量化机制
从可逆计算看DSL的设计要点
Nop平台基于可逆计算原理，提出了一整套系统化的构建机制来简化DSL的设计和实现，使得我们很容易增加针对自己业务领域的DSL，也很容易在已有DSL的基础上进行扩展。
GPT用于复杂代码生产所需要满足的必要条件
现在很多人都在尝试用GPT直接生成代码，试图通过自然语言指导GPT完成传统的编码工作。但是，几乎没有人去真正认真的考虑一下生成的代码如何长期维护的问题。本文从理论层面分析了GPT用于复杂代码生产所需要满足的必要条件，并提出了Nop平台与GPT结合的具体策略。
如何评价一种框架技术（比如ORM框架）的好坏
对于一种新的框架技术，”很方便、很好用”这样的评价表达的仅仅是一种主观感受，能否在客观层面定义一些不受人的主观偏好影响的客观标准？
什么是好的模型？
业务开发如何才能独立于框架
Nop如何克服DSL只能应用于特定领域的限制？
Nop平台可以看作是一个语言工作台（Language Workbench），它为DSL(领域特定语言，Domain Specific Language)的设计和研发提供了完整的理论支撑和底层工具集。使用Nop平台来开发，主要是使用DSL来表达业务逻辑，而不是使用通用的程序语言来表达。有些人可能会有疑问：既然DSL是所谓的领域特定语言，那岂不是意味着它只能应用于某个特定领域，这样在描述业务的时候是不是会存在本质性的限制？以前ROR(Ruby On Rails)框架流行的时候，热炒过一段时间DSL的概念，但现在不也悄无声息了，Nop又有何特异之处？对这个问题的回答很简单：Nop平台是基于可逆计算理论从零开始构建的下一代低代码平台，而可逆计算理论是一个系统化的关于DSL设计和构建的理论，它在理论层面解决了传统DSL设计和应用所存在的问题。
如何开发一个能够开发低代码平台的平台
从可逆计算看DSL的设计要点
Nop平台为什么是一个独一无二的开源软件开发平台
Nop平台与其他开源软件开发平台相比，其最本质的区别在于Nop平台是从第一性的数学原理出发，基于严密的数学推导逐步得到各个层面的详细设计。它的各个组成部分具有一种内在的数学意义上的一致性。这直接导致Nop平台的实现相比于其他平台代码要短小精悍得多，而且在灵活性和可扩展性方面也达到了所有已知的公开技术都无法达到的高度，可以实现系统级的粗粒度软件复用。而主流的技术主要基于组件组装的思想进行设计，其理论基础已经决定了整体软件的复用度存在上限。
为什么说XLang是一门创新的程序语言？
XLang语言之所以是一门创新的程序语言，是因为它创造了一个新的程序结构空间，在这个结构空间中可以很方便的实现可逆计算理论所提出的Y = F(X) + Delta的计算范式
DeepSeek的通俗版解释：XLang为什么是一门创新的编程语言？
如果重写SpringBoot，我们会做哪些不同的选择？
如果我们完全从零开始重新编写SpringBoot，那么我们会明确定义哪些核心问题由底层框架来负责解决？针对这些问题我们会提出什么样的解决方案？这些解决方案与SpringBoot目前的做法又有哪些本质上的差异？Nop平台中的依赖注入容器NopIoC是基于可逆计算原理从零开始实现的一个模型驱动的依赖注入容器，它通过大约5000行代码，实现了我们所用到的SpringBoot的所有动态自动装配机制和AOP拦截机制，并且实现了GraalVM集成，可以很容易的编译为native镜像。在本文中，我将结合NopIoC的实现代码，谈一谈在可逆计算理论视角下对IoC容器设计原理的所作的一些分析。
低代码平台需要什么样的ORM引擎？
什么是ORM？ORM为什么可以简化数据访问层的代码编写？哪些常见的业务语义可以统一下放到ORM层来表达？在低代码平台的语境下，数据结构需要支持用户自定义调整，从前端展现界面到后台数据存储的逻辑路径需要被尽量压缩，ORM引擎可以为此提供哪些支持？如果我们不满足于事先限定的某些低代码应用场景，而是希望实现一条从LowCode到ProCode的平缓的升级路径，我们对ORM引擎会提出什么样的要求？
低代码平台需要什么样的ORM引擎？(2)
为什么在数学的意义上GraphQL严格的优于REST？
Nop平台中通过严密的数学推理，对于GraphQL的定位进行了重新的诠释，获得了一些新的设计思想和技术实现方案。在这种诠释下，NopGraphQL引擎实现了对REST的全面超越，
可以说在数学的意义上GraphQL严格的优于REST。
从零开始编写的下一代逻辑编排引擎 NopTaskFlow
NopTaskFlow是一个基于可逆计算理论实现的逻辑编排引擎。
为什么NopTaskFlow是一个独一无二的逻辑编排引擎
NopReport为什么是一个非常独特的报表引擎？
NopReport与一般的报表引擎不同，它可以直接采用Excel和Word作为模板，而不一定需要使用专用的可视化设计器。
为什么SpringBatch是一个糟糕的设计？
SpringBatch的设计在今天看来存在严重的设计问题，对于性能优化、代码复用都极为不友好。本文分析了SpringBatch的设计问题，并结合NopBatch这一新的批处理框架的实现方案来介绍下一代批处理框架的设计思想。
为什么Nop平台坚持使用XML而不是JSON或者YAML
在Nop平台中，XML和JSON是自动支持双向转换的，本质上用哪种表达方式都不影响模型的语义
从可逆计算看低代码
关于Nop平台底层理论的答疑
什么是数据驱动？它和模型驱动、领域驱动、元数据驱动、DSL驱动之间有什么区别？
XX Driven是软件工程领域的常见黑话之一，翻译过来就是某某驱动，替换一下XX，我们就得到了数据驱动、模型驱动、领域驱动、元数据驱动、DSL驱动等等这一大堆的驱动。一个很自然的疑问是，这些不同的驱动之间有什么区别？有什么必要人为制造出这么多不同的概念？
小学生也可以轻松掌握的Paxos算法秘奥
Paxos算法是分布式领域中一个非常基本的算法，一向以晦涩烧脑著称。但是它之所以让人感到摸不着头脑，主要是因为我们不容易直观地理解它为什么要这样设计。尽管我们可以通过具体例子来验证其正确性，甚至可以用严谨的数学证明来说服自己它是对的，但我们还是很难回答，为什么一定要选择这种方式？这是否是唯一可行的方法？有没有可能不依赖数学推导，就能找到一种解释，让Paxos算法在直觉上显得不言而喻？
Paxos的魔法学研究报告, 普通小学生也能理解的Paxos算法讲解
函数式编程为什么有利于解耦(Decouple)
函数式编程的思想以及在我们日常编程中如何应用函数式编程来实现逻辑解耦，函数式编程在哪些方面提供了对于面向对象编程的一种有益的补充
从React Hooks看React的本质
|
render函数是一种好不容易建立起来的信息管道，如果使用一次就随手丢弃，那实在是太浪费了，何不反复利用？通过引入具备响应性的状态变量，规定一个全局的响应式规则：“无论什么原因导致state变化，自动触发局部的render函数重新执行”，就可以使得render函数得到成功的升华，完美的将微观的交互性嵌入到了宏观的信息流场景中。