一些想法:

The debate between FP and imperative programming (OO, structured, etc), has been raging since Lisp versus Fortran. I think you pose excellent questions but recognize that they are not especially new. Part of the hoopla over FP is that we seem to be recognizing that concurrency is very difficult, and that locks and other mechanisms in OO (e.g. Java) are just one solution. FP offers a refreshing sea change with ideas such as Actors and the power of stateless computing. To those wrestling with OO, the landscape seems highly appealing. Yes, schools teach FP. In fact, the University of Waterloo and others offer Scheme in first year classes (reference here). Regarding the average programmer, I'm sure that the same arguments were given against C++ back in the early 1990s. And look what happened. If businesses can gain an advantage via a technology, you can bet that people will receive training.

这并不是说这是板上钉钉的事，也不是说在3-5年内不会出现反弹(一如既往)。然而，朝着计划生育的趋势是有好处的，值得关注。

我敢打赌，当你使用以下方法时，你并不知道你在进行函数式编程:

Excel公式 石英的作曲家 JavaScript Logo(海龟图形) LINQ SQL js(或Lodash)， D3

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

函数式编程包括编写不改变状态的代码。这样做的主要原因是，对函数的连续调用将产生相同的结果。您可以使用任何支持第一类函数的语言编写函数式代码，但有一些语言(如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.

我个人认为，对于分布式系统和多线程/并行编程，函数式编程将很快取得突破。只要它通过编程库与现有的OOP范式集成。所以…在我看来，纯功能的方法仍将停留在学术上。

函数式编程将很可能成为工程师和科学家用来解决他们所面临的问题的工具。它不会像早期的语言那样占领世界。然而，最难打败的产品是Excel，如果我是一名工程师，需要做计算，Excel是很棒的。

However, F# is going to be another source and will likely fill design needs by the non-Computer Scientists. Let's face it, Computer Scientists have done a great job of creating a WHOLE new way of doing things. Object Oriented Programming is GREAT. But sometimes you just need a way to solve an equation, get a solution and graph it. That's it. Then a language like F# fills the bill. Or maybe you want to build a finite state machine, F# again could be one of the solutions, but then C could be a solution as well.

但是当涉及到并行处理时，Excel大放异彩，f#也会及时出现。但是要以友好的方式，F#= friendly。