@IndexOutOfBounds 解释的可以。它是通用编程，没有场景限制，非要说的话，就是写小一点的项目或脚本用命令式方法更简单，中大一些的项目我就会用这种声明式写法。

@kome @yxc246800 我从未全盘否认顺序，正文说了顺序适合于计算过程，我当然承认它的地位。但它并非没有缺点，如 #41 #68 所述，按命令式方法，除了重构代码，是否还会有更好解决办法。

@Ketteiron 要写测试很容易，因为它就是一个数据结构，你赋值了某个属性，然后去测试数据是否正确即可，仅此而已。

@gaobing 没人逼你非得乱序写代码 A Y X ，你依然可以顺序写 X Y A ，它只是说可以这么写而已。另外，你这样占楼...

@docx 实际上 debug 没有想象中那么难，因为若一个值是错误的话，那么它不会传播很远，可能下一个就定位到了。所以，错误不会如想象中那般，传播得非常遥远。

@cenbiq 你的几个举例，并非完全“声明式”，它们调试难度就是为了抵消“非完全声明式“所引入的额外难度。递归和循环问题我都遇到过，程序会第一时间指出该问题，不会隐瞒。

@OneLiteCore 首先抱歉，我不应该用“错误”而改用“错觉”更合适，后面一条回复就使用了“错觉”。
其次，你所讲的是业务需求的本质复杂性，它不会被消除，但使用命令式写法会引入更多的非本质复杂性。正如 #41 举例，若按照命令式写法，你首先得在计算 A 之前，先计算出新的 Z ，而 Z 有可能是异步的，所以不得不重新打乱之前已有的同步计算 A 的过程，重构代码。而这种方式则不会，修改局部即只作用于局部。程序维护一次和维护一百次时维护难度是相同的。

@visper 解释过了在 #53

@rb6221 我一直在耐心理性解释的吧，从未怼人，哪里有讲过“你不懂，但是我懒得跟你解释，懂的人自然会懂”之类的言论。

@cocong 首先作为库，并且在实际应用中证明这种方案的可行性，远比直接搞一套语言更实际。
@cmos @roykingH 前面解释过，这并非解决乱序执行问题。关于可读、可写、可维护性见 #41

@msg7086 @xtreme1 感觉相似是在声明式和依赖关系，区别在于 Haskell/Coq/Agda 是静态一次性计算，不会动态持续更新。据我目前所知，最接近的是 Excel 。
@xtreme1 另外，我没碰想瓷任何东西，我承认会有认知局限，感谢你让我了解了 Coq/Agda ，但你若说“碰瓷”Excel/VisiCalc 可能更接近。

@Tink 有示例在 #30

@340244120w 你认为这会抬高编程门槛？相反这其实会降低编程门槛。我们十几个项目都工作良好，稳定可靠。

传统思维会认为，在没有完全弄懂程序的所有细节之前是不可能正确修改代码的，因为每一行代码都堆叠在前面的代码之上，移动一点儿都可能崩塌。

但这种方式不会。你完全不必了解全部规则，也能放心大胆地修改代码，不会出错。为什么呢？举例说明，假设需求变了，要把程序改为 A = X + Z 。你有两个选择：
一、你开心时，可以找到 A = X + Y 的地方把 Y 换为 Z 就好了；
二、你不开心时，忘掉之前的 A = X + Y ，管那么多干啥，直接新写一个规则 A = X + Z 把之前所有关于 A 的覆盖掉就好了。

现在你不必了解全局也可以放心大胆地写代码了。
因为每一个规则，只关注依赖的变量，但不必关心被依赖的变量在哪儿、何时准备好，仅仅把自己计算正确就行了。当然，被依赖的变量也是如此计算的。

所以，从方法二可以看出，即使程序迭代了上百次，你也可以完全忽略已有规则，就当它们都不存在，所有变量都是新的，大不了就把新需求从头写一下而已。

@forisra 请问你解决数学问题时是用“算术方法”还是“方程方法”？难道命令式编程不是把业务需求改写为算术过程吗？

@shyling 有没有可能我们是被“命令式的机器执行思维”限制了原本更人性化的“方程式思维“。

@lqs
@maigebaoer
对啦，终于有人看懂了。它很像 Excel ，但可以用作通用编程，简单、可靠、稳定。

@liuchenx 有示例 https://github.com/rainforesters/imsure-demo ，按照惯性思维，你可能会觉得难看懂，但要实现相同功能，按传统方式来写代码肯定会复杂得多。你最好先忘掉规则，只把数据结构当做一个普通对象，读写任何属性都是正确的。然后再去看，规则是如何保证属性始终保持正确性的。

@Ketteiron 思维惯性的阻力，你若看 prolog 的话会更晕。和上条回复一样，错觉以为这会导致更难 debug ，实际上你几乎不需要 debug 。因为，若定义一条规则把取值范围从 64 位收窄为 16 位，那么它一定会收窄为 16 位，这是确定的肯定不会出错。同理，假设有多条业务规则作用于一个变量上，那么它也是取值收窄的过程，并且每次都是确定的不会出错，由此推及整个程序也是确定的。所以，实际上很少需要 debug 。

@OneLiteCore 为什么会错误的以为这会更难维护？实际上这更容易维护。你以为你需要弄懂所有的规则才能写代码、改代码？并非如此，你甚至不需要感知它之前是否有规则，你只需要描述你的规则就好了。就像类型约束一样，假设一个类型为 int64 的变量，它的取值范围从无规则时 64 位，到规则 1 约束 32 位，再到规则 2 约束 16 位。