为什么不可变对象启用函数式编程？ [英] Why do immutable objects enable functional programming?

问题描述

我试图学习scala，但我无法理解这个概念。为什么使对象不可变有助于防止函数中的副作用。任何人都可以解释我喜欢我吗？

解决方案

有趣的问题，有点难以回答。 b

函数式编程非常关注如何使用数学来推理程序。要做到这一点，需要描述程序的形式主义，以及如何能够证明他们可能拥有的属性。

有许多计算模型提供了这样的形式，如lambda微积分和图灵机。而且它们之间有一定的等同性（参见这个问题，用于讨论）。

在一个非常真实的意义上，具有可变性和其他副作用的程序可以直接映射到功能程序。考虑这个例子：

  a = 0 
b = 1 
a = a + b 
  

以下是将它映射到功能程序的两种方法。首先， a 和 b 是状态的一部分，每行是从状态到一个新的状态：

  state1 =（a = 0，b =？）
 state2 =（a = state1。 a，b = 1）
 state3 =（a = state2.a + state2.b，b = state2.b）
  

下面是另一个例子，每个变量都与时间相关联：

 （a，t0）= 0 
（b，t1）= 1 
（a，t2）=（a，t0）+（b，t1）
  

那么，鉴于上述情况，为什么不使用可变性？

好吧，这里是关于数学的有趣的事情：形式主义是，它更容易做出证明。或者换句话说，对于易变性程序的推理太难了。

因此，关于可变性编程的概念几乎没有什么进展。着名的设计模式不是通过研究得出的，也没有任何数学支持。相反，它们是多年和多年反复试验的结果，其中一些已经证明是错误的。谁知道其他几十种设计模式随处可见？

与此同时，Haskell程序员想出了Functors，Monads，Co-monads，Zippers，Applicatives，Lenses ..几十个有数学依据的概念，最重要的是，代码是如何构成程序的实际模式。你可以用它来推理你的程序，提高可重用性并提高正确性。例如，请查看 Typeclassopedia 。

难怪不熟悉函数式编程的人会对这些东西感到有些害怕......相比之下，编程世界的其他部分仍然在使用几十年前的概念。新概念的概念是陌生的。不幸的是，所有这些模式，所有这些概念，只适用于他们正在使用的代码不包含可变性（或其他副作用）。如果是这样，那么它们的属性就不再有效了，你不能依赖它们。你回来猜测，测试和调试。

I'm trying to learn scala and I'm unable to grasp this concept. Why does making an object immutable help prevent side-effects in functions. Can anyone explain like I'm five?

解决方案

Interesting question, a bit difficult to answer.

Functional programming is very much about using mathematics to reason about programs. To do so, one needs a formalism that describe the programs and how one can make proofs about properties they might have.

There are many models of computation that provide such formalisms, such as lambda calculus and turing machines. And there's a certain degree of equivalency between them (see this question, for a discussion).

In a very real sense, programs with mutability and some other side effects have a direct mapping to functional program. Consider this example:

a = 0
b = 1
a = a + b

Here are two ways of mapping it to functional program. First one, a and b are part of a "state", and each line is a function from a state into a new state:

state1 = (a = 0, b = ?)
state2 = (a = state1.a, b = 1)
state3 = (a = state2.a + state2.b, b = state2.b)

Here's another, where each variable is associated with a time:

(a, t0) = 0
(b, t1) = 1
(a, t2) = (a, t0) + (b, t1)

So, given the above, why not use mutability?

Well, here's the interesting thing about math: the less powerful the formalism is, the easier it is to make proofs with it. Or, to put it in other words, it's too hard to reason about programs that have mutability.

As a consequence, there's very little advance regarding concepts in programming with mutability. The famous Design Patterns were not arrived at through study, nor do they have any mathematical backing. Instead, they are the result of years and years of trial and error, and some of them have since proved to be misguided. Who knows about the other dozens "design patterns" seen everywhere?

Meanwhile, Haskell programmers came up with Functors, Monads, Co-monads, Zippers, Applicatives, Lenses... dozens of concepts with mathematical backing and, most importantly, actual patterns of how code is composed to make up programs. Things you can use to reason about your program, increase reusability and improve correctness. Take a look at the Typeclassopedia for examples.

It's no wonder people not familiar with functional programming get a bit scared with this stuff... by comparison, the rest of the programming world is still working with a few decades-old concepts. The very idea of new concepts is alien.

Unfortunately, all these patterns, all these concepts, only apply with the code they are working with does not contain mutability (or other side effects). If it does, then their properties cease to be valid, and you can't rely on them. You are back to guessing, testing and debugging.

这篇关于为什么不可变对象启用函数式编程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！