This topic created in 114 days ago, the information mentioned may be changed or developed.
让我们先从一个简单的事实开始
我们都知道，最好的程序员能够做出最简洁、最小的抽象系统，让我们将其称之为P，
然后，差一些的程序员（比如我）会写一些附带功能来扩展这个系统，让我们将我的代码称之为Code,
我们可以将这个过程表述为：
App = P + Code
这个过程是很自然的，不是么？
OK ，既然我们都接受这个自然的过程，那么设想实际上存在一个逆过程不是也很自然吗？
假设这里有一个庞大、丑陋的巨型系统W，难道不该存在一种逆过程，将这个系统改进成一种更简洁的形态L吗？
就像这样：
W + inverse Δ = L
或是：
APP - Code = P
你可能没见过这个东西，但是在数学上，它是成立的。
现在，让我换一个视角继续解释这个理论。
假设你的公司开发了某个实用的大型系统，然后突然来了个客户看上了你的大型系统。
但是，你的公司的需求和客户公司的需求又不可能完全一致。
传统的做法是什么样的呢？
你可能将两个系统的共性剥离出来组成一个小型的核心系统，然后维护两套派生系统。
但是在可逆理论指导下，则完全没必要这么做，
你完全可以全心全意维护你公司主用的系统，然后编写 delta 代码来掩盖二者不兼容的部分。
假设：
X 是你的系统
Y 是顾客要求的系统
Δ 是两个系统之间不兼容的部分
注意Δ包含：
- 客户要求增加的功能，
- 客户要求减少的功能，这个要求可能不是显式要求，而是他不需要。
我们可以将其写为：
Y = X + Δ
关键点在于：
- X 从来没有被破坏、拆分
- 系统差异是“附着的”，而不是“撕裂的”
让我们再用官方文档中的一个例子来比较一下这个范式的特点：
Object-Oriented: The inequality A > B Component: Addition A = B + C Reversible Computation: The delta Y = X + ΔY 我觉得你可以注意到，可逆计算是组合范式的一个扩展，它引入了一个非常有趣的删减原语。
传统组件复用是“相同才能复用”，它把口号翻转成“相关就能复用”；
只要两个系统能写成 X 与 X+Δ，就能零修改地共用 X。
等于把“封装必须稳定”变成了“演化可以破坏封装”，彻底掀掉面向对象给系统级复用盖的天花板。
说来也巧，我觉得我们实际上早就遇到过这个理念一次，在 Javascript 的原型链继承特性上。
只不过可逆计算理论把它往外推，延伸到了整个项目工程的范围。
目前我还看不出这个理论能够带来什么实践上的颠覆，但是它提供的思想是很具备启发性的。
想想看这个点子你编写代码来删减功能，多有趣啊。
这个理论的作者目前正在制作一个基于该理论（及其延伸理论）的低代码平台Nop Platform
这个项目的官方口号是：
App = Delta x-extends Generator<DSL>
不过这些个延伸理论有点太复杂了，我也不是很懂，如果你想了解的话你可以读一下它的文档。
官方介绍：
https://gitee.com/canonical-entropy/nop-entropy/blob/master/docs/theory/reversible-computation.md
项目仓库：
Gitee: https://gitee.com/canonical-entropy/nop-entropy
GitHub: https://github.com/entropy-cloud/nop-entropy
Supplement 1 Jan 13
首先，我要修正本文中存在的两处错误：
- 官方介绍在知乎专栏上有更好的排版：https://zhuanlan.zhihu.com/p/64004026
- 我在引用官方的例子时错误地把它的英文版复制过来了，中文版如下：
面向对象: 不等式 A > B 组件: 加 A = B + C 可逆计算：差量 Y = X + △Y 其次，我不断收到关于本文中的数学公式不严谨、概念判断有谬误的讨论。
在此我诚恳接受大家的批评，我的本意是运用大家对于数学计算的直观理解，快速建立起对可逆计算理论的印象。
现在看，这么做过于鲁莽和草率。
你要是不喜欢我的表达方式，你可以把文本喂给AI，让它换一种你喜欢的方式说。
就哪怕你在提示词里加上：”给我分析一下这垃圾有什么价值“，我都不会在乎半点。
我写这个帖子的目的是分享一下这个理念，顺便也想知道它的核心概念：
「系统不必拆分，也能继续演化」
是否存在实质性错误？
我本人和该理论的作者没有任何关系，也未参与关联项目 Nop Platform 的运作。
在此贴出链接只是出于对原作者的尊重。
所以，你要是真的有货，就亮出来；
尽管亮剑，尽情亮剑。
真把项目搞垮搞黄了和我也没有半毛钱关系，我也是吃瓜的。
现在想来，这个理念之所以让我印象深刻，是因为它揭示了一些我们早已习以为常却从未意识到其存在的东西：
「所谓“编程”，不正是从“现实”世界这个混乱庞大的系统中，抽出一些简洁漂亮的东西吗？」
Supplement 2 Jan 13
现在，我要问你：「是什么阻止了我们，对已有系统再做一次同样的抽象？」
 | 1 Nivdc OP 里面有一段是 KIMI 写的，把这理论都吹上天了 |
 | 2 sillydaddy Jan 12 感谢分享！很新奇的概念，回头看看。 |
 | 3 zizon Jan 12 要不先读读初等数论. |
