blocks|key|2922759|text|函数式语言的一个关键特性是第一类函数的概念。其思想是，您可以将函数作为参数传递给其他函数，并将它们作为值返回。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2922760|函数式编程涉及编写不改变状态的代码。这样做的主要原因是，连续调用函数将产生相同的结果。您可以用任何支持一类函数的语言编写函数代码，但是有些语言不允许您更改状态，比如Haskell。事实上，你根本不应该产生任何副作用(比如打印文本)--这听起来可能是完全无用的。|2922761|相反，Haskell采用了一种不同的IO方法:+monads。这些对象包含要由解释器的顶层执行的所需IO操作。在任何其他级别，它们都只是系统中的对象。|2922762|函数式编程有什么优势？函数式编程允许使用较少的潜在bug进行编码，因为每个组件都是完全隔离的。此外，使用递归和一类函数允许简单的正确性证明，这通常反映了代码的结构。|2922763|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

One key feature in a functional language is the concept of first-class functions. The idea is that you can pass functions as parameters to other functions and return them as values.

Functional programming involves writing code that does not change state. The primary reason for doing so is so that successive calls to a function will yield the same result. You can write functional code in any language that supports first-class functions, but there are some languages, like Haskell, which do not allow you to change state. In fact, you're not supposed to make any side effects (like printing out text) at all - which sounds like it could be completely useless.

Haskell instead employs a different approach to IO: monads. These are objects that contain the desired IO operation to be executed by your interpreter's toplevel. At any other level they are simply objects in the system.

What advantages does functional programming provide? Functional programming allows coding with fewer potentials for bugs because each component is completely isolated. Also, using recursion and first-class functions allows for simple proofs of correctness which typically mirror the structure of the code.

blocks|key|719214|text|函数式语言使用与命令式和面向对象语言不同的范例。它们使用无副作用的函数作为语言中的基本构建块。这使得很多事情变得更加困难(或者在大多数情况下与人们所习惯的不同)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|719215|函数式编程的最大优点之一是，无副作用函数的执行顺序并不重要。例如，在Erlang中，这用于以一种非常透明的方式启用并发性。因为函数式语言中的函数行为与数学函数非常相似，所以很容易将它们转换成函数式语言。在某些情况下，这可以使代码更具可读性。|719216|传统上，函数式编程的一大缺点也是缺乏副作用。没有IO很难写出有用的软件，但IO很难在没有函数副作用的情况下实现。因此，大多数人从函数式编程中获得的好处永远不会超过从单个输入计算单个输出。在像F#或Scala这样的现代混合范式语言中，这就更容易了。|719217|许多现代语言都包含来自函数式编程语言的元素。Python3.0有很多函数式编程特性，你也可以用C#进行函数式编程。我认为函数式编程流行的原因主要有两个:并发性在普通编程中正成为一个真正的问题，因为我们得到了越来越多的多处理器计算机；以及语言变得越来越容易使用。|719218|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Functional languages use a different paradigm than imperative and object-oriented languages. They use side-effect-free functions as a basic building block in the language. This enables lots of things and makes a lot of things more difficult (or in most cases different from what people are used to).

One of the biggest advantages with functional programming is that the order of execution of side-effect-free functions is not important. For example, in Erlang this is used to enable concurrency in a very transparent way. 
And because functions in functional languages behave very similar to mathematical functions it's easy to translate those into functional languages. In some cases, this can make code more readable.

Traditionally, one of the big disadvantages of functional programming was also the lack of side effects. It's very difficult to write useful software without IO, but IO is hard to implement without side effects in functions. So most people never got more out of functional programming than calculating a single output from a single input. In modern mixed-paradigm languages like F# or Scala this is easier.

Lots of modern languages have elements from functional programming languages. C# 3.0 has a lot functional programming features and you can do functional programming in Python too. I think the reasons for the popularity of functional programming is mostly because of two reasons: Concurrency is getting to be a real problem in normal programming because we're getting more and more multiprocessor computers; and the languages are getting more accessible.

blocks|key|3767484|text|除了其他答案之外，用纯函数术语来描述解决方案会迫使人们更好地理解问题。相反，以函数式的方式思考会发展出更好的解决问题的技能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3767485|*要么是因为函数范式更好，要么是因为它将提供一个额外的攻角。|3767486|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In addition to the other answers, casting the solution in pure functional terms forces one to understand the problem better. Conversely, thinking in a functional style will develop better* problem solving skills.

*Either because the functional paradigm is better or because it will afford an additional angle of attack.

blocks|key|5178155|text|检出Why+Functional+Programming+Matters|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5178156|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf^0|2|Y|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Checkout <a href="http://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf" rel="nofollow noreferrer">Why Functional Programming Matters</a>

blocks|key|3767689|text|我一定很笨拙，但我还是不明白。有没有像F#这样的函数式语言编写的小应用程序的实际例子，在那里你可以查看源代码，看看为什么使用这种方法比C#更好？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3767690|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I must be dense, but I still don't get it. Are there any actual examples of small app's written in a functional language like F# where you can look at the source code and see how and why it was better to use such an approach than, say, C#?

blocks|key|5178314|text|对我来说，主要的加分是它固有的并行性，特别是当我们现在从更多的MHz转向越来越多的内核时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5178315|我认为它不会成为下一个编程范例并完全取代OO类型方法，但我确实认为我们将需要用函数式语言编写一些代码，或者我们的通用语言将成长为包含更多的函数式结构。|5178316|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The main plus for me is its inherent parallelism, especially as we are now moving away from more MHz and towards more and more cores.

I don't think it will become the next programming paradigm and completely replace OO type methods, but I do think we will get to the point that we need to either write some of our code in a functional language, or our general purpose languages will grow to include more functional constructs.

blocks|key|5178407|text|在阅读了“黑客与画家”之后，我实际上正在学习LISP，我相信我会从LISP中学到一些东西，这些东西会让我更好地理解我编写的其他程序。现在我想我不会仅仅因为1995年的某个家伙创建了一个后来成为Yahoo+Stores的网站，就在我的日常生活中使用LISP。所以无论如何这都是双赢的(如果它流行起来，我赢了，如果没有，我会得到更多关于如何编程和东西如何工作的观点)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5178408|现在..。关于另一个相关的问题，我认为随着明年32核处理器的到来，编程会有很大的变化吗？是的，我不知道它是否会是函数式编程，但是……我很确定会有不同的东西！|5178409|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'm actually learning LISP after reading Hackers and Painters and I do believe I will LEARN something from LISP that will give me a better undertanding of everything else I program. Now I dont think I will actually be using LISP in my everyday just because some guy in 1995 created a website that became Yahoo Stores. So its a win-win anyway (if it catches on I win if not, I get more points of views on how to program and how stuff works)

Now... on another question kinda related, do I think programming will change a lot with 32 cores procs arriving next year? YES, I dont know if it will be functional programming but... im pretty sure there will be something diferent!

blocks|key|5178613|text|我同意第一点，但时代不同了。公司会做出回应，即使他们是后期采用者，如果他们看到有优势的话。生活是动态的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5178614|90年代末，他们在斯坦福大学教授Haskell和ML。我敢肯定，像卡内基梅隆大学、麻省理工学院、斯坦福大学和其他好的学校都在向学生们展示它。|5178615|我同意大多数“在web上公开关系数据库”的应用程序将在很长一段时间内继续保持这种状态。Java、.NET、RoR和PHP已经发展出一些非常好的解决方案来解决这个问题。|5178616|您发现了一些重要的问题:它可能是不能通过其他方法轻松解决的问题，这些方法将促进函数式编程。那会是什么？|5178617|庞大的多核硬件和云计算是否会推动它们向前发展？|5178618|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I agree with the first point, but times change. Corporations will respond, even if they're late adopters, if they see that there's an advantage to be had. Life is dynamic.

