让我们先从一个简单的事实开始——
我们都知道，最好的程序员能够做出最简洁、最小的抽象系统，让我们将其称之为P，
然后，差一些的程序员（比如我）会写一些附带功能来扩展这个系统，让我们将我的代码称之为Code,
我们可以将这个过程表述为：

    App = P + Code

这个过程是很自然的，不是么？
OK ，既然我们都接受这个自然的过程，那么设想实际上存在一个逆过程不是也很自然吗？

假设这里有一个庞大、丑陋的巨型系统W，难道不该存在一种逆过程，将这个系统改进成一种更简洁的形态L吗？
就像这样：

    W + inverse Δ = L

或是：

    App - Code = P

你可能没见过这个东西，但是在数学上，它是成立的。


现在，让我换一个视角继续解释这个理论。

假设你的公司开发了某个实用的大型系统，然后突然来了个客户看上了你的大型系统。
但是，你的公司的需求和客户公司的需求又不可能完全一致。

传统的做法是什么样的呢？
你可能将两个系统的共性剥离出来组成一个小型的核心系统，然后维护两套派生系统。

但是在可逆理论指导下，则完全没必要这么做，
你完全可以全心全意维护你公司主用的系统，然后编写 delta 代码来掩盖二者不兼容的部分。

假设：

注意Δ包含：

  1. 客户要求 增加 的功能，以及
  2. 客户要求 减少 的功能，这个要求可能不是显式要求，而是他不需要。

我们可以将其写为：

    Y = X + Δ

关键点在于：


让我们再用官方文档中的一个例子来比较一下这个范式的特点：

    面向对象: 不等式 A > B
    组件:    加法   A = B + C
    可逆计算：差量   Y = X + ΔY

我觉得你可以注意到，可逆计算是组合范式的一个扩展，它引入了一个非常有趣的删减原语。

传统组件复用是“相同才能复用”，它把口号翻转成“相关就能复用”；
只要两个系统能写成 X 与 X+Δ，就能零修改地共用 X。

等于把“封装必须稳定”变成了“演化可以破坏封装”，彻底掀掉面向对象给系统级复用盖的天花板。


说来也巧，我觉得我们实际上早就遇到过这个理念一次，在 JavaScript 的原型链继承特性上。
只不过可逆计算理论把它往外推，延伸到了整个项目工程的范围。

目前我还看不出这个理论能够带来什么实践上的颠覆，但是它提供的思想是很具备启发性的。

想想看这个点子——你编写代码来删减功能，多有趣啊。


这个理论的作者目前正在制作一个基于该理论（及其延伸理论）的低代码平台——Nop Platform
这个项目的官方口号是：

App = Delta x-extends Generator<DSL>

不过这些个延伸理论有点太复杂了，我也不是很懂，你想了解的话可以读一下它的文档。

官方介绍：
可逆计算：下一代软件构造理论

项目仓库：
Gitee: https://gitee.com/canonical-entropy/nop-entropy
GitHub: https://github.com/entropy-cloud/nop-entropy

我不断收到关于本文中的数学公式不严谨、概念判断有谬误的讨论。
在此我诚恳接受大家的批评，我的本意是运用大家对于数学计算的直观理解，快速建立起对可逆计算理论的印象。
现在看，这么做过于鲁莽和草率。

你要是不喜欢我的表达方式，你可以把文本喂给AI，让它换一种你喜欢的方式说。
就哪怕你在提示词里加上：“给我分析一下这垃圾有什么价值”，我都不会在乎半点。

我写这个帖子的目的是分享一下这个理念，顺便也想知道它的核心概念：
「系统不必拆分，也能继续演化」

是否存在实质性错误？

我本人和该理论的作者没有任何关系，也未参与关联项目 Nop Platform 的运作。
在此贴出链接只是出于对原作者的尊重。

所以，你要是真的有货，就亮出来；
尽管亮剑，尽情亮剑。

真把项目搞垮搞黄了和我也没有半毛钱关系，我也是吃瓜的。


现在想来，这个理念之所以让我印象深刻，是因为它揭示了一些我们早已习以为常却从未意识到其存在的东西：

「所谓“编程”，不正是从“现实”这个混乱庞大的系统中，抽出一些简洁漂亮的东西吗？」

现在，我要问你：「是什么阻止了我们，对已有系统再做一次同样的抽象？」