Functional programming avoids state and emphasizes functionality. There's never any such thing as no state, though the state might actually be something that's immutable or baked into the architecture of what you're working with. Consider the difference between a static web server that just loads up files off the filesystem versus a program that implements a Rubik's cube. The former is going to be implemented in terms of functions designed to turn a request into a file path request into a response from the contents of that file. Virtually no state is needed beyond a tiny bit of configuration (the filesystem 'state' is really outside the scope of the program. The program works the same way regardless of what state the files are in). In the latter though, you need to model the cube and your program implementation of how operations on that cube change its state.

我觉得这里有点误会。纯函数式程序有状态。不同之处在于该状态是如何建模的。在纯函数式编程中，状态是由接受某个状态并返回下一个状态的函数操作的。然后通过将状态传递给纯函数序列来实现状态排序。

甚至全局可变状态也可以这样建模。例如，在Haskell中，程序是一个从World到World的函数。也就是说，你传入整个宇宙，程序返回一个新的宇宙。但是，在实践中，您只需要传入您的程序实际感兴趣的部分。程序实际上返回一系列动作，作为程序运行的操作环境的指令。

您希望从命令式编程的角度对此进行解释。好的，让我们看一些用函数式语言编写的非常简单的命令式编程。

考虑下面的代码:

int x = 1;
int y = x + 1;
x = x + y;
return x;

相当标准的命令式代码。没有做什么有趣的事情，但这是可以用来说明的。我想你们会同意这里涉及到国家。变量x的值随时间变化。现在，让我们稍微改变一下符号，发明一个新的语法:

let x = 1 in
let y = x + 1 in
let z = x + y in z 

加上括号使它的意思更清楚:

let x = 1 in (let y = x + 1 in (let z = x + y in (z)))

可以看到，状态是由一系列纯表达式建模的，这些纯表达式绑定了下面表达式的自由变量。

您会发现这个模式可以建模任何类型的状态，甚至IO。

事实上，即使在没有可变状态的语言中，也很容易有一些看起来像可变状态的东西。

Consider a function with type s -> (a, s). Translating from Haskell syntax, it means a function which takes one parameter of type "s" and returns a pair of values, of types "a" and "s". If s is the type of our state, this function takes one state and returns a new state, and possibly a value (you can always return "unit" aka (), which is sort of equivalent to "void" in C/C++, as the "a" type). If you chain several calls of functions with types like this (getting the state returned from one function and passing it to the next), you have "mutable" state (in fact you are in each function creating a new state and abandoning the old one).

It might be easier to understand if you imagine the mutable state as the "space" where your program is executing, and then think of the time dimension. At instant t1, the "space" is in a certain condition (say for example some memory location has value 5). At a later instant t2, it is in a different condition (for example that memory location now has value 10). Each of these time "slices" is a state, and it is immutable (you cannot go back in time to change them). So, from this point of view, you went from the full spacetime with a time arrow (your mutable state) to a set of slices of spacetime (several immutable states), and your program is just treating each slice as a value and computing each of them as a function applied to the previous one.

好吧，也许这并不容易理解:-)

