让我们先从一个简单的事实开始——
我们都知道,最好的程序员能够做出最简洁、最小的抽象系统,让我们将其称之为P,
然后,差一些的程序员(比如我)会写一些附带功能来扩展这个系统,让我们将我的代码称之为Code,
我们可以将这个过程表述为:
App = P + Code
这个过程是很自然的,不是么?
OK ,既然我们都接受这个自然的过程,那么设想实际上存在一个逆过程不是也很自然吗?
假设这里有一个庞大、丑陋的巨型系统W,难道不该存在一种逆过程,将这个系统改进成一种更简洁的形态L吗?
就像这样:
W + inverse Δ = L
或是:
APP - Code = P
你可能没见过这个东西,但是在数学上,它是成立的。
现在,让我换一个视角继续解释这个理论。
假设你的公司开发了某个实用的大型系统,然后突然来了个客户看上了你的大型系统。
但是,你的公司的需求和客户公司的需求又不可能完全一致。
传统的做法是什么样的呢?
你可能将两个系统的共性剥离出来组成一个小型的核心系统,然后维护两套派生系统。
但是在可逆理论指导下,则完全没必要这么做,
你完全可以全心全意维护你公司主用的系统,然后编写 delta 代码来掩盖二者不兼容的部分。
假设:
X 是你的系统
Y 是顾客要求的系统
Δ 是两个系统之间不兼容的部分
注意Δ包含:
我们可以将其写为:
Y = 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
1
Nivdc OP 里面有一段是 KIMI 写的,把这理论都吹上天了😅
|
2
sillydaddy 5 小时 6 分钟前
感谢分享!很新奇的概念,回头看看。
|
3
zizon 4 小时 48 分钟前
要不先读读初等数论.
|
5
Nivdc OP @zizon 我知道你可能对我采用的简单的加号+和减号-产生一种直觉上的误解,其实它和数学概念上的加减不是一回事,它代表着一种组合过程,理论的作者用了个更合理的合并符号'⊕',我在这里只是出于介绍的目的将其简化了。
|
6
newtype0092 4 小时 14 分钟前
"你可能没见过这个东西,但是在数学上,它是成立的。"
我一个数学学渣都知道,你要把软件迭代这种多次变换压缩成一个 Δ,最起码得在一个线性空间里吧。。。 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 4 小时 0 分钟前 智商检测器,软件都是把复杂的东西搞简单,这个理论把简单的东西复杂化,抽象化
|
10
Nivdc OP @ZGame 没有啊,我觉得很简单啊,就是在用组合范式的时候你可以减掉原有的功能,为系统级复用提供了解决方案。
要是解决问题的规模很小,这个范式不会起效的,甚至就是句废话,但是在大规模系统系统复用上,这个理论很有参考价值。 |
11
newtype0092 3 小时 31 分钟前
@Nivdc #8 没有我就单纯探讨一下。。。
我刚才还好奇专门读了他的文档,说真的有点神棍了。 他前面提出了一点数学上的内容,但实际上是偷换在偷换概念。 数学的运算都是有严格定义域的,他是典型的把线代、机器学习那套最基础的 y = f(x) + d 的东西硬往不相关的软件开发领域套,甚至还放了个完全不知想表达什么的图。 这部分你随便找个机器学习课程看前 1 个小时就能能懂,没啥高深的。 而且后面的部分和前面的数学部分基本没啥关系,看起来就卖弄一些概念,把数学苦手的人先吓住,然后就随便忽悠了。。。 |
12
Nivdc OP @newtype0092 我觉得你说的完全正确,那个天书文档真的有点难懂,感觉就是纯在卖弄概念😅
但是“软件演化来自Δ差量递进”,我觉得这个理念确实有其先进和独到之处 |
13
newtype0092 3 小时 5 分钟前
@Nivdc #12 Δ差量这里我觉得他也在偷换
![]() 软件迭代是需要很多维度的输入的,设计编码测试等等,是需要实打实的工作量的,即使现在有 AI 了,微调、推理等工作量也是少不了的。 他想把这个东西往数学上去靠,把这个概念解释成一个可以按某种方式直接计算的东西(神奇 ⊕ 操作 )。数学概念上这个Δ可运算是因为有定义的规则和成熟的求解工具,计算器按按好了。 软件上要想达到这个效果就需要有一个规则能让我直接得到正确代码,而不用上面的工作的过程。 仔细想想这不是就是我们 (Ctrl+)CV 工程师的绝学么。。。 那现在的问题就是只要找到一个万能代码库,未来所有功能直接从里面 copy 出来就行了,要修改什么功能直接增删对应的代码。 那现在这个代码库从哪来呢?网上先搜代码也肯定覆盖不了所有需求。 所以就可以把新功能限制在指定的框架范围内,把支持的功能全部整理成模版。。。 然后就有种越想越熟悉的感觉,你懂吧 ![]() |
14
ZGame 2 小时 57 分钟前
@Nivdc #10 看起来是一套框架, 你怎么证明他不是弄了一套 App=f(a,b,c,d,e,f,g....) ,让程序员去按照他的逻辑去填参数呢。 App=f(a)+g(b)+v(c) 这样是不是更简单点呢?
|
15
dhb233 2 小时 43 分钟前
什么?你把屎山解决了?
|
16
nutting 2 小时 42 分钟前
看起来像是共产主义宣言
|
17
Nivdc OP @newtype0092 汗流浃背了😅
但是我觉得这里的关键不是万能代码库,而是你现在在开发的东西最终都会变成现实世界中某个领域的专属代码库,对吧? 如果现在出现了另一块与你的领域有重合但不完全相同的领域,需要你的代码。 那么Δ差量为我们展示了另一条路经,除了“抽出两块领域共有的东西”这个方法外,你还可以反向削减原有的代码库,使其符合当前的需求。 Nop Platform 那一套扩展确实非常可疑,我也没仔细看过。 XML+Java 实现的,这能靠谱吗(滑稽) 此外我还觉得即便这个范式能够得到推广,在实践中 Y=X+Δ 也很有可能存在一个临界点,取决于 Y 和 X 的差异程度,一旦Δ本身出现膨胀,这个范式需要退化到旧范式的路径上重组为 Y=C+ΔY ,X=C+ΔX 。 |
18
momocraft 2 小时 36 分钟前
2 年前在知乎看过了
在实用案例出现前被我归类为民科 |
19
Nivdc OP @ZGame 我觉得你说的和 @newtype0092 的质疑是比较相似的,那就姑且先抛开 Nop Platform 这个框架看,你觉得这个理论是不是有些有道理的地方呢?
|
21
hahiru 1 小时 21 分钟前
APP - Code = P
APP - P = Code 但是程序能这么操作吗?程序和数学并不完全能类推。 Code 是在 P 的基础上写的。也许 Code2 是在 Code1 的基础上写的。 最后的屎山叫 APP 但是 APP 中你如何轻松剥离 CodeX 然后得到巧克力味的屎山呢? 话说也许以后 AI 超牛逼了全 AI 自己写,全规范全流程。但是目前来看人类不适合这种模式。 |
22
GeruzoniAnsasu 1 小时 15 分钟前
Δ不遵循交换律和结合率。
所以 X+ΔY 不等价于 X-(-ΔY)。 实际情况不可能是从 X 里「删减」得到 Y ,而是必须引入了大量的适配层,「增加」大量非必要的代码才能得到 Y 。 OP 没写过版本迁移适配代码吗? |
23
litchinn 1 小时 7 分钟前
这不典型的 P-NP 问题吗,你可以轻松验证你能从一个复杂系统剥离出一个最小核心,但你无法快速找到解
|
25
Nivdc OP @hahiru 但是 APP 中你如何轻松剥离 CodeX 然后得到巧克力味的屎山呢?
答案很简单啊,不要合并 Code1 、Code2 到 App 里面,用一个元编程手法保持替换掉不就好了? |
26
Nivdc OP @GeruzoniAnsasu 没写过。关键问题在于,如果 X 和 Y 的差异极小,用直觉来思考怎么会存在“大量非必要的代码”呢?
|
28
Nivdc OP @GeruzoniAnsasu 我可能有误解,但我感觉你陷入了一个误区,可逆计算理论不尝试解决一个系统版本更新迭代的问题,它尝试解决的是大系统复用的问题
|
29
GeruzoniAnsasu 16 分钟前
@Nivdc 推广就直说。 现在大家的评论之所以停留在逻辑层面是想尽可能不误伤涉及的项目,万一真仔细看了项目到时候可能就要开喷了。
另「系统版本」原本应该是个 Abastraction. 任何迭代都会发生版本变更,你可以声称某个理论「不解决版本号第一位数字增加了 1 的情况」,只解决「系统开发过程的演变的问题」。但从抽象上来看这两者完全等价。 之所以要问有没有写过跨版本适配代码,因为这是最容易理解「所谓的可逆计算」的范式: 你在现有 migration 的基础上增加一些 migration ,在现有的 service 结构上增加一些 adaptor ,可能是新适配旧也可能是旧适配新 —— 但无怎样它们在软件工程/真实世界的表现形式都只会是「增加一大坨本可以(如果不保持兼容性的话)不要的代码和层」。 数学上等价于一个工程实现完全不代表工程实现能重现数学形式的优雅。 |
30
Nivdc OP @GeruzoniAnsasu 我都不参与项目我推个屁,尽管伤透,反正和我也没关系。真搞垮了,我也是吃瓜。
你说得没错,不管怎么样,只要软件演化,就是在原有的基础上增加一大坨。 但是我们在这里讨论的是两个相似的系统,如何以最小的代价转化的问题。 「所谓的可逆计算」在这里提供的方案,是编写 delta 代码。 |
31
peteretep 4 分钟前
|
32
Nivdc OP @GeruzoniAnsasu 尽管从抽象的视角来看,将“软件更新到下一个版本”和“给客户提供专用的版本”是完全等价的,但是实践上,“迭代软件的版本”和“定制开发功能”这是一回事吗?
|
34
robinchina 几秒前
thinkphp 你在说我么?
|