这会不会引起编程范式的变革？
计算机从最初为了解决计算问题慢慢演进到现在主要解决软件工程问题，即逻辑问题，但我们能操控计算机的工具（语言、范式）依然停留在为解决计算问题而设计的阶段，在面对逻辑问题时由于这种工具与问题的不匹配衍生了《人月神话》里所说的偶然复杂性，就像用勺子砍树，虽然能勉强做到，但非常难用，而我们却从未质疑过工具是不是本来就用错了，荒谬至极。
从另外一个角度来说，计算机之所以叫"计算机"是因为它最初为了解决计算问题，而现在主要为了解决逻辑问题，那么它应该叫"逻辑机"或"逻辑/计算机"，也应该配有解决逻辑问题的工具才对。
这就不得不剖析"计算"与"逻辑"的区别：
- 计算是步骤、指令，是过程性的，它描述的是一系列在时间上依次发生的动作
- 逻辑是规则、关系，是声明性的，它描述的是概念之间永恒成立的关系或约束
所以这就解释了现有的操控工具为什么适合计算问题，而不适合逻辑问题。需要创造一种新的工具来解决逻辑问题，并且它的特点一定是声明性的。
就像为了解决计算问题而创造的指令一样，解决逻辑问题也需要把逻辑拆解为最小单元并找到表达方式。因为现有编程语言的指令是解决计算问题的工具，而我们不可能从工具中找到逻辑的最小单元，所以就得忘掉这些，跳出这些，从底层状态机视角去拆解就能得到：
- 逻辑是一系列状态转移节点所组成的路径
- 计算是每个状态转移节点的内部转换过程
继续拆解出逻辑的最小单元就是最小化的"状态转移节点"，描述从上一个状态到下一个状态的转移。而"状态"在程序中表达为"变量"，所以这个逻辑最小单元的表达方式就是：描述从上一个变量到下一个变量的转移，即数据转换。
但这个"数据转换"概念在计算与逻辑的视角却截然不同：
- 计算关注的是实际的转换过程，它得等到前面变量传过来之后才开始运行
- 逻辑关注的是抽象的转换方向，它不关心前后变量是否存在，只需要描述好方向就行
所以解决逻辑问题的工具就是：设计一种既可以描述转换方向又无关变量是否存在的新写法。
于是就有了这种新编程范式：通过声明式写法把业务逻辑简化为描述数据之间的转换关系。构成简单、稳定、可靠的球状关系网，让程序从刚性结构变为柔性，砸不坏摔不烂，易于维护。
这种范式不仅几乎消除了偶然复杂性还解决了一个以前无解的难题，即使业务逻辑发生变化或规模增长，修改难度也是恒定的，不像传统命令范式会随着规模增长修改难度暴涨。打个比方，使用命令范式编程就像盖楼，每个砖块就是指令，当修改时移动任何一块砖都可能导致崩塌，因为它是顺序向上积累的；而新范式描述的是抽象的关系网，修改只是调整指向关系而已，无关顺序，稳定可靠。（正好救赎不可靠的 AI ）
最后总结，其实这代表了一种网状结构的自动状态机，或许是/或贴近程序的最简单形态。