They were teaching Haskell and ML at Stanford in the late 90s. I'm sure that places like Carnegie Mellon, MIT, Stanford, and other good schools are presenting it to students.

I agree that most "expose relational databases on the web" apps will continue in that vein for a long time. Java EE, .NET, RoR, and PHP have evolved some pretty good solutions to that problem.

You've hit on something important: It might be the problem that can't be solved easily by other means that will boost functional programming. What would that be?

Will massive multicore hardware and cloud computing push them along?

blocks|key|2923453|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2923454|大多数应用程序都很简单，可以用普通的面向对象方法来解决|blockquote|2923455|2923456|2923457|2923458|面向对象的方式并不总是“正常”的。这十年的标准是上个十年的边缘概念。|ordered-list-item|2923459|2923460|2923461|函数式编程是数学。Lisp+(用函数式programming):|2923462|替换Paul+Graham+on+Lisp|offset|length|2923463|所以对于这种20世纪50年代的语言为什么没有过时的简短解释是，它不是技术，而是数学，而数学不会变得陈旧。，|2923464|。比较Lisp的正确之处不在于20世纪50年代的硬件，而在于比方说1960年发现的快速排序算法，它仍然是最快的通用排序算法。|2923465|2923466|entityMap|0|LINK|mutability|MUTABLE|url|http://www.paulgraham.com/icad.html^0|0|0|0|0|0|0|0|0|0|2|J|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|14|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|15|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|17|7|@]|8|@]|9|$]]|$1|F|3|-4|4|5|6|18|7|@]|8|@]|9|$]]|$1|G|3|H|4|I|6|19|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|1A|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|L|3|M|4|I|6|1C|7|@]|8|@]|9|$]]|$1|N|3|O|4|5|6|1D|7|@]|8|@$P|1E|Q|1F|1|1G]]|9|$]]|$1|R|3|S|4|5|6|1H|7|@]|8|@]|9|$]]|$1|T|3|U|4|C|6|1I|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1J|7|@]|8|@]|9|$]]|$1|W|3|-4|4|5|6|1K|7|@]|8|@]|9|$]]]|X|$Y|$4|Z|10|11|9|$12|13]]]]

<blockquote>
Most applications are simple enough to be solved in normal OO ways
</blockquote>
<ol>
<li>OO ways have not always been &quot;normal.&quot; This decade's standard was last decade's marginalized concept.
</li>
<li>Functional programming is math. <a href="http://www.paulgraham.com/icad.html" rel="nofollow noreferrer">Paul Graham on Lisp</a> (replace Lisp by functional programming):
</li>
</ol>
<blockquote>
So the short explanation of why this
1950s language is not obsolete is that
it was not technology but math, and
math doesn’t get stale. The right
thing to compare Lisp to is not 1950s
hardware, but, say, the Quicksort
algorithm, which was discovered in
1960 and is still the fastest
general-purpose sort.
</blockquote>

blocks|key|2923565|text|即使您从未专业地使用过函数式语言，理解函数式编程也会使您成为一名更好的开发人员。它将给你一个新的视角来看待你的代码和编程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2923566|我说没有理由不去学习它。|2923567|我认为在混合函数式和命令式风格方面做得很好的语言是最有趣的，也是最有可能成功的。|2923568|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Even if you never work in a functional language professionally, understanding functional programming will make you a better developer. It will give you a new perspective on your code and programming in general. 

I say there's no reason to not learn it.

I think the languages that do a good job of mixing functional and imperative style are the most interesting and are the most likely to succeed.

blocks|key|714331|text|大多数应用程序都可以在这里插入您喜欢的语言、范例等来解决。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|714332|尽管这是真的，不同的工具可以用来解决不同的问题。Functional只允许另一个高(更高？)级别抽象，当正确使用时，可以更有效地完成我们的工作。|714333|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Most application can be solved in [insert your favorite language, paradigm, etc. here].

Although, this is true, different tools can be used to solve different problems. Functional just allows another high (higher?) level abstraction that allows to do our jobs more effectively when used correctly.

blocks|key|5178911|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5178912|大学并没有真正教授这门课(现在是这样吗？)|blockquote|5178913|5178914|5178915|我不知道现在的情况，但我在20世纪90年代中期的CS课程中同时学习了Miranda和Lisp。尽管后来没有使用纯函数式语言，但它影响了我解决问题的方式。|5178916|5178917|大多数应用程序都很简单，可以用普通的面向对象方法来解决|5178918|5178919|5178920|在90年代中期的CS课程中，OO+(使用Eiffel教授)几乎和函数式编程一样被教授。两者在当时都是非主流的。OO现在可能是“正常的”，但从来都不是这样的。|5178921|我很有兴趣看看F#是否是将FP推向主流的东西。|5178922|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|W|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|Y|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|11|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|12|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|13|7|@]|8|@]|9|$]]]|R|$]]

<blockquote>
 It's not really taught at universities (or is it nowadays?)
</blockquote>

I don't know about nowadays, but I was taught both Miranda and Lisp as part of my CS course in the mid 1990s. Despite not using a pure functional language since, it has influenced the way I solve problems.

<blockquote>
 Most applications are simple enough to be solved in normal OO ways
</blockquote>

In the same mid '90s CS course, OO (taught using Eiffel) was taught pretty much on a par with functional programming. Both were non-mainstream at the time. OO may be "normal" now, but it was not ever thus.

I'll be interested to see whether F# is the thing that pushes FP into the mainstream.

blocks|key|5178989|text|我认为其中一个原因是，有些人认为，一种语言是否会被接受的最重要的部分是该语言的有多好。不幸的是，事情很少会这么简单。例如，我认为Python被接受背后的最大因素并不是语言本身(尽管这很重要)。Python如此受欢迎的最大原因是其庞大的标准库和更大的第三方库社区。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5178990|像Clojure或F#这样的语言可能是这条规则的例外，因为它们是基于JVM/CLR构建的。因此，我对他们没有答案。|5178991|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think one reason is that some people feel that the most important part of whether a language will be accepted is how good the language is. Unfortunately, things are rarely so simple. For example, I would argue that the biggest factor behind Python's acceptance isn't the language itself (although that is pretty important). The biggest reason why Python is so popular is its huge standard library and the even bigger community of 3rd party libraries.

Languages like Clojure or F# may be the exception to the rule on this considering that they're built upon the JVM/CLR. As a result, I don't have an answer for them.

blocks|key|714429|text|F#可能会流行起来，因为微软正在推动它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|714430|优点：|714431|714432|F#将成为Visual+Studio下一个版本的一部分，微软正在建立社区已经有一段时间了-与知名客户合作的布道者、书籍和顾问，在MS+conferences.|unordered-list-item|714433|F#上的重要曝光是一流的|714434|语言，它是第一种具有真正强大基础的函数式语言(我并不是说Lisp、Haskell、|714435|+Erlang、Scala、OCaml没有很多库，它们只是没有.Net那么完整)|714436|对并行性的强大支持|714437|714438|Contra：|714439|即使你精通C#和.Net，|714440|F#也很难上手--至少对我来说是这样：(|714441|很难找到优秀的F#开发者|714442|714443|所以，我给F#+50:50的机会让它变得重要。其他函数式语言在不久的将来是不会实现的。|714444|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|16|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|17|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|18|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|1A|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1D|8|@]|9|@]|A|$]]|$1|U|3|V|5|G|7|1E|8|@]|9|@]|A|$]]|$1|W|3|X|5|G|7|1F|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1H|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|12|$]]

