@newtype0092 不管作者是不是在故弄玄虚，这套理论还真让我悟出点东西。
尽管从表面看，它只是为大系统复用提供了一条新颖的解决思路，但是它真正闪烁的地方，是在元编程领域。

一旦我们接受了 delta 代码的概念，拆解、重构大型系统将变得轻而易举。

因为这将不再是解 P-NP 问题：「你可以轻松验证你能从一个复杂系统剥离出一个最小核心，但你无法快速找到解。」
而是变成了：「你可以轻松编写 delta 代码，步步裁剪，一点一点删减功能逼出复杂系统的最小核心」

尽管 delta 代码的概念在实践上未必成立，即使成立也可能会面临高抽象、难以理解的元编程难题。但是这个理论真正难能可贵的，是它给予了我们极大的勇气去面对复杂系统，这一点是很难得的。

@peteretep 我的错我的错，数学水平太差了，搞得看起来跟民科一样，真别纠结里面的等式了，我觉得它的概念还是很好理解的。

@GeruzoniAnsasu 尽管从抽象的视角来看，将“软件更新到下一个版本”和“给客户提供专用的版本”是完全等价的，但是实践上，“迭代软件的版本”和“定制开发功能”这是一回事吗？

@GeruzoniAnsasu 我都不参与项目我推个屁，尽管伤透，反正和我也没关系。真搞垮了，我也是吃瓜。

你说得没错，不管怎么样，只要软件演化，就是在原有的基础上增加一大坨。
但是我们在这里讨论的是两个相似的系统，如何以最小的代价转化的问题。

「所谓的可逆计算」在这里提供的方案，是编写 delta 代码。

@GeruzoniAnsasu 我可能有误解，但我感觉你陷入了一个误区，可逆计算理论不尝试解决一个系统版本更新迭代的问题，它尝试解决的是大系统复用的问题

@litchinn 所以，这里存在一条折中路径，删去原系统中的一小部分，替换掉需要替换的部分。现实世界就是需要这种妥协💦

@GeruzoniAnsasu 没写过。关键问题在于，如果 X 和 Y 的差异极小，用直觉来思考怎么会存在“大量非必要的代码”呢？

@hahiru 但是 APP 中你如何轻松剥离 CodeX 然后得到巧克力味的屎山呢？
答案很简单啊，不要合并 Code1 、Code2 到 App 里面，用一个元编程手法保持替换掉不就好了？

@ZGame 我觉得蛮现实的，你把每个有增有删的 commit 积起来看，最终就是你的 App 了...唉，就当我太笨吧，可能这辈子就这样了。

@ZGame 我觉得你说的和 @newtype0092 的质疑是比较相似的，那就姑且先抛开 Nop Platform 这个框架看，你觉得这个理论是不是有些有道理的地方呢？

@newtype0092 汗流浃背了😅

但是我觉得这里的关键不是万能代码库，而是你现在在开发的东西最终都会变成现实世界中某个领域的专属代码库，对吧？
如果现在出现了另一块与你的领域有重合但不完全相同的领域，需要你的代码。

那么Δ差量为我们展示了另一条路经，除了“抽出两块领域共有的东西”这个方法外，你还可以反向削减原有的代码库，使其符合当前的需求。


Nop Platform 那一套扩展确实非常可疑，我也没仔细看过。
XML+Java 实现的，这能靠谱吗（滑稽）


此外我还觉得即便这个范式能够得到推广，在实践中 Y=X+Δ 也很有可能存在一个临界点，取决于 Y 和 X 的差异程度，一旦Δ本身出现膨胀，这个范式需要退化到旧范式的路径上重组为 Y=C+ΔY ，X=C+ΔX 。

@newtype0092 我觉得你说的完全正确，那个天书文档真的有点难懂，感觉就是纯在卖弄概念😅
但是“软件演化来自Δ差量递进”，我觉得这个理念确实有其先进和独到之处

@ZGame 没有啊，我觉得很简单啊，就是在用组合范式的时候你可以减掉原有的功能，为系统级复用提供了解决方案。
要是解决问题的规模很小，这个范式不会起效的，甚至就是句废话，但是在大规模系统系统复用上，这个理论很有参考价值。

@newtype0092 可能是我说的这句“在数学上，它是成立的”这个判断确实是有问题的，造成了误解，非常抱歉

@newtype0092 你的质疑是极好的，因为我自己也非常怀疑这个玩意，但是我的水平太差了，可能没办法准确理解你的核心疑问。

所以我让 AI 帮我解读了一下，它是这么回答的：

这里有一个非常微妙、但决定性的错位：

你的真实意思是：
Δ 是一种 “工程差异的描述方式”
它是依附于 X 的补丁/遮罩/视图

而他说的“数学成立”理解成了：
Δ 是一种 “可独立存在、可组合、可逆的变换元素”
这两者完全不是一回事。

你心里想的是：
Δ 只在 (X → Y) 这个关系中有意义

而他以为你说的是：
Δ 是某种普适的变换算子

@zizon 我知道你可能对我采用的简单的加号+和减号-产生一种直觉上的误解，其实它和数学概念上的加减不是一回事，它代表着一种组合过程，理论的作者用了个更合理的合并符号'⊕'，我在这里只是出于介绍的目的将其简化了。

@zizon 我当然知道这里面的等式不严谨，但是这又不妨碍它的表达，纠结这个干啥😅
爱看严谨的？那你看作者的天书文档去。

里面有一段是 KIMI 写的，把这理论都吹上天了😅