编程就是压缩-技术圈

Programming is Compression

业务需求会不断扔各种案例过来，这样的情况下，应该怎样怎样。编程的过程就是把各种各样的具体case进行压缩表达的过程。除了需求，各种 bug report 也是输入。

首先我们来看一下目标函数的问题

静态压缩 v.s. 泛化能力

Static Compression v.s. Generalization Ability

static compression 的目标：给定所有的当前需求，最小化整体的实现代码量。方法就是能复用就复用，不能简单的复用的，创造条件也要强行复用。

generalization ability 的目标：给定过去的需求，进行合理的预测，最小化迁移到未来可能的新需求的成本。其实现手段就是保持代码整洁，有结构。但是问题在于什么叫“有结构”很难学习。相反，最小化整体的实现代码量是一个更容易销售，也更容易学习的目标。

《业务逻辑拆分模式》所描述的“主板+插件”的结构，就是给“有结构”提供一个易于学习的目标函数。在给定如下条件的前提下：

主板不反向依赖插件
插件之间不互相编译期依赖，运行时依赖必须通过主板开 SPI 来实现数据互通
实现了业务的需求
用户体验的一致性

这些条件都满足之后，让“主板的代码行数”越少，就是越好。

这里“合理的预测”似乎和不要预先设计是矛盾的。然而所有的“泛化”都是某种预测。整洁有结构的代码“赌”的是什么呢？赌的就是新需求大概率是 localized 的。

规律性 v.s. 特异性

Regularity v.s. Specificity

压缩的前提是对象本身具有内在的规律性。压缩的过程就是把规律性的部分和特异性的部分分离出来。这个也就体现在了各种“中台”，“低代码”，“DSL”的说辞之中，所谓一部分人搞定 80%，剩下的领域专家（也就是处理特异性的人）去搞定特异性的 20%。

然而这里的前提是处理 20% 的人要先知道之前的工序做了哪部分的 80%，才能知道自己要做哪 20%。wetware 相比 hardware 就是自然进化的速度太慢，千兆网，万兆网，升级速度杠杠的。但是人与人的沟通还是要靠非常低效率的文字理解和声波通信。

无论这 20% 怎么补齐，是 DSL 传参也好，是给生成的代码打个补丁也好。只要代码量比较大，和那 80% 部分的沟通就会越多。除非需求内在的 Regularity 非常强，可以用极其少量的参数组合已有功能来表达新需求，否则大概率写这 20% 代码的人会非常痛苦。这也是为什么“低代码”无法流行的根本原因。

机器学习

一部分人处理 Regularity，一部分人处理 Specificity：这就是所谓“中台”，“低代码”，“DSL”。核心是 specificity 部分要足够小，才能弥补沟通成本。

人类来提供 Regularity，机器处理 Specificity：一开始是 logical programming，人类要提供非常多的 regularity。后来是 probabilistic programming，人类需要提供 generating function 来编码专家经验到概率分布里。到后来 deep neural network，人类需要用 convolution filter 来用所谓 inductive bias 的方式 encourage 神经网络往某个方向学习

hinton 提出的 capsule network 的理想就是能把人类提供的 inductive bias 最小化，只提供

recursive：这个世界是层次化组织的，迭代的
part-whole：一个child仅从属于一个parent

然后来机器去自监督学习到剩余的部分。但是要把“这个世界是层次化组织的”这样的 regularity 表达出来是及其困难的。

CNN 本身是一层堆一层的，但是其学习到的特征并非如人所愿那么层次化。CNN堆了96层，也未必就能确定96层的 part-whole 就是足够了的。
Autoencoder 号称要搞个 bottleneck，就是要把 bottleneck 体现为中间 layer 的参数数量要更少一点上。这样的表达太“直白”了，效果并不好。GAN 等一众后续就是把这个 bottleneck 的参数限制给去掉了。

朴素直白地拿 architecture 的几何形状表达 inductive bias 是不 work 的。AGI 所需的 inductive bias 不太可能那么快被找到表达的方式。即便找到了，也未必能在当前的硬件下展示其威力而被 bechmarker 们所忽略。

所以更可能的情况是让人类来表达“规律性”，所谓专家经验。然后由机器来处理“特异性”。probabilistic programming 这样的人机混合的编程方式会得到更广泛的应用。越来越多的程序员会从直接编码规则来驾驭机器，变成“声明式编程”。把规律性的部分提取成 what，让机器去找到 how。

点击”阅读原文“，访问《业务逻辑拆分模式》电子书 https://autonomy.design