如今，越来越多的注意力转向函数式编程的主要原因之一是多线程/处理的兴起以及 FP 专注于无副作用、无状态计算的优势，从而使可伸缩性变得轻松。
当然，尽管如此，在面向对象编程中，我们也可以转移到无状态范式，在这种范式中，所有对象都不会改变状态。这可以是一种约定，甚至可能是语言隐式支持的。例如，在强制对象字段和方法之间统一访问的语言中，简单地不允许 setter 方法就可以实现这一点。
那么，我的问题是，既然 OO 可以利用无状态性，并且对象没有任何要求有状态性，那么 OOP 是否实际上是 FP 的超集？FP 是否有任何其他优点/特性使多线程比 OOP 更实用？
是学历的问题。
使用函数式语言进行函数式编程的优点是胡萝卜加大棒。胡萝卜是函数式语言具有函数式语法和语义，并带有函数库。关键是函数式语言可以迫使您遵守某些标准。如果你用非 FP 语言做 FP，你就不会得到这些。您必然会与对状态友好的标准库作斗争，并且必须自我监督以确保您不会创建状态。
在 C 中做 OO 的类比是一个很好的类比。有时您的约束条件使得 C 是正确的选择，而 OO 结构也是正确的选择。GTK 就是一个很好的例子。如果没有 OOP，很难编写 UI 工具包。但是，这意味着您正在承担通常由编译器完成的工作。如果没有句法和语义支持，一些在一种语言中很容易的事情在一种语言中变得困难或不可能。例如，我从未见过模拟多重继承的 C 项目。只是体力劳动太多了。
如果您为了并行性而在您的 OO 代码中采用函数式风格，那么您很可能会在没有太多痛苦的情况下获得您所追求的好处。但是您仍然会错过编译时保证，即您的代码是纯粹的、对 FP 的语言内支持以及 FP 编译器如今能够进行的令人印象深刻的优化。这是一个权衡，所以这是一个必须根据具体情况做出的决定，而且只有你可以做出。
至于 OOP 是否是 FP 的超集，我什至认为这个概念没有意义。在表达程序方面，他们都是完全有能力的。您可以在 FP 语言中实现 OO 语言，反之亦然。有时一个更接近问题域，有时另一个。无论如何，我认为你真正的问题是是否一定要喜欢 FP，答案是，不；用你喜欢的。
我认为您还应该考虑检查 Actor 模型，因为它更适合 OO 而不是状态不友好（只是共享状态不友好），同时仍然产生可伸缩性/并行性的好处。
我曾经有过同样的理解，并且被“纠正”了。我不是一个函数式的人，我不明白，但显然函数式语言中有一些工具可以更好地适应这种编程风格。
我认为这就像一个 C 程序员说，既然 C 方法可以组合成一个结构并被替换，那不是让 C 成为 OO 的超集吗？事实上，这就是 C++ 最初的实现方式，但它并没有使 C 成为一种 OO 语言。
FP 更多的是关于你解决问题的方式，而不是你使用的语言。所以没有 OOP 不是 FP 的超集。FP 中的一些构造（mapReduce，...）可以隐式转换为多线程应用程序。但是没有什么能阻止您在 OOP 中使用它们。这都是关于心态的。