F# could catch on because Microsoft is pushing it.

Pro:

<ul>
<li>F# is going to be part of next version of Visual Studio </li>
<li>Microsoft is building community for some time now - evangelists, books, consultants that work with high profile customers, significant exposure at MS conferences.</li>
<li>F# is first class .Net language and it's the first functional language that comes with really big foundation (not that I say that Lisp, Haskell, Erlang, Scala, OCaml do not have lots of libraries, they are just not as complete as .Net is)</li>
<li>Strong support for parallelism </li>
</ul>

Contra: 

<ul>
<li>F# is very hard to start even if you are good with C# and .Net - at least for me :(</li>
<li>it will probably be hard to find good F# developers </li>
</ul>

So, I give 50:50 chance to F# to become important. Other functional languages are not going to make it in near future.

blocks|key|719903|text|因为FP在生产力、可靠性和可维护性方面具有显著的优势。多核可能是一个杀手级应用，尽管有大量遗留的code.Furthermore，但最终会让大公司改用它，即使是像C#这样的大型商业语言也因为许多核心问题而呈现出独特的功能风格-副作用根本不适合并发性和并行性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|719904|我不同意“普通”程序员不会理解它。他们会的，就像他们最终理解OOP一样(OOP即使不是更神秘，也同样奇怪)。|719905|此外，大多数大学都教授FP，许多甚至将其作为第一门编程课程来教授。|719906|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Because FP has significant benefits in terms of productivity, reliability and maintainability. Many-core may be a killer app that finally gets big corporations to switch over despite large volumes of legacy code.Furthermore, even big commercial languages like C# are taking on a distinct functional flavour as a result of many-core concerns - side effects simply don't fit well with concurrency and parallelism.

I do not agree that "normal" programmers won't understand it. They will, just like they eventually understood OOP (which is just as mysterious and weird, if not more so).

Also, most universities do teach FP, many even teach it as the first programming course.

blocks|key|3768666|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3768667|普通的公司程序员，例如和我一起工作的大多数人，不会理解它，大多数工作环境也不会让你在它里面编程|blockquote|3768668|3768669|3768670|不过，这只是个时间问题。一般的公司程序员都能学到当前最重要的东西。15年前，他们还不理解OOP。如果FP流行起来，你的“普通企业程序员”也会紧随其后。|3768671|3768672|大学并没有真正教授这门课(现在是这样吗？)|3768673|3768674|3768675|变化很大。在我的大学里，SML是学生接触的第一门语言。我相信麻省理工学院将LISP作为一年级课程来教授。当然，这两个例子可能不具有代表性，但我相信大多数大学至少会提供一些关于FP的选修课，即使他们没有将其作为必修课的一部分。|3768676|3768677|大多数应用程序都很简单，可以用普通的面向对象方法来解决|3768678|3768679|3768680|不过，这并不是“足够简单”的问题。FP中的解决方案会更简单(或者更易读、更健壮、更优雅、更高效)吗？许多事情都“简单到可以用Java解决”，但它仍然需要大量的代码。|3768681|在任何情况下，请记住，FP的支持者声称这是几十年来的下一个大事件。也许他们是对的，但请记住，当他们在5年前、10年前或15年前提出同样的主张时，他们并不是对的。|3768682|然而，有一件事肯定对他们有利，那就是最近，C#突然转向了FP，以至于它实际上将一代程序员变成了FP程序员，而他们甚至没有注意到这一点。这可能只是为FP“革命”铺平了道路。也许吧。;)|3768683|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|12|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|13|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|14|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|15|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|17|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|18|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|19|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|1A|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|P|3|Q|4|C|6|1C|7|@]|8|@]|9|$]]|$1|R|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|S|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]|$1|T|3|U|4|5|6|1F|7|@]|8|@]|9|$]]|$1|V|3|W|4|5|6|1G|7|@]|8|@]|9|$]]|$1|X|3|Y|4|5|6|1H|7|@]|8|@]|9|$]]|$1|Z|3|-4|4|5|6|1I|7|@]|8|@]|9|$]]]|10|$]]

<blockquote>
 The average corporate programmer, e.g.
 most of the people I work with, will
 not understand it and most work
 environments will not let you program
 in it
</blockquote>

That one is just a matter of time though. Your average corporate programmer learns whatever the current Big Thing is. 15 years ago, they didn't understand OOP.
IF FP catches on, your "average corporate programmers" will follow.

<blockquote>
 It's not really taught at universities
 (or is it nowadays?)
</blockquote>

Varies a lot. At my university, SML is the very first language students are introduced to.
I believe MIT teaches LISP as a first-year course. These two examples may not be representative, of course, but I believe most universities at the very least offer some optional courses on FP, even if they don't make it a mandatory part of the curriculum.

<blockquote>
 Most applications are simple enough to
 be solved in normal OO ways
</blockquote>

It's not really a matter of "simple enough" though. Would a solution be simpler (or more readable, robust, elegant, performant) in FP? Many things are "simple enough to be solved in Java", but it still requires a godawful amount of code.

In any case, keep in mind that FP proponents have claimed that it was the Next Big Thing for several decades now. Perhaps they're right, but keep in mind that they weren't when they made the same claim 5, 10 or 15 years ago.

One thing that definitely counts in their favor, though, is that recently, C# has taken a sharp turn towards FP, to the extent that it's practically turning a generation of programmers into FP programmers, without them even noticing. That might just pave the way for the FP "revolution". Maybe. ;)

blocks|key|3768769|text|函数式编程已经在IMHO上流行起来了，只是还不是很明显。这类语言的长处在于数学/算法，这也是光环团队将其用于TrueSkill的原因之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3768770|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Functional Programming has already caught on IMHO, it's just not very visible yet. The strength of such languages is mathematics/algorhithms, which is one of the reasons why the Halo Guys use it for their TrueSkill stuff.

blocks|key|2924282|text|在我看来，那些在大学时从未学习过Lisp或Scheme的人现在正在发现它。就像这个领域的许多事情一样，有一种炒作和创造高期望的趋势……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2924283|一切都会过去的。|2924284|函数式编程很棒。然而，它不会接管世界。C、C%2B%2B、Java、C#等仍将存在。|2924285|我认为这将带来更多的跨语言能力-例如，用函数式语言实现东西，然后用其他语言访问这些东西。|2924286|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It seems to me that those people who never learned Lisp or Scheme as an undergraduate are now discovering it. As with a lot of things in this field there is a tendency to hype and create high expectations...

It will pass.

Functional programming is great. However, it will not take over the world. C, C++, Java, C#, etc will still be around.

What will come of this I think is more cross-language ability - for example implementing things in a functional language and then giving access to that stuff in other languages.

