@muchan92 程序员也要用户体验啊，你这几行代码搞定的是写起来那么复杂，谁用啊。

@visper 解释过了在 #53

@muchan92 #53 我们要解决的问题是维护程序的正确性. 大部分现代程序采用的方式是上 unit test, regression test, 上静态分析 另一条路是写出符合某 specification 的代码, 即 formal verification, 也是你实际上在做的路子. 这是 cs 中 pl 领域的很大一块, low hanging fruit 基本不存在了. 想入门这块可以从 Software Founditions 和 PLFA 看起. 所以 #1 说你是计算机民科是毫不夸张的.

我觉得你这玩意的终点是 FLUX 架构:单项数据流,声明式编程

看了一下你这个项目，似乎是受到 vue 观察机制或者 rxjs 的启发，相当于一个完全使用响应式数据流驱动的概念，但问题是我直接写 vue 全用计算属性，或者直接使用 angular 不好吗？而且你得思考一个问题，所有业务都适合响应式数据流吗？我以前用 angular 时思考过这个问题，个人认为大多数业务不需要使用数据流来处理。

@fregie 这东西在大型项目中确实很好,稳定性好便于维护,代价是提高理解成本和编码量

我怎么就想不到这种水贴的方式啊，难怪我的币还是这么少。

而且你这个所谓“乱序”也就是声明式数据流，复杂度一旦高起来调试会非常困难，我写过数据处理流程相当复杂的 android 项目，完全使用 kotlin Coroutines/Flow ，并且存在一些过度使用 flow 的情况，你知道对复杂的数据流进行调试和不小心搞出来的数据流循环的调试有多麻烦吗？

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

类似 Mobx 把 React/Vue 的 响应式 带到 写逻辑中。 一种发布订阅模型的应用