Haskell / Clojure是否真的不适合诸如粒子模拟之类的动态系统？

在先前的问题中，有人告诉我函数式编程语言不适合物理引擎之类的动态系统，这主要是因为变异对象的成本很高。这种说法有多现实？为什么？

Haskell和Clojure都允许实际的可变性，因此从一开始就不成问题。

除此之外，如果您的“可变”数据由作为一些较大计算的一部分而逐渐更新的中间值组成，您甚至可能不需要可变性就可以提高效率！例如，Haskell正在进行一项关于流融合的技术的研究，该技术中的编译器融合了处理循环，数据生产者和数据使用者，以完全消除中间数据结构。

Haskell在这里的主要问题是懒惰-在一个数字运算程序中，您有很多输入数据和很多输出数据，而所有这些都很重要，懒惰对您几乎没有好处，但仍然会带来一些开销。这并不是说您不能在Haskell中编写类似的程序（实际上人们确实如此），但是它并没有发挥语言的优势，您需要更好地了解评估模型才能获得所需的性能。

也就是说，繁重的数字处理也无法发挥JVM的优势。这种程序就是为什么FORTRAN仍然存在的原因。

我不能代表Clojure，但是我可以说Haskell有很多非常优化的IO软件包，这些软件包将允许您想要的所有变异。

这是我写的一个问题的答案，其中有人详细介绍了三种最常见的问题并考虑了它们的性能：https : //stackoverflow.com/questions/15439966/when-why-use-an-mvar-over-a-tvar/15440286 ＃15440286

您还可以在此处看到一个简单的图表，其中显示了称为Warp的haskell Web服务器的性能指标，该服务器是IO密集型应用程序。

关于Haskell，对此有很多困惑，事实是它具有出色的IO设施，其中包含许多用于以多种不同方式使用IO的黑客软件包，其中许多已进行了高度优化。人们认为并非如此的原因是，Haskell竭尽全力将IO与其他所有内容分开，但这对性能特征没有影响。

但是，现在要谈论性能特征，人们之所以认为它性能不佳，是由于懒惰的评估导致其以并非总是直观的方式表现。但是，当您在IO上下文中开始进行破坏性更新（例如在您所指的系统中）时，您不必担心的事情就会大大减少。进一步的人倾向于发现，当他们遇到性能问题时，用于检测和确定资源去向的内置设施将提供很大帮助。

值得一看的像您描述的系统一样值得关注的monad是ST monad，它专门用于通过很小的IO调用进行破坏性更新，从而提供了出色的性能。

抱歉，我真的不能和Clojure通话，希望其他人可以在那提供详细信息。