blocks|key|3769001|text|一段时间以来，事情一直在朝着功能方向发展。在过去的几年里，Ruby和Python这两个很酷的新成员都比它们之前的语言更接近函数式语言-以至于一些Lisper已经开始支持其中的一个或另一个“足够接近”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3769002|随着大规模并行硬件给每个人带来进化压力，函数式语言成为处理这些变化的最佳场所，认为Haskell或F#将成为下一个大事件的想法并不像以前那样飞跃。|3769003|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Things have been moving in a functional direction for a while. The two cool new kids of the past few years, Ruby and Python, are both radically closer to functional languages than what came before them — so much so that some Lispers have started supporting one or the other as "close enough." 

And with the massively parallel hardware putting evolutionary pressure on everyone — and functional languages in the best place to deal with the changes — it's not as far a leap as it once was to think that Haskell or F# will be the next big thing.

blocks|key|720176|text|你最近有没有关注编程语言的发展？所有主流编程语言的每个新版本似乎都从函数式编程中借用了越来越多的功能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|720177|720178|闭包、匿名函数、作为值传递和返回函数曾经是只有Lisp和ML黑客才知道的奇异特性。但是渐渐地，C#、Delphi、Python、Perl、Javascript都增加了对闭包的支持。没有closures.|unordered-list-item|720179|Several语言，任何后起之秀的语言都不可能被认真对待，特别是Python语言、C#语言和Ruby语言都具有对列表理解和列表生成器的本机支持。|720180|ML在1973年开创了泛型编程，但对泛型(“参数多态性”)的支持只是在最近5年左右的时间里才成为行业标准。如果我没记错的话，Fortran在2003年支持泛型，紧随其后的是Java2004,2005年的C#，2008年的Delphi。(我知道C%2B%2B从1979年就开始支持模板了，但是关于C%2B%2B标准语言的90%25的讨论都是以“这里有恶魔”开始的。)|720181|720182|是什么让这些特性对程序员有吸引力？这应该是显而易见的：它帮助程序员编写更短的代码。如果想要保持竞争力，未来的所有语言都将至少支持闭包。在这方面，函数式编程已经成为主流。|offset|length|style|BOLD|720183|720184|大多数应用程序都很简单，可以用普通的面向对象方法来解决|blockquote|720185|720186|720187|谁说不能用函数式编程来做简单的事情呢？并不是每个函数式程序都需要是编译器、定理证明器或大规模并行电信交换机。除了我更复杂的项目之外，我还经常使用F#编写临时的一次性脚本。|720188|entityMap^0|0|0|0|0|0|0|R|D|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|14|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@$M|17|N|18|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|1A|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1D|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|Z|$]]

Have you been following the evolution of programming languages lately? Every new release of all mainstream programming languages seems to borrow more and more features from functional programming.

<ul>
<li>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.</li>
<li>Several languages, notably Python, C#, and Ruby have native support for list comprehensions and list generators.</li>
<li>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".)</li>
</ul>

What makes these features appealing to programmers? It should be plainly obvious: it helps programmers write shorter code. All languages in the future are going to support -- at a minimum -- closures if they want to stay competitive. In this respect, functional programming is already in the mainstream.

<blockquote>
 Most applications are simple enough to
 be solved in normal OO ways
</blockquote>

Who says can't use functional programming for simple things too? Not every functional program needs to be a compiler, theorem prover, or massively parallel telecommunications switch. I regularly use F# for ad hoc throwaway scripts in addition to my more complicated projects.

blocks|key|3769265|text|我不认为函数式编程“流行”有任何问题，因为它已经使用了大约40年(作为一种编程风格)。每当OO程序员编写支持不可变对象的干净代码时，该代码就借用了函数式概念。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3769266|然而，强制使用函数式风格的语言现在得到了大量的虚拟墨迹，这些语言在未来是否会成为主导还是一个悬而未决的问题。我自己的猜测是，混合的、多范式的语言，如Scala或OCaml，很可能会以与纯面向对象语言(Smalltalk、Beta等)相同的方式主导“纯粹的”函数式语言。影响了主流编程，但并没有成为最广泛使用的符号。|offset|length|3769267|最后，我忍不住要指出，你的评论re+FP与我几年前从过程程序员那里听到的评论高度相似：|3769268|3769269|“一般”的程序员不理解它。|unordered-list-item|3769270|它没有被广泛教授。|3769271|任何你可以用它写的程序都可以用当前的技术以另一种方式编写。|3769272|3769273|正如图形用户界面和“作为业务模型的代码”是帮助OO得到更广泛认可的概念一样，我相信增加对不变性和更简单(大规模)并行的使用将帮助更多的程序员看到函数式方法提供的好处。但是，正如我们在the+past+50+or+so+years中学到的那样，这构成了整个数字计算机编程的历史，我认为我们仍然有很多东西需要学习。二十年后，程序员将惊讶地回顾我们目前使用的工具的原始性质，包括现在流行的OO和FP语言。|3769274|entityMap|0|LINK|mutability|MUTABLE|url|http://www.scala-lang.org/|1|http://ocaml.org/|2|http://blip.tv/file/1472720^0|0|22|5|0|28|5|1|0|0|0|0|0|0|0|2J|N|2|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]|$D|19|E|1A|1|1B]]|A|$]]|$1|F|3|G|5|6|7|1C|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1E|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|1F|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|1G|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1I|8|@]|9|@$D|1J|E|1K|1|1L]]|A|$]]|$1|S|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]|10|$5|V|W|X|A|$Y|11]]|12|$5|V|W|X|A|$Y|13]]]]

I don't think that there's any question about the functional approach to programming "catching on", because it's been in use (as a style of programming) for about 40 years. Whenever an OO programmer writes clean code that favors immutable objects, that code is borrowing functional concepts.

However, languages that enforce a functional style are getting lots of virtual ink these days, and whether those languages will become dominant in the future is an open question. My own suspicion is that hybrid, multi-paradigm languages such as <a href="http://www.scala-lang.org/" rel="noreferrer">Scala</a> or <a href="http://ocaml.org" rel="noreferrer">OCaml</a>
will likely dominate over "purist" functional languages in the same way that pure OO language (Smalltalk, Beta, etc.) have influenced mainstream programming but haven't ended up as the most widely-used notations.

Finally, I can't resist pointing out that your comments re FP are highly parallel to the remarks I heard from procedural programmers not that many years ago:

<ul>
<li>The (mythical, IMHO) "average" programmer doesn't understand it.</li>
<li>It's not widely taught.</li>
<li>Any program you can write with it can be written another way with current techniques.</li>
</ul>

Just as graphical user interfaces and "code as a model of the business" were concepts that helped OO become more widely appreciated, I believe that increased use of immutability and simpler (massive) parallelism will help more programmers see the benefits that the functional approach offers. But as much as we've learned in <a href="http://blip.tv/file/1472720" rel="noreferrer">the past 50 or so years</a> that make up the entire history of digital computer programming, I think we still have much to learn. Twenty years from now, programmers will look back in amazement at the primitive nature of the tools we're currently using, including the now-popular OO and FP languages.

blocks|key|2924612|text|我不认为大多数现实的人认为函数式编程会流行起来(成为像OO一样的主要范例)。毕竟，大多数业务问题都不是很好的数学问题，而是移动数据并以各种方式显示数据的复杂命令性规则，这意味着它不适合纯函数式编程范式(+monad的学习曲线远远超过OO)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2924613|OTOH，函数式编程让编程变得有趣。它让你领略到宇宙基本数学简洁表达的内在、永恒之美。人们说学习函数式编程会让你成为更好的程序员。这当然是非常主观的。我个人也不认为这是完全正确的。|2924614|它会让你成为更好的有知觉的人。|2924615|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I don't think most realistic people think that functional programming will catch on (becomes the main paradigm like OO). After all, most business problems are not pretty math problems but hairy imperative rules to move data around and display them in various ways, which means it's not a good fit for pure functional programming paradigm (the learning curve of monad far exceeds OO.)