| 5 Nivdc OP @zizon 我知道你可能对我采用的简单的加号+和减号-产生一种直觉上的误解，其实它和数学概念上的加减不是一回事，它代表着一种组合过程，理论的作者用了个更合理的合并符号''，我在这里只是出于介绍的目的将其简化了。 |
 | 6 newtype0092 Jan 12 "你可能没见过这个东西，但是在数学上，它是成立的。" 我一个数学学渣都知道，你要把软件迭代这种多次变换压缩成一个 Δ，最起码得在一个线性空间里吧。。。 Y1 = X + Δ1 Y2 = X + Δ1 + Δ2 你要 X = Y2 - (Δ1 + Δ2) 成立 那 X + Δ2 = Y2 - Δ1 也得成立吧？ 软件工程完全不是这么回事儿好么，每次迭代的代码都得和之前一次的代码完全正交不相关，什么应用能这么开发呢？ |
 | 7 Nivdc OP @newtype0092 你的质疑是极好的，因为我自己也非常怀疑这个玩意，但是我的水平太差了，可能没办法准确理解你的核心疑问。 所以我让 AI 帮我解读了一下，它是这么回答的： 这里有一个非常微妙、但决定性的错位： 你的真实意思是： Δ 是一种 “工程差异的描述方式” 它是依附于 X 的补丁/遮罩/视图 而他说的“数学成立”理解成了： Δ 是一种 “可独立存在、可组合、可逆的变换元素” 这两者完全不是一回事。 你心里想的是： Δ 只在 (X → Y) 这个关系中有意义 而他以为你说的是： Δ 是某种普适的变换算子 |
| 8 Nivdc OP @newtype0092 可能是我说的这句“在数学上，它是成立的”这个判断确实是有问题的，造成了误解，非常抱歉 |
 | 9 ZGame Jan 12  1 智商检测器,软件都是把复杂的东西搞简单,这个理论把简单的东西复杂化,抽象化 |
