muchan92

我现在可以。
设计的误区是扩展性，即使有充足的时间，但需求的奇葩性总会击穿原以为良好的扩展性，因为代码设计就像刚性结构的建筑，每一行代码都是堆砌的砖块，后面的代码堆砌在前面的代码上，但没人能保证前面的代码永远不会移动。所以扩展性仅能支持很小的形变，但需求却可能会 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 只是想写一篇导读，如果不可以的话，那就让这篇下沉吧，抱歉