@zxyangyu 啊哈，果然提到 `三体` 问题了，如果是的话，则用什么都不咋好使，如果不算作 `三体`，那么就是普通两者间的引力。

关于函数式编程前排提及过，从根本上是过程式编程，是手动驱动数据，另外由于异步或副作用的存在，往往难以写出纯函数。对于纯函数，是具有函数式编程优点的，但是并不总能实现。

另外对于有些朋友解读为数据驱动，可能那样认知成本更低，但是不建议那么认为，因为容易忽略掉结构化的层级和关联，还有一个显著的区分特点为：是主动驱动数据，还是根据数据的准备情况自动执行。这也用来区分是过程式编程还是数据结构化编程；也是影响程序读写难度的核心。

对于过程式编程，由于逻辑过程的本质复杂，没有好的手段可以大幅降低开发难度。
数据结构化编程，无论是从思维上，还是写法上，又或是生态工具上，都有潜力大幅降低开发难度，并且还有许多潜力等待发现。
以文中的 `安全` 部分举例（也可以参见 github ），任何数据流动都会进行完备校验，而不必像在过程式中，每次都得自己手动进行校验（甚至大多人都不校验）等等。

@frandy 如果把**规则**误解为是对象的方法，那么就会产生面向对象的误解。
我们先不要把视角放在结构规则与对象方法的定义写法上面，忽略写法的相似性。
我们先把视角放在两者最终是如何使用的，看一下显著差别。

面向对象编程中，最终的调用是由程序员**主动**调用一个或多个对象的方法（或一系列方法），由程序员自己一步步推动 input data 经过一系列逻辑或方法，最终得到 output data 。

数据结构化编程中，最终会是一个像配置文件的入口，只需要把待赋值的 input 字段赋值好就行，不用关心顺序，不用关心层级，只要所有预期的 input 字段都准备好了，那么程序会**被动**自动执行，产生 output data 。

这能看出，面向对象或面向过程的编程，都是需要用力在 data 背后主动推动其进行流动，数据流向只能通过深入阅读细节源码才能知晓，这也是难以维护的重要原因。
数据结构化编程，则并不用费力气去推动 data，而是变成了仅提供 data，只要该有的都有了，那么就会自动执行。其数据流向是可以通过数据结构来进行阅读，并不需要深入逻辑源码；并且正如文中 `结构化编程的好处` 提到的，可以用工具，以可视化的图形方式，展示出整个程序的所有结构之间的流向图等等；额外的，如果编写有误，也可以直接显示出来等等。

还是用文中的举例，结构化编程讲究的是**自洽**，就像是为太阳、地球定义引力的规则，然后把它们随便扔到任何空间中，它们总会按照引力的规则开始旋转。而过程式编程就需要由神出手，精确摆好太阳和地球的位置，然后再用手费力的在后面推动其进行旋转。

若你细品的话，在规则的定义方面，有些 DDD 的味道。规则是对结构的自洽描述，如：引力。

@felixcode 只是想写一篇导读，如果不可以的话，那就让这篇下沉吧，抱歉

@lap510200 有什么具体的想法，直接表述出来就好，像现在这么说，我实在没法回答。
有什么想法，随意提问，我们之所以在这，不就是为了讨论，探讨么，在探讨的过程中，我们才能更好的一步步消去迷雾，获得明白，探讨过程本身也是很有意思、很有意义的不是么。

@Exin 最重要的可能是我已经在探索该观念的历程中（比文中所述更详尽，更原始），已经渐渐熟悉并转变自己的思维了，所以表达的时候是以一个潜意识已经接受者的角度去落笔，对于这个观念几乎没有任何思想准备的朋友们而言，思维跨度太大，我较难表述，大家也较难接受。

所以我觉得，大家可以就从没有思想准备的视角下，提出见解来。
我们可以多多探讨，多多交流，把你的想法都表述出来，大家也把想法都表述出来，看看哪个思考节点较难理解，哪个节点会有疑惑，哪个节点会有不同见解，等等，这样也有助于我对错误的更正，也有助于大家对该观念的认知和了解，在互相探讨的过程中，我们能够更清晰明白的接受或发现更精彩的新想法。

@taowen 同时，明确的声明预期条件，也就明确的描述了数据的流向，可以让其他人清晰的理清数据流向。

@taowen 你所说的类似，是响应式上看起来相似，当数据发生变化时触发钩子。

单纯从代码层面上讲，两者的两个主要区别是：
* vue 3 是在 effect 里隐式追踪依赖，rainforest-js 是要求明确指定依赖。
* vue 3 里的子结构依赖需要由程序员自己保证父结构不为空，rainforest-js 里是仅声明需要的目标依赖，无需关心父结构是否为空（遵循结构化的思维）。

从思维方式和代码编写层面上讲，vue 3 是过程式编程，由作者的逻辑主动驱动数据，rainforest-js 是定义明确的预期规则，然后将该准备的数据都准备好，规则会被动的自动执行，一切是可以预期的。

@taowen 原作者的想法很有意思，不过却是唯心主义的表达。
人类作为会思考的动物，在对于 `概念` 性问题上，由于个体或群体的思维差异，可能会有不同的解读，比如，对于水果的名称，可以用中文 苹果，也可以用英文 Apple 。
而一旦对于真实的 `物质` 性问题上，却会完美的达成一致，比如，对于水果的数量，没有就是 `0` 或 `零` 或 `zero`，一个就是 `1` 或 `一` 或 `one`。
同样的，唯物主义在基于自洽、规则恒定的前提下，也不否认多样性，比如，光速是恒定的，但是在不同的传播介质中其速度是并不相同的，但在每种介质中速度都是恒定的，这是规则，这是我们的这个世界的物质规则。
也依然如此，人类有中文、英文等种种语言，但它们的规则也是恒定的——用来沟通。

所以，过程式代码之所以较难阅读，是因为我们阅读的作者的思维，不同的作者有不同的方式来 `驱动` 数据，总之最终给出一个大家都认可的结果。
而结构化思维却能将作者拉回到数据结构（物质）本身的规则上来，能够很大程度上达成规则的统一，可能依然有多样性，但也只不过是物质规则的描述并不完全而已。

@jheroy 函数式编程根本上是逻辑过程的拆分、封装、演进，粒度不同。
以逻辑为主的编程方式就像是：Hey, 都精神点，跟着本人的思路认真听讲了，不然走神儿就非得晕了不可。
以数据结构为主的编程方式就像是：来来来，我带你们看看我们的工厂，这些工厂把原材料进行加工产出成品，形成一个产业链。
由于数据结构的自洽性，预期的确定性，就像是甲方提出需求由乙方提供结果，程序员将精力注重于可信的、可以预期的输入和输出，而不必按步走完逻辑流程才能知晓结果。同时结构化也能有更好的可视化数据流向。

@jheroy 数据结构化编程，不是 `逻辑` 结构化编程