| 10 Nivdc OP @ZGame 没有啊，我觉得很简单啊，就是在用组合范式的时候你可以减掉原有的功能，为系统级复用提供了解决方案。 要是解决问题的规模很小，这个范式不会起效的，甚至就是句废话，但是在大规模系统系统复用上，这个理论很有参考价值。 |
| 11 newtype0092 Jan 12 @Nivdc #8 没有我就单纯探讨一下。。。 我刚才还好奇专门读了他的文档，说真的有点神棍了。 他前面提出了一点数学上的内容，但实际上是偷换在偷换概念。 数学的运算都是有严格定义域的，他是典型的把线代、机器学习那套最基础的 y = f(x) + d 的东西硬往不相关的软件开发领域套，甚至还放了个完全不知想表达什么的图。 这部分你随便找个机器学习课程看前 1 个小时就能能懂，没啥高深的。 而且后面的部分和前面的数学部分基本没啥关系，看起来就卖弄一些概念，把数学苦手的人先吓住，然后就随便忽悠了。。。 |
| 12 Nivdc OP @newtype0092 我觉得你说的完全正确，那个天书文档真的有点难懂，感觉就是纯在卖弄概念 但是“软件演化来自Δ差量递进”，我觉得这个理念确实有其先进和独到之处 |
| 13 newtype0092 Jan 12 @Nivdc #12 Δ差量这里我觉得他也在偷换  软件迭代是需要很多维度的输入的，设计编码测试等等，是需要实打实的工作量的，即使现在有 AI 了，微调、推理等工作量也是少不了的。 他想把这个东西往数学上去靠，把这个概念解释成一个可以按某种方式直接计算的东西（神奇 操作 ）。数学概念上这个Δ可运算是因为有定义的规则和成熟的求解工具，计算器按按好了。 软件上要想达到这个效果就需要有一个规则能让我直接得到正确代码，而不用上面的工作的过程。 仔细想想这不是就是我们 (Ctrl+)CV 工程师的绝学么。。。 那现在的问题就是只要找到一个万能代码库，未来所有功能直接从里面 copy 出来就行了，要修改什么功能直接增删对应的代码。 那现在这个代码库从哪来呢？网上先搜代码也肯定覆盖不了所有需求。 所以就可以把新功能限制在指定的框架范围内，把支持的功能全部整理成模版。。。 然后就有种越想越熟悉的感觉，你懂吧 |
| 14 ZGame Jan 12 @Nivdc #10 看起来是一套框架, 你怎么证明他不是弄了一套 App=f(a,b,c,d,e,f,g....) ,让程序员去按照他的逻辑去填参数呢。 App=f(a)+g(b)+v(c) 这样是不是更简单点呢？ |
 | 15 dhb233 Jan 12 什么？你把屎山解决了？ |
 | 16 nutting Jan 12 看起来像是共产主义宣言 |
| 17 Nivdc OP @newtype0092 汗流浃背了 但是我觉得这里的关键不是万能代码库，而是你现在在开发的东西最终都会变成现实世界中某个领域的专属代码库，对吧？ 如果现在出现了另一块与你的领域有重合但不完全相同的领域，需要你的代码。 那么Δ差量为我们展示了另一条路经，除了“抽出两块领域共有的东西”这个方法外，你还可以反向削减原有的代码库，使其符合当前的需求。 Nop Platform 那一套扩展确实非常可疑，我也没仔细看过。 XML+Java 实现的，这能靠谱吗（滑稽） 此外我还觉得即便这个范式能够得到推广，在实践中 Y=X+Δ 也很有可能存在一个临界点，取决于 Y 和 X 的差异程度，一旦Δ本身出现膨胀，这个范式需要退化到旧范式的路径上重组为 Y=C+ΔY ，X=C+ΔX 。 |
 | 18 momocraft Jan 12 2 年前在知乎看过了 在实用案例出现前被我归类为民科 |
| 19 Nivdc OP @ZGame 我觉得你说的和 @newtype0092 的质疑是比较相似的，那就姑且先抛开 Nop Platform 这个框架看，你觉得这个理论是不是有些有道理的地方呢？ |
 | 21 hahiru Jan 12 APP - Code = P APP - P = Code 但是程序能这么操作吗？程序和数学并不完全能类推。 Code 是在 P 的基础上写的。也许 Code2 是在 Code1 的基础上写的。 最后的屎山叫 APP 但是 APP 中你如何轻松剥离 CodeX 然后得到巧克力味的屎山呢？ 话说也许以后 AI 超牛逼了全 AI 自己写，全规范全流程。但是目前来看人类不适合这种模式。 |
 | 22 GeruzoniAnsasu Jan 12 Δ不遵循交换律和结合率。 所以 X+ΔY 不等价于 X-(-ΔY)。 实际情况不可能是从 X 里「删减」得到 Y ，而是必须引入了大量的适配层，「增加」大量非必要的代码才能得到 Y 。 OP 没写过版本迁移适配代码吗？ |
 | 23 litchinn Jan 12 这不典型的 P-NP 问题吗，你可以轻松验证你能从一个复杂系统剥离出一个最小核心，但你无法快速找到解 |