OTOH, functional programming is what makes programming fun. It makes you appreciate the inherent, timeless beauty of succinct expressions of the underlying math of the universe. People say that learning functional programming will make you a better programmer. This is of course highly subjective. I personally don't think that's completely true either.

It makes you a better sentient being.

blocks|key|5180050|text|哇-这是一个有趣的讨论。对此我有自己的想法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5180051|FP使得一些任务相对简单(与非FP语言相比)。非FP语言已经开始从FP中汲取灵感，所以我怀疑这种趋势将会继续下去，我们将看到更多的合并，这应该会帮助人们更容易地跳跃到FP。|5180052|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Wow - this is an interesting discussion. My own thoughts on this:

FP makes some tasks relatively simple (compared to none-FP languages).
None-FP languages are already starting to take ideas from FP, so I suspect that this trend will continue and we will see more of a merge which should help people make the leap to FP easier.

blocks|key|2924898|text|我总是对下一件大事持怀疑态度。很多时候，下一个大事件纯粹是历史的偶然，无论技术好不好，都在正确的时间出现在正确的地方。例如:+C%2B%2B、Tcl/Tk、Perl。所有有缺陷的技术，都非常成功，因为它们要么被认为解决了当时的问题，要么几乎与根深蒂固的标准相同，或者两者兼而有之。函数式编程可能确实很棒，但这并不意味着它会被采用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2924899|但是我可以告诉你为什么人们对函数式编程感到兴奋:很多程序员都有过一种“转换体验”，他们发现使用函数式语言可以使他们的工作效率提高一倍(或者可能是十倍)，同时生成更具弹性的代码，并且错误更少。这些人认为函数式编程是一个秘密武器；Paul+Graham的Beating+the+Averages就是一个很好的例子。哦，那他的申请呢？电子商务web应用程序。|offset|length|2924900|自2006年初以来，也有一些关于函数式编程和并行性的热议。至少从1984年开始，像Simon+Peyton+Jones这样的人就一直在担心并行性问题，所以在函数式语言解决多核问题之前，我不会屏息等待。但它确实解释了现在的一些额外的议论。|2924901|总体而言，美国大学在函数式编程教学方面做得很差。teaching+intro+programming+using+Scheme有一个强大的核心支持，Haskell在那里也有一些支持，但在教授函数式程序员高级技术方面却很少。我曾在哈佛大学教授过这样一门课程，今年春天我还将在塔夫斯大学教授这门课程。本杰明·皮尔斯曾在宾夕法尼亚大学教授过这样一门课程。我不知道保罗·胡达克是否在耶鲁做过什么。欧洲的大学正在做更好的工作；例如，在丹麦、荷兰、瑞典和英国的重要地方强调函数式编程。我对澳大利亚发生的事情知之甚少。|2924902|entityMap|0|LINK|mutability|MUTABLE|url|http://www.paulgraham.com/avg.html|1|http://research.microsoft.com/en-us/people/simonpj/default.aspx|2|http://htdp.org/^0|0|3H|K|0|0|15|I|1|0|O|13|2|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@$D|15|E|16|1|17]]|A|$]]|$1|J|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|U]]]]

I'm always skeptical about the Next Big Thing. Lots of times the Next Big Thing is pure accident of history, being there in the right place at the right time no matter whether the technology is good or not. Examples: C++, Tcl/Tk, Perl. All flawed technologies, all wildly successful because they were perceived either to solve the problems of the day or to be nearly identical to entrenched standards, or both. Functional programming may indeed be great, but that doesn't mean it will be adopted.

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 <a href="http://www.paulgraham.com/avg.html" rel="noreferrer">Beating the Averages</a>. Oh, and his application? E-commerce web apps.

Since early 2006 there has also been some buzz about functional programming and parallelism. Since people like <a href="http://research.microsoft.com/en-us/people/simonpj/default.aspx" rel="noreferrer">Simon Peyton Jones</a> have been worrying about parallelism off and on since at least 1984, I'm not holding my breath until functional languages solve the multicore problem. But it does explain some of the additional buzz right about now.

In general, American universities are doing a poor job teaching functional programming. There's a strong core of support for <a href="http://htdp.org/" rel="noreferrer">teaching intro programming using Scheme</a>, 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.

blocks|key|2924938|text|它已经在Hadoop中流行了Map/reduce|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2924939|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Hadoop^0|4|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

It has already caught on with Map/reduce in <a href="http://en.wikipedia.org/wiki/Hadoop" rel="nofollow noreferrer">Hadoop</a>

blocks|key|2924976|text|我认为函数式编程语言成为“下一个大事件”的最大争论是，在未来，多核处理器将成为标准。程序员将不得不利用这一点，而函数式编程为构建顶级并发软件提供了非常好的可能性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2924977|附注:当我在波士顿大学上大学的时候(98-02)，我们花了一个学期的学习计划，这是LISP的近亲。当我们第一次开始学习它的时候，我想撕裂我的头发。在课程结束时，这是非常自然的。|2924978|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think the biggest argument for functional programming languages to become the "next big thing" is that in the future multi-core processors will be the norm. Programmers will have to take advantage of that, and functional programming offers really wonderful possibilities for building top of the line concurrent software.

P.S. When I was in college at Boston University ('98-'02) we spent a semester learning Scheme which is a close cousin of LISP. When we first started learning it, I wanted to rip my hair out. By the end of the course it was very natural.

blocks|key|2925039|text|我没有看到任何人提到房间里的大象，所以我认为这取决于我:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2925040|JavaScript是一种函数式语言。随着越来越多的人使用JS做更高级的事情，特别是利用jQuery、Dojo和其他框架的优点，FP将由web开发人员的后门引入。|2925041|与闭包相结合，FP使JS代码变得非常轻巧，但仍然具有可读性。|2925042|干杯，PS|2925043|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I don't see anyone mentioning the elephant in the room here, so I think it's up to me :)

JavaScript is a functional language. As more and more people do more advanced things with JS, especially leveraging the finer points of jQuery, Dojo, and other frameworks, FP will be introduced by the web-developer's back-door. 

In conjunction with closures, FP makes JS code really light, yet still readable. 

Cheers,
PS

blocks|key|3769885|text|我不知道它是否会流行起来，但从我的调查来看，函数式语言几乎肯定值得学习，并将使您成为更好的程序员。仅仅是理解引用透明性就能让很多设计决策变得容易得多--由此产生的程序也更容易推理。基本上，如果你遇到一个问题，那么它往往只是一个单一函数的输出问题，而不是一个状态不一致的问题，这可能是由具有副作用的不透明语言中的数百个类/方法/函数中的任何一个引起的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3769886|FP的无状态特性更自然地映射到web的无状态特性，因此函数式语言更容易用于更优雅、更RESTFUL的web应用程序。与JAVA和.NET框架相比，它们需要求助于可怕的丑陋技巧，如视图状态和会话密钥来维护应用程序状态，并在web等本质上无状态的功能平台上维护有状态命令式语言的抽象(有时会相当泄漏)。|3769887|而且，您的应用程序越无状态，它就越容易进行并行处理。如果你的网站碰巧变得流行起来，这对网络来说非常重要。仅仅向站点添加更多的硬件来获得更好的性能并不总是那么简单。|3769888|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I don't know whether it will catch on or not, but from my investigations, a functional language is almost certainly worth learning, and will make you a better programmer. Just understanding referential transparency makes a lot of design decisions so much easier- and the resulting programs much easier to reason about. Basically, if you run into a problem, then it tends to only be a problem with the output of a single function, rather than a problem with an inconsistant state, which could have been caused by any of the hundreds of classes/methods/functions in an imparative language with side effects.

