您最反对函数式编程的观点是什么？[关闭]

函数式编程是最古老的编程范例之一。但是，与更流行的范例相比，它在业界使用不多。但是在学术界已经大大强调了这一点。

您最反对函数式编程的观点是什么？

问题在于，最常见的代码固有地涉及状态-业务应用程序，游戏，UI等。应用程序的某些部分纯功能没有问题；实际上，大多数应用程序至少可以在一个方面受益。但是，将范式强加到处都是感觉违反直觉的。

函数式编程的问题不在于函数式编程本身，而是大多数执行此操作的人和（更糟糕的）大多数设计用于执行该操作的语言的人。

问题源于以下事实：尽管非常聪明（有时是彻头彻尾的聪明才智），但仍有太多人对纯正，完美和对世界的看法（通常是相当狭and的）过于狂热，并向世界编程。语言以及使用它的每个人。

结果之一是无法妥协。（除其他事项外）这导致大约10,000种语言和方言的不同，足以使人烦恼，但只有极少的不同，以使其中一种具有与其他语言相比真正的显着优势。许多人还着眼于现实世界，并决定由于它与功能模型不太吻合，因此基本上是错误的，最好予以忽略。

无法妥协还导致了相当多的语言，它们对于特定类型的问题（或某些特定类型的问题）绝对是美丽的，但对于其他许多类型来说却确实很烂。其中一些可能是由功能模型本身引起的，但是（至少在我看来）更多是由吸引该领域的基本人格类型引起的。

这导致了许多问题。首先，学习“函数式编程”主要具有哲学价值。对于大多数其他类型的语言，了解特定类型的一种语言对学习另一种语言有很大帮助。如果我的项目使用语言XI，通常可以聘请相当安全地了解语言Y（但不是X）的人。对于函数式语言，事实并非如此。您可能非常了解Erlang，但仍然发现Haskell monads完全陌生且难以理解。

将语言的数量与人才之间有限的可移植性相结合，您会遇到一个丑陋的情况：一种语言或方言几乎不可能形成将其合理地普遍使用所必需的“临界质量”。这是慢慢改变，但它仍然像Linux一样成为占主导地位的桌面操作系统有很多-每一年，人们想出了令人信服的论据最后这将是在一年-就像人谁一直在预测，每几十年来，他们又会错了。这并不是说（任何一个）都不会发生-只是那些看过预测并认为“不，今年不是”的人到目前为止是正确的。

我认为函数式编程没有得到广泛使用的原因是因为它妨碍了您的工作。很难认真研究一下例如Lisp或Haskell，而不必说“整个语言是一种很大的抽象反转”。当您建立了必要时编码人员无法获得的基线抽象时，您会建立该语言根本无法做到的事情，并且该语言的功能越多，它们所拥有的往往就越多。

以Haskell为例。以功能纯净的名义，您需要使用任何人都无法理解的令人震惊的抽象反转来管理状态和I / O，这是任何与任何事物交互的计算机程序的两个最基本的部分！ 很快变老了。

一切适当的尊重，我认为你的问题提出来了。函数式编程是一种工具，或者是一组对解决某些类型的问题有用的工具。对它有意见仅在特定问题或应用程序的上下文中才有意义。通常，对它有意见，就像对钳子或扳手有意见。

即使我已经掌握了它，我也可能不愿意在商业产品中使用功能语言，原因很简单，原因是它们未被广泛理解，并且如果我希望业务发展，我会担心寻找其他有能力的开发人员的能力随着时间的推移维护或扩展它。

这不是不可想象的，您可能会获得更高的开发人员标准，因为没有真正黑客技能的javaschool毕业生不会知道从哪种类型的项目开始，但是有能力的开发人员的有限一定是一个必要的考虑因素。从业务角度来看。

上市时间

难以摆脱程序代码和咒语的完整IT环境。

首先，我不接受有关有状态编程和fp的任何论点。查看haskell中的State monad，您会发现许多有趣的新方法来评估State对代码的影响。

