使用一些创造性和模式匹配，无状态游戏被创造出来:

迷宫游戏 迷宫游戏2 CSSPlay:井字 纯CSS一字棋 CSSPlay:乒乓球 CSSPlay:乒乓球 CSSPlay:警察与强盗 CSSPlay: Whack-a-Rat CSS3 Pong:与CSS有关的疯狂事情

以及滚动演示:

随机英雄 动画模拟SVG时钟 动画SVG摆 动画SVG赛车手 CSS3:造雪

和可视化:

XSLT 曼德尔布洛特

只是做同一件事的不同方式。

Consider a simple example such as adding the numbers 3, 5, and 10. Imagine thinking about doing that by first changing the value of 3 by adding 5 to it, then adding 10 to that "3", then outputting the current value of "3" (18). This seems patently ridiculous, but it is in essence the way that state-based imperative programming is often done. Indeed, you can have many different "3"s that have the value 3, yet are different. All of this seems odd, because we have been so ingrained with the, quite enormously sensible, idea that the numbers are immutable.

现在，当您将值设置为不可变时，考虑添加3、5和10。3加5得到另一个值8，然后再加10得到另一个值18。

这是做同样事情的等价方法。所有必要的信息都存在于这两种方法中，只是形式不同。其中，信息以状态的形式存在，并存在于改变状态的规则中。在另一种情况下，信息存在于不可变数据和函数定义中。

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

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

TLDR:你可以在没有可变状态的情况下进行任何计算，但是当真正需要告诉计算机该做什么的时候，因为计算机只使用可变状态，你需要在某些时候改变一些东西。

有很多答案正确地说，没有可变状态就不能做任何有用的事情，我想用一些简单的(反)例子来支持这一点，以及一个普遍的直觉。

如果你看到任何一段被认为是“纯函数式”的代码，并且它是这样做的(不是真正的语言):

printUpToTen = map println [1..10]

这不是纯功能性的。有一个隐藏状态(stdout的状态)不仅被改变了，而且隐式地传递进来。看起来像这样的代码(同样不是真正的语言):

printUpToTen = map println stdout [1..10]

也是不纯的:即使显式地传入state (stdout)，它仍然是隐式突变的。

现在直观地说:可变状态是必要的，因为影响我们计算机的核心构建块是可变状态，这个构建块是内存。我们不能强迫计算机做任何事情，而不以某种方式操纵内存，即使我们的计算模型确实可以计算任何东西，而没有“内存”的概念。

Think of something like an old GameBoy Advance: in order to display something to the screen, you must modify the memory (there are certain addresses that are read many times a second that determine whats being put on the screen). Your computational model (pure functional programming) may not need state to operate, you may even be able to implement you model using an imperative, state manipulation model (like assembly) that abstracts the state manipulation, but at the end of the day, somewhere in you code you have to modify those addresses in memory for the device to actually display anything.

这就是命令式模型具有天然优势的地方:因为它们总是在操作状态，所以您可以非常容易地将其转换为实际修改内存。下面是一个渲染循环的例子:

while (1) {
   render(graphics_state);
}

如果你要展开循环，它看起来像这样:

render(graphics_state); // modified the memory
render(graphics_state); // modified the memory
render(graphics_state); // modified the memory
...

但在纯函数式语言中，你可能会得到这样的东西:

render_forever state = render_forever newState
    where newState = render state

展开(准确地说是压平)可以像这样可视化:

render(render(render(render(...state) // when is the memory actually changing??

// or if you want to expand it the other direction
...der(render(render(render(render(render(state) // no mutation

正如你所看到的，我们在状态上一遍又一遍地调用一个函数，状态是不断变化的，但我们从不改变内存:我们立即将它传递给下一个函数调用。即使我们的实现实际上在底层修改了一些表示状态的东西(甚至在适当的位置!)，它也不在正确的位置。在某些时候，我们需要暂停并修改内存中的正确地址，这涉及到突变。

下面是如何在没有可变状态的情况下编写代码:不是将变化状态放入可变变量中，而是将其放入函数的参数中。不写循环，而是写递归函数。比如这段命令式代码:

f_imperative(y) {
  local x;
  x := e;
  while p(x, y) do
    x := g(x, y)
  return h(x, y)
}

变成这样的函数代码(类似scheme的语法):

(define (f-functional y) 
  (letrec (
     (f-helper (lambda (x y)
                  (if (p x y) 
                     (f-helper (g x y) y)
                     (h x y)))))
     (f-helper e y)))

或者这个Haskellish代码

f_fun y = h x_final y
   where x_initial = e
         x_final   = loop x_initial
         loop x = if p x y then loop (g x y) else x

至于为什么函数式程序员喜欢这样做(你没有问)，你的程序中无状态的部分越多，就有越多的方法可以在不中断的情况下将这些部分组合在一起。无状态范式的强大之处在于它本身不具有无状态性(或纯粹性)，而在于它使您能够编写强大的、可重用的函数并将它们组合起来。

你可以在John Hughes的论文Why Functional Programming Matters中找到一个很好的教程，里面有很多例子。

这就是没有COMMON块的FORTRAN的工作方式:您将编写具有传入值和局部变量的方法。就是这样。

面向对象编程将我们的状态和行为结合在一起，但当我在1994年第一次从c++中接触到它时，它还是一个新思想。

天啊，当我还是机械工程师的时候，我是一个函数式程序员，而我却不知道!