The stateless nature of FP maps more naturally to the stateless nature of the web, and thus functional languages lend themselves more easily to more elegant, RESTFUL webapps. Contrast with JAVA and .NET frameworks that need to resort to horribly ugly HACKS like VIEWSTATE and SESSION keys to maintain application state, and maintain the (occasionally quite leaky) abstraction of a stateful imperative language, on an essentially stateless functional platform like the web. 

And also, the more stateless your application, the more easily it can lend itself to parallel processing. Terribly important for the web, if your website happens to get popular. It's not always straightforward to just add more hardware to a site to get better performance.

blocks|key|2925109|text|我敢打赌，当您使用以下命令时，您并不知道自己是函数式编程：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2925110|海龟Excel+formulas|2925111|Quartz+Composer|unordered-list-item|2925112|
|2925113|JavaScript|2925114|2925115|Logo+(海龟graphics)|2925116|2925117|LINQ|2925118|2925119|SQL|2925120|2925121|Underscore.js+(或)，D3+)|2925122|2925123|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|12|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|13|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|15|8|@]|9|@]|A|$]]|$1|N|3|H|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|17|8|@]|9|@]|A|$]]|$1|Q|3|H|5|6|7|18|8|@]|9|@]|A|$]]|$1|R|3|S|5|F|7|19|8|@]|9|@]|A|$]]|$1|T|3|H|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|1B|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|Y|$]]

I bet you didn't know you were functional programming when you used:

<ul>
<li>Excel formulas</li>
<li>Quartz Composer</li>
<li>JavaScript</li>
<li>Logo (Turtle graphics)</li>
<li>LINQ</li>
<li>SQL</li>
<li>Underscore.js (or Lodash),
D3</li>
</ul>

blocks|key|3770020|text|我认为你的问题的答案更多地在于“适合这项工作的正确工具”这句话，而不是最热门的东西。总会有热门的新技术出现，也总会有一些人抓住它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3770021|函数式语言已经存在了一段时间了，只是现在它们才得到了更多的关注。|3770022|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think the answer to your question lies more in the statement, "the right tool for the job", than the hottest thing. There will always be hot new technologies, and there will always be those who jump on them.

Functional languages have been around for a while, it's just now they are getting more press.

blocks|key|715161|text|它之所以流行，是因为它是控制复杂性的最佳工具。请参见：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|715162|Simon+Peyton-Jones+talk的|715163|幻灯片109-116+"A+Taste+of+Haskell“|unordered-list-item|715164|”下一个主流编程语言:游戏开发人员的视角“，作者Tim+Sweeney|715165|715166|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

It's catching on because it's the best tool around for controlling complexity. 
See: 
 - slides 109-116 of Simon Peyton-Jones talk "A Taste of Haskell" 
 - "The Next Mainstream Programming Language: A Game Developer's Perspective" by Tim Sweeney

blocks|key|5180829|text|呃，很抱歉我是个书呆子，但它已经流行起来了--我们叫它Excel。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5180830|http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/|offset|length|5180831|在计算机上运行的绝大多数程序都是用Excel或许多流行的克隆软件之一编写的。|5180832|(有许多程序会多次运行，而用Excel编写的程序往往不是这样的-大多数Excel程序都有一个运行实例)|5180833|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1V|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@$D|S|E|T|1|U]]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|C]]]]

Uh, sorry to be a pedant, but it has already caught on - we call it Excel.

<a href="http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/" rel="nofollow noreferrer">http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/</a>

The vast majority of programmes that run on computers are written in Excel or one of the many popular clones of it.

(there are many programmes that are run many times, and programmes written in Excel tend NOT to be ones of these - most Excel programmes have 1 run instance)

blocks|key|2925364|text|可以肯定的是，FP是下一个最佳范例。下一步是使用哪种语言，这是很难的，但我相信可能是Haskell、F#、Clojure、Ocaml或Erlang。或者可以是具有更多FP构造和对并行性/性能的更好支持的Python，或者也可以是具有parrot的Perl6看起来非常有趣。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2925365|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

FP is the next best paradigm that is for sure. Now which language could be the next step, That is the hard stuff but I believe could be Haskell, F#, Clojure, Ocaml or Erlang. Or could be Python with more FP constructs and better support for parallelism/performance or also Perl 6 with parrot looks very interesting.

blocks|key|3770237|text|我想是在1994年，乌得勒支大学教授函数式编程，直到最近几年，OOP才开始在“现实世界”流行起来。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3770238|没有“简单的应用程序”这回事。;-)|unordered-list-item|3770239|3770240|我认为，当我们开始在硬件中获得越来越多的内核时，对软件的一些关键部分进行(接近)副作用的免费编程将是必不可少的。给函数式编程多一点时间。而C#当前和未来版本中的函数式功能将大大有助于那些公司程序员在没有意识到的情况下为函数式编程做好准备……|3770241|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

<ul>
<li>How long did it take OOP to get understood by the average corporate programmer...?</li>
<li>I was taught functional programming at Utrecht University in - I think - 1994 and only see it start to catch on "in the real world" in the last couple of years.</li>
<li>There is no such thing as a "simple application". ;-)</li>
</ul>

I think that (approaching) side effect free programming for some key parts of software will be essential when we start to get more and more cores in our hardware. Give functional programming a bit more time. And the functional sprinkling in current and future versions of C# will go a long way in preparing those corporate programmers for functional programming without them even realising it...

blocks|key|3770277|text|我的观点是，随着微软将其进一步推向主流，它将会流行起来。对我来说，它之所以有吸引力，是因为它能为我们做些什么，因为它是一个新的挑战，也因为它对未来的工作机会感到不满。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3770278|一旦掌握了它，它将成为另一个工具，进一步帮助我们提高程序员的工作效率。|3770279|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

My view is that it will catch on now that Microsoft have pushed it much further into the mainstream. For me it's attractive because of what it can do for us, because it's a new challenge and because of the job opportunities it resents for the future.

Once mastered it will be another tool to further help make us more productive as programmers.

blocks|key|2925549|text|一些想法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2925550|2925551|从Lisp和Fortran开始，FP和命令式编程(OO、结构化等)之间的争论就一直很激烈。我认为你提出了很好的问题，但认识到它们并不是特别新。|unordered-list-item|2925552|关于FP的喧嚣的一部分是，我们似乎认识到并发是非常困难的，而OO+(例如Java)中的锁和其他机制只是一种解决方案。FP提供了一个令人耳目一新的巨大变化，比如Actor和无状态计算的力量。对于那些正在与OO搏斗的人来说，appealing.|2925553|Yes，学校教授FP的前景似乎很好。事实上，滑铁卢大学和其他大学在第一年的课程中提供了(reference+here).|offset|length|2925554|Regarding普通程序员的计划，我相信早在20世纪90年代初就有人给出了反对C%2B%2B的相同理由。看看发生了什么。如果企业可以通过一项技术获得优势，你可以打赌人们将接受培训。|2925555|2925556|这并不是说这是一件确定的事情，也不是说在3-5年内不会有反弹(总是如此)。然而，FP的趋势是有价值的，值得关注。|2925557|entityMap|0|LINK|mutability|MUTABLE|url|http://compsci.ca/blog/computer-science-at-waterloo-the-new-scheme-of-things/^0|0|0|0|0|18|E|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|12|8|@]|9|@$J|13|K|14|1|15]]|A|$]]|$1|L|3|M|5|E|7|16|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