It might seem inneficient to explicitly represent the whole program state as a value, which has to be created only to be discarded the next instant (just after a new one is created). For some algorithms it might be natural, but when it is not, there is another trick. Instead of a real state, you can use a fake state which is nothing more than a marker (let's call the type of this fake state State#). This fake state exists from the point of view of the language, and is passed like any other value, but the compiler completely omits it when generating the machine code. It only serves to mark the sequence of execution.

举个例子，假设编译器给了我们以下函数:

readRef :: Ref a -> State# -> (a, State#)
writeRef :: Ref a -> a -> State# -> (a, State#)

从这些类似haskell的声明中转换，readRef接收到类似于指向“a”类型值和假状态的指针或句柄的东西，并返回由第一个形参和新的假状态指向的“a”类型值。writeRef类似，但是改变了所指向的值。

If you call readRef and then pass it the fake state returned by writeRef (perhaps with other calls to unrelated functions in the middle; these state values create a "chain" of function calls), it will return the value written. You can call writeRef again with the same pointer/handle and it will write to the same memory location — but, since conceptually it is returning a new (fake) state, the (fake) state is still imutable (a new one has been "created"). The compiler will call the functions in the order it would have to call them if there was a real state variable which had to be computed, but the only state which there is is the full (mutable) state of the real hardware.

(了解Haskell的人会注意到我简化了很多东西，并省略了一些重要的细节。对于那些想要看到更多细节的人，看看mtl中的Control.Monad.State，以及ST和IO(又名ST RealWorld)单子。

You might wonder why doing it in such a roundabout way (instead of simply having mutable state in the language). The real advantage is that you have reified your program's state. What before was implicit (your program state was global, allowing for things like action at a distance) is now explicit. Functions which do not receive and return the state cannot modify it or be influenced by it; they are "pure". Even better, you can have separate state threads, and with a bit of type magic, they can be used to embed an imperative computation within a pure one, without making it impure (the ST monad in Haskell is the one normally used for this trick; the State# I mentioned above is in fact GHC's State# s, used by its implementation of the ST and IO monads).

请记住:函数式语言是图灵完备的。因此，任何用命令式语言执行的有用任务都可以用函数式语言完成。最后，我认为混合方法是有意义的。像f#和Clojure(我确信还有其他语言)这样的语言鼓励无状态设计，但在必要时允许可变性。

你不可能有一种有用的纯函数式语言。总会有一定程度的可变性需要处理，IO就是一个例子。

将函数式语言视为您使用的另一种工具。它对某些事情有好处，但对其他事情没有好处。你给出的游戏例子可能不是使用函数语言的最佳方式，至少屏幕会有一个可变的状态，你不能用FP做任何事情。使用FP思考问题的方式和解决问题的类型将不同于使用命令式编程所习惯的方式。

简单的回答是:你不能。

那么不变性有什么好大惊小怪的呢?

If you're well-versed in imperative language, then you know that "globals are bad". Why? Because they introduce (or have the potential to introduce) some very hard-to-untangle dependencies in your code. And dependencies are not good; you want your code to be modular. Parts of program not influence other parts as little as possible. And FP brings you to the holy grail of modularity: no side effects at all. You just have your f(x) = y. Put x in, get y out. No changes to x or anything else. FP makes you stop thinking about state, and start thinking in terms of values. All of your functions simply receive values and produce new values.

这有几个优点。

首先，没有副作用意味着程序更简单，更容易推理。不用担心引入程序的新部分会干扰并使现有的正在工作的部分崩溃。

其次，这使得程序的可并行性微不足道(有效的并行化是另一回事)。

第三，有一些可能的性能优势。假设你有一个函数:

double x = 2 * x

现在你输入一个3的值，得到一个6的值。每一次。但是在祈使句中也可以这样做，对吧?是的。但问题是，在命令式中，你可以做更多的事情。我可以:

int y = 2;
int double(x){ return x * y; }

但我也可以

int y = 2;
int double(x){ return x * (y++); }

命令式编译器不知道我是否会有副作用，这使得优化更加困难(即double 2不必每次都是4)。函数函数知道我不会——因此，它可以在每次看到“double 2”时进行优化。

现在，即使每次创建新值对于复杂类型的值在计算机内存方面看起来是难以置信的浪费，但它不必如此。因为，如果你有f(x) = y，并且x和y的值“基本相同”(例如，只有少数叶子不同的树)，那么x和y可以共享部分内存——因为它们都不会突变。

如果这个不可变的东西这么好，为什么我说没有可变状态就不能做任何有用的事情。如果没有可变性，整个程序就是一个巨大的f(x) = y函数。同样的道理也适用于程序的所有部分:只是函数，而且是“纯粹”意义上的函数。我说过，这意味着每次都是f(x) = y。因此，例如readFile("myFile.txt")每次都需要返回相同的字符串值。不是很有用。

因此，每个FP都提供了一些突变状态的方法。“纯”函数语言(例如Haskell)使用一些可怕的概念(如单子)来做到这一点，而“不纯”函数语言(例如ML)则直接允许这样做。

当然，函数式语言还带来了许多其他优点，使编程更加高效，比如一类函数等。