@moudy 我学过，但它们解决的问题并不一样。

@vfs 使用声明式写法，用规则来描述业务逻辑。就像写方程式一样，业务逻辑直接映射为规则，不需要推导，它会自动按正确顺序执行。即使需求变更，也只是调整下规则的依赖关系而已，简单可靠，不会涉及到推翻脆弱的代码顺序。

这是解决数学或乱序执行问题吗？请先搞清楚再说好吧。

@w568w 呵呵

我现在可以。
设计的误区是扩展性，即使有充足的时间，但需求的奇葩性总会击穿原以为良好的扩展性，因为代码设计就像刚性结构的建筑，每一行代码都是堆砌的砖块，后面的代码堆砌在前面的代码上，但没人能保证前面的代码永远不会移动。所以扩展性仅能支持很小的形变，但需求却可能会 180 度转弯。
所以与其谈论扩展性不如谈论稳定性。假设需求非常多变，找到一种能够始终保证稳定性的方案即是出路。

牛啊，支持

@OneLiteCore 经济发展不是探讨的主题，但它是企业技术革新的内驱动力，忽略不掉所以捎带提一句。
挖矿/AI 不可否认地促进了硬件发展，因为软件对硬件的胃口越来越大，而手机上的软件胃口变差的话肯定会导致硬件发展趋缓，我不推崇软件负优化，只是很多时候没必要过度优化，差不多就行，开发者也不太累，硬件也够用。

@FalconD 不缺，认真的，只有紧平衡才会促进技术和经济发展，否则资源过剩是没有需求的企业也没有动力去发展，客观事实经常反常规思维

修什么仙，问什么道啊

@ZiChun 本不想评论，但既然都在说递归，那么就简单解释一下吧，禁用递归是刻意为之，而不是不能实现，允许递归其实更容易实现。那么禁用递归的主要原因是：1. 在没有状态机堆栈结构的前提下，是难以实现尾递归的，那么就有可能导致宿主语言堆栈溢出，是有可能而不是必定； 2. 禁用递归采用变通方式不会影响代码功能，反而能让开发者明确知晓此处会产生递归，能有效防止意外情况，权衡之后因而采用。关于后面两个例子，dijkstra 是算法问题，函数更实用，不必强用这种写法来实现，这种写法更适合解决实际中的业务内容。rollback 就更简单了，字段状态重设就好了。

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