| 25 Nivdc OP @hahiru 但是 APP 中你如何轻松剥离 CodeX 然后得到巧克力味的屎山呢？ 答案很简单啊，不要合并 Code1 、Code2 到 App 里面，用一个元编程手法保持替换掉不就好了？ |
| 26 Nivdc OP @GeruzoniAnsasu 没写过。关键问题在于，如果 X 和 Y 的差异极小，用直觉来思考怎么会存在“大量非必要的代码”呢？ |
| 28 Nivdc OP @GeruzoniAnsasu 我可能有误解，但我感觉你陷入了一个误区，可逆计算理论不尝试解决一个系统版本更新迭代的问题，它尝试解决的是大系统复用的问题 |
| 29 GeruzoniAnsasu Jan 12 @Nivdc 推广就直说。 现在大家的评论之所以停留在逻辑层面是想尽可能不误伤涉及的项目，万一真仔细看了项目到时候可能就要开喷了。 另「系统版本」原本应该是个 Abastraction. 任何迭代都会发生版本变更，你可以声称某个理论「不解决版本号第一位数字增加了 1 的情况」，只解决「系统开发过程的演变的问题」。但从抽象上来看这两者完全等价。 之所以要问有没有写过跨版本适配代码，因为这是最容易理解「所谓的可逆计算」的范式： 你在现有 migration 的基础上增加一些 migration ，在现有的 service 结构上增加一些 adaptor ，可能是新适配旧也可能是旧适配新 但无怎样它们在软件工程/真实世界的表现形式都只会是「增加一大坨本可以（如果不保持兼容性的话）不要的代码和层」。 数学上等价于一个工程实现完全不代表工程实现能重现数学形式的优雅。 |
| 30 Nivdc OP @GeruzoniAnsasu 我都不参与项目我推个屁，尽管伤透，反正和我也没关系。真搞垮了，我也是吃瓜。 你说得没错，不管怎么样，只要软件演化，就是在原有的基础上增加一大坨。 但是我们在这里讨论的是两个相似的系统，如何以最小的代价转化的问题。 「所谓的可逆计算」在这里提供的方案，是编写 delta 代码。 |
 | 31 peteretep Jan 12  这也太民科了数学上的等式变换是 完全无损耗的， 工程上的变换都是有有损耗的 |
| 32 Nivdc OP @GeruzoniAnsasu 尽管从抽象的视角来看，将“软件更新到下一个版本”和“给客户提供专用的版本”是完全等价的，但是实践上，“迭代软件的版本”和“定制开发功能”这是一回事吗？ |
 | 34 robinchia Jan 12 thinkphp 你在说我么？ |
| 35 Nivdc OP @newtype0092 不管作者是不是在故弄玄虚，这套理论还真让我悟出点东西。 尽管从表面看，它只是为大系统复用提供了一条新颖的解决思路，但是它真正闪烁的地方，是在元编程领域。 一旦我们接受了 delta 代码的概念，拆解、重构大型系统将变得轻而易举。 因为这将不再是解 P-NP 问题：「你可以轻松验证你能从一个复杂系统剥离出一个最小核心，但你无法快速找到解。」 而是变成了：「你可以轻松编写 delta 代码，步步裁剪，一点一点删减功能逼出复杂系统的最小核心」 尽管 delta 代码的概念在实践上未必成立，即使成立也可能会面临高抽象、难以理解的元编程难题。但是这个理论真正难能可贵的，是它给予了我们极大的勇气去面对复杂系统，这一点是很难得的。 |
Select Language