你最近有关注编程语言的发展吗?所有主流编程语言的每一个新版本似乎都从函数式编程中借用了越来越多的特性。

Closures, anonymous functions, passing and returning functions as values used to be exotic features known only to Lisp and ML hackers. But gradually, C#, Delphi, Python, Perl, Javascript, have added support for closures. Its not possible for any up-and-coming language to be taken seriously without closures. Several languages, notably Python, C#, and Ruby have native support for list comprehensions and list generators. ML pioneered generic programming in 1973, but support for generics ("parametric polymorphism") has only become an industry standard in the last 5 years or so. If I remember correctly, Fortran supported generics in 2003, followed by Java 2004, C# in 2005, Delphi in 2008. (I know C++ has supported templates since 1979, but 90% of discussions on C++'s STL start with "here there be demons".)

是什么让这些功能吸引程序员?这应该是显而易见的:它帮助程序员编写更短的代码。如果想要保持竞争力，未来所有的语言都将至少支持闭包。在这方面，函数式编程已经成为主流。

大多数应用程序都很简单 可以用正常的面向对象方法解决

谁说不能用函数式编程来处理简单的事情?并不是每个函数程序都需要是编译器、定理证明器或大型并行通信交换机。除了更复杂的项目外，我还经常使用f#来编写临时脚本。

我不认为大多数现实的人会认为函数式编程会流行起来(成为像OO那样的主要范式)。毕竟，大多数业务问题都不是漂亮的数学问题，而是用来移动数据并以各种方式显示它们的繁琐的命令式规则，这意味着它不适合纯函数式编程范式(monad的学习曲线远远超过OO)。

对了，函数式编程让编程变得有趣。它会让你欣赏宇宙中潜在数学的简洁表达所蕴含的永恒之美。人们说学习函数式编程会让你成为更好的程序员。当然，这是非常主观的。我个人认为这也不完全正确。

它让你成为一个更有感情的人。

函数式语言的一个关键特征是一类函数的概念。其思想是，您可以将函数作为参数传递给其他函数，并将它们作为值返回。

函数式编程包括编写不改变状态的代码。这样做的主要原因是，对函数的连续调用将产生相同的结果。您可以使用任何支持第一类函数的语言编写函数式代码，但有一些语言(如Haskell)不允许更改状态。事实上，你根本不应该产生任何副作用(比如打印文本)——这听起来可能完全没用。

相反，Haskell对IO: monads采用了不同的方法。这些对象包含解释器顶层要执行的所需IO操作。在其他任何层面上，它们都只是系统中的对象。

函数式编程有什么优点?函数式编程允许代码出现错误的可能性更小，因为每个组件都是完全隔离的。此外，使用递归和一级函数允许简单的正确性证明，这通常反映了代码的结构。

我一直对“下一件大事”持怀疑态度。很多时候，下一个大事件纯粹是历史的偶然，无论技术好坏，它都在正确的时间出现在正确的地点。例如:c++， Tcl/Tk, Perl。所有的技术都是有缺陷的，都非常成功，因为它们被认为要么解决了当时的问题，要么与根深蒂固的标准几乎相同，或者两者兼而有之。函数式编程可能确实很棒，但这并不意味着它会被采用。

But I can tell you why people are excited about functional programming: many, many programmers have had a kind of "conversion experience" in which they discover that using a functional language makes them twice as productive (or maybe ten times as productive) while producing code that is more resilient to change and has fewer bugs. These people think of functional programming as a secret weapon; a good example of this mindset is Paul Graham's Beating the Averages. Oh, and his application? E-commerce web apps.

自2006年初以来，也有一些关于函数式编程和并行的讨论。因为像Simon Peyton Jones这样的人至少从1984年开始就一直在担心并行性，所以在函数式语言解决多核问题之前，我不会屏住呼吸。但它确实解释了目前一些额外的话题。

In general, American universities are doing a poor job teaching functional programming. There's a strong core of support for teaching intro programming using Scheme, and Haskell also enjoys some support there, but there's very little in the way of teaching advanced technique for functional programmer. I've taught such a course at Harvard and will do so again this spring at Tufts. Benjamin Pierce has taught such a course at Penn. I don't know if Paul Hudak has done anything at Yale. The European universities are doing a much better job; for example, functional programming is emphasized in important places in Denmark, the Netherlands, Sweden, and the UK. I have less of a sense of what's happening in Australasia.

哇，这是一个有趣的讨论。我对此有自己的看法:

FP使一些任务相对简单(与非FP语言相比)。 非FP语言已经开始从FP中汲取思想，所以我怀疑这种趋势会继续下去，我们将看到更多的合并，这将帮助人们更容易地过渡到FP。

我的观点是，既然微软已经把它推向了主流，它就会流行起来。对我来说，它很有吸引力，因为它能为我们做什么，因为它是一个新的挑战，因为它为未来提供了工作机会。

一旦掌握了它，它将成为进一步帮助我们提高编程效率的另一个工具。