@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 位。

@villivateur 是 Hardware Description Language 吗？挺好玩，有意思。

@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 的味道。规则是对结构的自洽描述，如：引力。