Some thoughts:

<ul>
<li>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.</li>
<li>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.</li>
<li>Yes, schools teach FP. In fact, the University of Waterloo and others offer Scheme in first year classes (<a href="http://compsci.ca/blog/computer-science-at-waterloo-the-new-scheme-of-things/" rel="nofollow noreferrer">reference here</a>).</li>
<li>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. </li>
</ul>

This is not to say that it is a sure thing, or that there won't be a backlash in 3-5 years (as there always is). However, the trend towards FP has merit and is worth watching.

blocks|key|715283|text|当我读到Epic+Games的Tim+Sweeney的“下一个主流编程语言:游戏开发者的视角”时，我的第一个想法是--我学会了Haskell。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|715284|PPT|offset|length|715285|Google's+HTML+Version|715286|entityMap|0|LINK|mutability|MUTABLE|url|http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt|1|http://209.85.129.132/search?q=cache:vEhsoTFOx4sJ:www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt%2Bgears%2Bof%2Bwar%2Bdeveloper%2Bfuture%2Blanguage&hl=lv&ct=clnk&cd=1^0|0|0|3|0|0|0|L|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

When reading "The Next Mainstream Programming Language: A Game Developer’s Perspective" by Tim Sweeney, Epic Games, my first thought was - I got to learn Haskell.

<a href="http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt" rel="nofollow noreferrer">PPT</a>

<a href="http://209.85.129.132/search?q=cache:vEhsoTFOx4sJ:www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt+gears+of+war+developer+future+language&amp;hl=lv&amp;ct=clnk&amp;cd=1" rel="nofollow noreferrer">Google's HTML Version</a>

blocks|key|5181218|text|Slava+Akhmechet上有一篇很棒的文章，叫做Functional+Programming+For+The+Rest+of+Us+(这篇文章让我了解了FP+btw)。在FP带来的好处中，他不同寻常地强调了以下几点(我相信这有助于吸引软件工程师)：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|5181219|辅助校样和辅助校样单元Testing|5181220|Debugging|unordered-list-item|5181221|
|5181222|Concurrency|5181223|5181224|Hot+|5181225|5181226|+Deployment|5181227|5181228|Machine+Optimizations|5181229|5181230|然后继续讨论更多传统上讨论的FP方面的优点，如高阶函数、currying、惰性计算、优化、抽象控制结构(尽管不讨论monads)、无限数据结构、严格性、延续、模式匹配、闭包等。|5181231|强烈推荐！|5181232|entityMap|0|LINK|mutability|MUTABLE|url|http://www.defmacro.org/|1|http://www.defmacro.org/ramblings/fp.html^0|0|F|0|R|15|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]|$A|1E|B|1F|1|1G]]|C|$]]|$1|D|3|E|5|6|7|1H|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1I|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|1J|8|@]|9|@]|C|$]]|$1|K|3|L|5|H|7|1K|8|@]|9|@]|C|$]]|$1|M|3|J|5|6|7|1L|8|@]|9|@]|C|$]]|$1|N|3|O|5|H|7|1M|8|@]|9|@]|C|$]]|$1|P|3|J|5|6|7|1N|8|@]|9|@]|C|$]]|$1|Q|3|R|5|H|7|1O|8|@]|9|@]|C|$]]|$1|S|3|J|5|6|7|1P|8|@]|9|@]|C|$]]|$1|T|3|U|5|H|7|1Q|8|@]|9|@]|C|$]]|$1|V|3|-4|5|6|7|1R|8|@]|9|@]|C|$]]|$1|W|3|X|5|6|7|1S|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|1T|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|1U|8|@]|9|@]|C|$]]]|11|$12|$5|13|14|15|C|$16|17]]|18|$5|13|14|15|C|$16|19]]]]

There's a great article from <a href="http://www.defmacro.org/" rel="nofollow noreferrer">Slava Akhmechet</a> called <a href="http://www.defmacro.org/ramblings/fp.html" rel="nofollow noreferrer">Functional Programming For The Rest of Us</a> (this was the article that got me into FP btw). Amongst the benefits FP brings, he unorthodoxly emphasizes the following (which I believe contributes to the appeal for software engineers):

<ul>
<li>Unit Testing</li>
<li>Debugging</li>
<li>Concurrency</li>
<li>Hot Code Deployment</li>
<li>Machine Assisted Proofs and Optimizations</li>
</ul>

And then goes on to discuss the goodness of more traditionally discussed aspects of FP like higher order functions, currying, lazy evaluation, optimization, abstracting control structures (although not discussing monads), infinite data structures, strictness, continuations, pattern matching, closures and so on.

Highly recommended !

blocks|key|5181303|text|很多人都提到过函数式语言。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5181304|但是除了Javascript之外，现在使用的一些最常用的函数式语言。|5181305|Excel、SQL、XSLT、XQuery、J和K在金融领域得到了广泛的应用。|5181306|当然是Erlang。|5181307|所以我要说，从这个列表中可以看出，函数式编程技术每天都在主流中使用。|5181308|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Lots of people have mentioned Functional Languages. 

But some of the Most commonly used Functional Languages in use today besides Javascript.

Excel, SQL, XSLT, XQuery, J and K are used in financial realm. 

Of course Erlang.

So I would say that from that list that Functional Programming techniques are used in mainstream every day.

blocks|key|3770842|text|函数式编程很可能是工程师和科学家用来解决他们所面临的问题的工具。它不会像早期的语言那样占用整个世界。然而，最难击败的产品是Excel，如果我是一名工程师，需要做计算，Excel是很棒的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3770843|然而，F#将是另一个来源，可能会满足非计算机科学家的设计需求。让我们面对它吧，计算机科学家在创造一种全新的做事方式方面做了大量的工作。面向对象编程是很棒的。但有时你只需要一种方法来解一个方程，得到一个解，然后用图表表示出来。就这样。然后，像F#这样的语言就可以填补这一空白。或者你可能想要构建一个有限状态机，F#也可以是解决方案之一，但是C也可以是一个解决方案。|3770844|但在并行处理方面，Excel大放异彩，随着时间的推移，F#也会出现。不过以一种友好的方式，F#=友好。|3770845|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Functional Programming will likely be a tool that is used by Engineers, Scientists to solve the problems that they are facing. It isn't going to take the world like earlier langages. However, the hard product to beat is Excel, if I am an engineer and need to do calculations, Excel is awesome.

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.

But when it comes to parallel processing, Excel shines and in time F# will be there as well. In a friendly manner though, F#= friendly.

blocks|key|2925974|text|讨论中遗漏的一点是，最好的类型系统是在当代FP语言中找到的。更重要的是，编译器可以自动推断所有(或至少大部分)类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2925975|有趣的是，人们在编写Java程序时花了一半的时间来编写类型名称，然而Java到目前为止还不是类型安全的。虽然您可能永远不会在Haskell程序中编写类型(除非作为一种编译器检查的文档)，并且代码是100%25类型安全的。|2925976|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

A point missed in the discussion is that the best type systems are found in contemporary FP languages. What's more, compilers can infer all (or at least most) types automatically.

