函数式编程的陷阱/缺点 [英] Pitfalls/Disadvantages of Functional Programming
问题描述
你什么时候不想使用函数式编程？它不擅长什么？
我更加关注整体范例的缺点，而不是像未被广泛使用或没有好的调试器可用。那些答案可能现在是正确的，但他们处理FP是一个新概念（一个不可避免的问题），而不是任何固有的特质。 相关：
- 功能性编程的优势
- 为什么没有功能编程接管了吗？
我很难想象很多功能编程的缺点。再次，我是功能规划国际会议的前任主席，所以您可以放心地认为我有偏见。
我认为主要缺点与隔离有关并有进入壁垒。学习写出 good 功能性程序意味着学习以不同的方式思考，做得好，需要投入大量的时间和精力。没有老师是很难学的。这些属性会导致一些负面影响：
-
新手编写的函数程序很可能会不必要地慢 - 更可能而不是比如说一个由新手写给C的C程序。另一方面，新手编写的C ++程序可能会不必要地慢。 （所有那些闪亮的功能...）
一般来说专家编写快速功能程序并不困难;事实上，一些在8核和16核处理器上表现最好的并行程序现在已经写入 Haskell 了。
-
开始函数式编程的人很可能会放弃在实现承诺的生产力增长之前，而不是开始比如说Python或Visual Basic的人。在书籍和开发工具方面没有那么多的支持。
与人交谈的人越来越少。 Stackoverflow就是一个很好的例子。相对较少的Haskell程序员定期访问该网站（尽管其中的一部分是Haskell程序员拥有自己的生动的论坛，这些论坛比Stackoverflow更加老旧和更好）。
它也是确实，你不能很容易地与邻居说话，因为函数式编程概念比Smalltalk，Ruby和C ++等语言背后的面向对象概念更难教和难学。而且，面向对象的社区花费了好几年时间为他们所做的工作提供了很好的解释，而功能编程社区似乎认为他们的东西显然很棒，并且不需要任何特殊的隐喻或词汇来解释。 （他们错了，我仍然在等待第一本好书 Functional Design Patterns 。） 一个众所周知的缺点是懒惰函数式编程（适用于Haskell或Clean，但不适用于ML或Scheme或Clojure）是，要预测评估懒惰的时间和空间成本是非常困难的。 em>功能程序 - 即使是专家也无法做到。这个问题是范例的基础，并且不会消失。有很多用于发现时间和空间行为的工具 post facto ，但为了有效地使用它们，您必须已经成为专家。
When would you NOT want to use functional programming? What is it not so good at?
I am more looking for disadvantages of the paradigm as a whole, not things like "not widely used", or "no good debugger available". Those answers may be correct as of now, but they deal with FP being a new concept (an unavoidable issue) and not any inherent qualities.
Related:
It's hard for me to think of many downsides to functional programming. Then again, I am a former chair of the International Conference on Functional Programming, so you may safely assume I am biased.
I think the main downsides have to do with isolation and with barriers to entry. Learning to write good functional programs means learning to think differently, and to do it well requires a substantial investment of time and effort. It is difficult to learn without a teacher. These properties lead to some downsides:
It is likely that a functional program written by a newcomer will be unnecessarily slow—more likely than, say, a C program written by a newcomer to C. On the other hand, it is about equally likely that a C++ program written by a newcomer will be unnecessarily slow. (All those shiny features...)
Generally experts have no difficulty writing fast functional programs; and in fact some of the best-performing parallel programs on 8- and 16-core processors are now written in Haskell.
It's more likely that someone starting functional programming will give up before realizing the promised productivity gains than will someone starting, say, Python or Visual Basic. There just isn't as much support in the form of books and development tools.
There are fewer people to talk to. Stackoverflow is a good example; relatively few Haskell programmers visit the site regularly (although part of this is that Haskell programmers have their own lively forums which are much older and better established than Stackoverflow).
It's also true that you can't talk to your neighbor very easily, because functional-programming concepts are harder to teach and harder to learn than the object-oriented concepts behind languages like Smalltalk, Ruby, and C++. And also, the object-oriented community has spent years developing good explanations for what they do, whereas the functional-programming community seem to think that their stuff is obviously great and doesn't require any special metaphors or vocabulary for explanation. (They are wrong. I am still waiting for the first great book Functional Design Patterns.)
A well-known downside of lazy functional programming (applies to Haskell or Clean but not to ML or Scheme or Clojure) is that it is very difficult to predict the time and space costs of evaluating a lazy functional program—even experts can't do it. This problem is fundamental to the paradigm and is not going away. There are excellent tools for discovering time and space behavior post facto, but to use them effectively you have to be expert already.
这篇关于函数式编程的陷阱/缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
