关注数据本身（这最终就是 的全部内容），而是关注函数。换句话说，我们专注于我们可以利用数据做的事情。 所以，这并不是关于蛋糕，而是关于我们制作蛋糕片的过程。你通过该函数传递什么样的蛋糕并不重要。只要数据具有某些属性，该函数就会产生预期的产品。 在函数式编程中，数据是不可变的，因为它不会改变。就像数学一样，每次我通过方程传递 2 时都会得到相同的结果。无论是两个苹果、蛋糕还是汽车，其实并不重要。而且，数字 2 永远不会改变，方程创造了新的东西，但 2 仍然存在。 那么，为什么函数式编程又卷土重来呢？ 早在 60 年代初，随着计算机的改进，它们可以解决的问题的复杂性也随之增加，但随着复杂性的增加，所需的代码也随之增加。检查一百行代码中是否存在错误是一回事，而必须梳理数百万行代码中是否缺少逗号则完全是另一回事。
为这个问题提供了一个解决方案。如果我们按照数据类型和我们对代码所做的事情来划分代码，那么我们就知道，当我们的那块蛋糕出现错误时，我们必须检查代码中处理蛋糕的部分。 所以在当时，OOP 是针对一个非常现实的问题的一个非常优雅的解决方案。但随着时 巴西手机号码数据 间的推移，它成为我们如何思考代码以及如何组织代码的标准。与任何标准一样，当您开始将其应用于所有事物时，接缝就会破裂。 一方面，用 OOP 术语思考需要抽象。例如，如果我想以 在一起，我必须创建一个名为 number 的类，其中数字 2 是一个实例，然后我们需要一个方法来将它添加两次。 这就是为什么像Ilya 这样的作者认为 与我们大脑的工作方式违反直觉。正如他雄辩地指出的那样，我们倾向于从我们所做的事情来思考世界：如果我饿了，我就会吃点东西，如果我想变得更健康，我就会散步。
因此，在某种程度上，我们更适应函数式编程如何表示问题的方式。 批评者提出的另一点是，OOP 成为了它试图消灭的怪物，随着程序变得越来越复杂，代码组织变得更加困难，尤其是对于长期项目。随着越来越多的类堆积起来，并且随着管道中对其方法进行越来越多的更改，出现问题的可能性呈指数级增加。 与 OOP 的动态本质相反，函数式编程的目标是稳定性，如果您需要做某件事，您可以编写一个函数来实现它，该函数将保持不变，直到您再次需要它。只要您向其传递正确类型的数据，它就会产生同样可靠的结果。 正如许多人很快指出的那样，函数式编程范式更具限制性，这是我们都同意的，但有时限制正是所需要的。正如苏兹达尔尼茨克简洁地指出的那样，糟糕的开发人员总是会编写糟糕的软件，但限制性框架将限制他们造成的损害。 理论上，通过将数据与功能解耦，我们创建了一个更可预测的环境，从长远来看更易于管理。