It is interesting that one spends half the time writing type names when programming Java, yet Java is by far not type safe. While you may never write types in a Haskell programm (except as a kind of compiler checked documentation) and the code is 100% type safe.

blocks|key|5181657|text|微软真的在推动F#在Visual+Studio上的下一个版本。它是一种混合语言，比如Scala，可以很好地与.net框架的其余部分集成。我认为很多微软公司都会使用它来加速高度并行的数据处理应用程序和函数的开发。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5181658|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Microsoft is really pushing F# with the next version on Visual Studio. It is a hybrid language such as Scala and integrates very nicely with the rest of the .net framework. I think a lot of Microsoft shops are going to use it to speed-up the development of highly parallel data-processing applications and functions.

blocks|key|2926035|text|我很难想象一种纯粹的函数式语言会成为当今的通用语言，这是我不会深入探讨的原因(因为它们是火种)。也就是说，无论使用哪种语言，函数式编程都能带来好处(如果它允许的话)。对我来说，这是一种更容易测试代码的能力。我经常和数据库打交道。我倾向于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2926036|2926037|编写一个获取数据、操作数据并返回数据的函数|ordered-list-item|2926038|编写一个非常简单的包装器来调用数据库，然后返回通过我的函数|2926039|传递数据的结果|2926040|这样做可以让我为我的操作函数编写单元测试，而不需要创建mock之类的东西。|2926041|我确实认为纯函数式语言非常有趣……我只是认为，对我来说，重要的是我们能从他们身上学到什么，而不是我们能用他们做什么。|2926042|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I have a hard time envisioning a purely functional language being the common language of the day, the reasons for which I won't get in to (because they're flame fodder). That being said, programming in a functional way can provide benefits no matter the language (if it allows such). For me, it's the ability to test my code much easier. I work with databases a lot... I tend to:

<ol>
<li>write a function that takes data, manipulates it, and returns data</li>
<li>write a dead simple wrapper that calls the database and then returns the result of passing that data through my function</li>
</ol>

Doing so allows me to write unit tests for my manipulation function, without the need to create mocks and the like.

I do think purely functional languages are very interesting... I just think it's what we can learn from them that matters to me, not what we can do with them.

blocks|key|721029|text|我要指出的是，您所说的关于函数式语言的所有内容，大多数人在大约20年前都在谈论面向对象的语言。那时候，关于OO是很常见的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|721030|*+The+average+corporate+programmer,+e.g.+most+of+the+people+I+work+with,+will+not+understand+it+and+most+work+environments+will+not+let+you+program+in+it
*+It's+not+really+taught+at+universities+(or+is+it+nowadays?)
*+Most+applications+are+simple+enough+to+be+solved+in+normal+IMPERATIVE+ways|code-block|syntax|javascript|721031|改变必须来自于某个地方。无论受过早期技术培训的人是否认为改变是不必要的，有意义和重要的改变都会发生。你认为OO的变化是好的，尽管当时所有的人都反对它？|721032|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I'd point out that everything you've said about functional languages, most people were saying about object-oriented langauges about 20 years ago. Back then it was very common to hear about OO:

<pre><code>* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
</code></pre>

Change has to come from somewhere. A meaningful and important change will make itself happen regardless of whether people trained in earlier technologies take the opinion that change isn't necessary. Do you think the change to OO was good despite all the people that were against it at the time?

blocks|key|2926143|text|我个人认为，对于分布式系统和多线程/并行编程，函数式编程很快就会有突破。只要它通过编程库与现有的OOP范型集成。所以..。纯粹的函数式方法--在我看来--仍将停留在理论层面。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2926144|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I personally think for distributed systems and multi-threaded/parallel programming functional programming will have a break-through soon. As long as it integrates with existing OOP paradigms through programming libraries. So... the purely functional approach - in my opinion - will remain academic.

blocks|key|721100|text|函数式编程已经存在很长一段时间了，因为LISP是最早拥有编译器的语言之一，而且从麻省理工学院的LISP机器开始。它不是一个新的范例(OO要新得多)，但主流的软件平台往往是用容易转换成汇编语言的语言编写的，它们的API非常喜欢命令式代码(UNIX和C，Windows和Macintosh，Pascal和后来的C)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|721101|我认为过去几年的新创新是各种API的流行，特别是对于平台API无关紧要的web开发。由于您不是直接对Win32+API或POSIX+API进行编码，因此人们可以自由地尝试函数式语言。|721102|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Functional programming has been around for a long time, since LISP was one of the earliest languages to have a compiler, and since MIT's LISP machines. It's not a new paradigm (OO is much newer) but the dominant software platforms have tended to be written in languages that translate easily to assembly language, and their APIs heavily favor imperative code (UNIX with C, Windows with C, and Macintosh with Pascal and later C).

I think the new innovation in the last few years is for a diversity of APIs to catch on, particularly for things like web development where the platform APIs are irrelevant. Since you're not coding directly to the Win32 API or the POSIX API, that gives people the freedom to try out functional languages.

blocks|key|2926350|text|如果人们看不到其他艺术的价值，他就不能理解他所选择的艺术的完美和不完美。遵循规则只允许在技术上发展到一定程度，然后学生和艺术家必须学习更多并寻求进一步的发展。学习其他艺术以及战略艺术都是有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2926351|谁没有通过观察别人的活动来更多地了解自己呢？学习剑术，学习吉他。要学习拳头，首先要学习商业。只学剑会使你心胸狭窄，不允许你向外成长。|2926352|--宫本武藏，“五环书”|2926353|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Man cannot understand the perfection and imperfections of his chosen art if he cannot see the value in other arts. Following rules only permits development up to a point in technique and then the student and artist has to learn more and seek further. It makes sense to study other arts as well as those of strategy.

Who has not learned something more about themselves by watching the activities of others? To learn the sword study the guitar. To learn the fist study commerce. To just study the sword will make you narrow-minded and will not permit you to grow outward.

-- Miyamoto Musashi, "A Book of Five Rings"

blocks|key|2926430|text|我认为函数式语言不会解决任何问题，这只是管理层试图推销的炒作，记住唯一的事实：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2926431|没有什么灵丹妙药。|2926432|其他的都是胡说八道，他们还说OO会解决我们的问题，Web+Services会解决我们的问题，Xml会解决我们的问题，但最终应用了上面的真理，所有的事情都失败了。还有，二十年后，谁说我们会使用二进制计算机呢？为什么不是quantic+computers呢？没有人可以预测未来，至少在这个星球上是这样。(这是第二个事实)|2926433|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I don't think that functional languages will solve anything, and that this is just a hype that management is trying to sell, remember the only truth:

There is no silver bullet.

All the rest, is bullshit, also they've said that OO would solve our problems, that Web Services would solve our problems, that Xml would solve our problems, but in the end the above truth applied, and everything went down. Also, twenty years from now on, who says that we will be using binary computers at all? Why not quantic computers? No one can predict the future, at least not on this planet. (That is the second truth)

I see a lot of talk on here about functional languages and stuff. Why would you use one over a "traditional" language? What do they do better? What are they worse at? What's the ideal functional programming application?

Why functional languages?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在这里看到了很多关于函数式语言的讨论。为什么你要用一种而不是“传统”的语言呢？他们做得更好的是什么？他们在什么方面做得更差？理想的函数式编程应用程序是什么？

问为什么是函数式语言？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么是函数式语言？EN