muchan92

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