如果我要对fp进行有意义的论证，那将是学习像haskell这样的严肃的功能语言就像学习驾驶一级方程式赛车。...令人振奋和有教育意义，但对于日常的工业编码却很可惜，因为平均而言，您的同事正在驾驶凯美瑞，并且对此感到非常高兴。在fp友好的环境中找到工作仍然非常困难，而且除非有人愿意自行淘汰或寻找fp的一些知名从业人员，否则我不会看到这种变化。

我想我的回答让我觉得自己是fp的狂热粉丝。我建议在担心找不到原因的原因之前，先给haskell这样的真正的FP语言打个招呼。

我是函数式编程的忠实拥护者和拥护者。但是，这是我的观点：

• 易于学习
  像python和ruby这样的编程语言（以及许多其他语言）也很容易学习。使用Haskell，Agda，Coq，ATS等语言进行高级功能编程非常困难。有些使用术语“数学结构化编程”。如果您熟悉类别理论和抽象数学，这很容易，但是如果您不知道“单子”是什么，那么可以做很多工作。

• 使用脚本语言进行编程可以提高工作效率。
  在某些情况下，使用脚本语言（如python和ruby）可以提高生产力。这意味着可以快速制作原型并将不同的软件包或库粘合在一起。在这种情况下，即使使用动态语言（例如，面向对象的动态编程）也是一件好事。通常，静态类型更好，但是使用动态类型的脚本可以起到积极的作用。

• 商业考虑
  编程只是成功的软件项目的一小部分。软件必须运行，用户必须开心，这不一定取决于所使用的编程语言。管理人员在评估新技术和编程语言时必须考虑收益和风险。新程序员可以快速学习新的编程语言吗？公司在技术方面有经验吗？是否存在风险，与上层管理人员难于争论吗？

在业务环境中，功能性编程可用于添加到核心软件组件（例如，并非如此关键任务的组件）的系统中。例如，一家银行几乎不会更改核心软件，而是以新的编程语言添加新的部件（GUI，监视软件等）。（也许有例外，但这是我在银行的经历。）

此外，当形式验证是一种好处或必须时，函数式编程非常有用。

我不反对FP是有用的范例，但我反对FP是编程语言中唯一可用的范例。

它在解决许多问题方面具有优势。但是，FP可以并且已经在C等程序语言中应用。

1. （到目前为止，最重要的一点）程序员的劳动力没有经过这些语言或样式的培训
2. 许多实用的福音传教士由于尝试销售实用的方式而成为洞洞或水果蛋糕。没有人喜欢一个洞，也没有人会把钱扔在一个水果蛋糕后面。提醒您，我真的很喜欢这些功能性的东西，并且希望将其引入其中，但是我知道，在我的工作场所中，我将是唯一一个无需花费大量培训（硬性销售）就可以开发它的人，几乎所有的优点引用读者的谈话内容。

当我们拥有数百个内核并达到锁无法扩展的认识时，功能便会出现。然后，并行数据嵌套将是“大型”程序的唯一途径，而功能在这方面表现出色。

FP在学术界很不错，因为编写出色的简短程序很酷，却忽略了性能。在现实世界中没有任何阴谋。同样，例如，实现某些东西（例如基数排序）似乎在FP中完全痛苦。哦，生成的代码是IMHExperience sloooooooooooooooooooooow。

有些人的学习曲线相当陡峭，需要很长时间（特别是如果您来自OOP；在进行范式转换之前，您将数次尖嘴）。

即使我开始进行函数式编程（来自Java并进入Clojure），我仍然发现它相当困难。社区似乎没有编写像Java那样具有表现力的代码。

似乎表现力损失很小，复杂性增加很小。

即使我对函数式编程语言（我认识一些Haskell和Lisp）经验很少，但我发现FP范例非常强大，并且通常比其他范例更优雅。我希望我有机会使用FP进行一个严肃的项目。

对于FP的有效性，我唯一有严重怀疑的领域是它如何处理无法归纳定义的复杂数据结构，例如图形。例如，如果我必须实现一种适用于大图的算法，可能遍历图并进行小的局部更改，那么我想知道FP方法是否可以与命令式方法相匹配，在该方法中，程序可以从节点移动到节点节点使用指针。