为什么function语言？
我在这里看到很多关于函数式语言和东西的讨论。 你为什么要用一个“传统”的语言？ 他们做什么更好？ 他们还有什么更糟的？ 什么是理想的function编程应用程序？
function语言使用与命令式和面向对象语言不同的范式。 他们使用无副作用的函数作为语言的基本构build块。 这使得许多事情变得更加困难（或者在大多数情况下与人们习惯的不同）
函数式编程最大的优点之一是副作用自由函数的执行顺序并不重要。 例如，在erlang中，这用于以非常透明的方式启用并发。 由于函数式语言中的函数与math函数非常类似，所以很容易将这些函数翻译成函数式语言。 在某些情况下，这可以使代码更具可读性。
传统上，函数式编程的一大缺点是缺乏副作用。 在没有IO的情况下编写有用的软件是非常困难的，但是IO很难在function上没有副作用的情况下实现。 所以大多数人从来没有比单一input计算单一输出更多的function编程。 在现代的混合范式语言如F＃或scala中，这更容易。
许多现代语言都具有function性编程语言的元素。 C＃3.0有很多function编程function，你也可以在python中进行function编程。 我认为function性编程普及的原因主要有两个原因。 在正常的编程中，并发正成为一个真正的问题，因为我们正在获得越来越多的多处理器计算机。 而语言越来越容易获得。
我不认为关于编程“捕捉”的function方法是没有任何问题的，因为它已经被使用了40年（作为一种编程风格）。 每当一个OO程序员写出干净的代码，赞成不可变的对象，该代码是借用function的概念。
然而， 强化function风格的语言如今正在获得大量的虚拟墨迹，这些语言在未来是否会占主导地位，这是一个悬而未决的问题。 我自己的怀疑是，像Scala或OCaml这样的混合型，多范式语言可能会像纯粹的OO语言（Smalltalk，Beta等）影响主stream编程一样，在“纯粹”function语言上占据主导地位，但还没有结束作为最广泛使用的符号。
最后，我无法抗拒地指出，你的意见是否与计划程序员在多年前所听到的言论高度平行：
- （神话，恕我直言）“平均”程序员不明白这一点。
- 这并没有广泛的教导。
- 任何可以用它编写的程序都可以用现有的技术以另一种方式编写。
就像graphics用户界面和“作为业务模型的代码”一样，OO越来越受到人们的广泛关注，我相信更多地使用不变性和更简单（大规模）的并行性将有助于更多的程序员看到function性方法带来的好处。 但是，就像我们在过去50年左右学到的构成整个数字计算机编程的历史一样，我认为我们还有很多东西需要学习。 从现在开始的二十年，程序员会惊讶于我们目前使用的工具的原始性质， 包括现在stream行的OO和FP语言。
对我来说主要的好处是它的内在平行性，尤其是当我们正在从更多的MHz转向越来越多的内核的时候。
我不认为它会成为下一个编程范例，完全取代OOtypes的方法，但是我认为我们会认识到，我们需要用函数式语言来编写一些代码，否则我们的通用语言将会成长为包括更多的function结构。
即使你从不用专业的语言工作，理解函数式编程也会使你成为一个更好的开发者。 它会给你一个关于你的代码和一般编程的新视angular。
我说没有理由不学习它。
我认为混合function性和强制性风格的语言是最有趣和最有可能成功的语言。
我总是怀疑下一个大事。 “下一件大事”的很多时候都是纯粹的历史事故，无论技术是否好，在正确的时间都在正确的地方。 例子：C ++，Tcl / Tk，Perl。 所有有缺陷的技术，因为被认为要么解决当前的问题，要么与根深蒂固的标准几乎相同，或者两者都被认为是非常成功的。 函数式编程可能确实很棒，但这并不意味着它会被采用。
但是我可以告诉你为什么人们对函数式编程感到兴奋 ：很多程序员都有一种“转换经验”，他们发现使用函数式语言使得它们的生产率是生产率的两倍（或者是生产率的十倍）代码更易于改变并且具有更less的错误。 这些人把函数式编程看作是一个秘密武器， 保罗·格雷厄姆的“ 跳动平均数”就是一个很好的例子。 哦，他的申请？ 电子商务networking应用程序。
自2006年初以来，关于函数式编程和并行性的研究也一直在发生。 由于像西蒙·佩顿·琼斯（Simon Peyton Jones）这样的人至less从1984年开始就一直在担心并行性，所以直到function语言解决了多核问题后，我才屏气。 但是现在，这确实解释了一些额外的嗡嗡声。
总的来说，美国的大学在function编程方面做得不好。 使用Scheme的教学编程有很强的支持，Haskell在这方面也有一定的支持，但是对于function程序员来说，先进的技术教学很less。 我在哈佛大学教过这样的课程，今年spring在塔夫茨大学也会这样做。 本杰明·皮尔斯（Benjamin Pierce）在宾夕法尼亚州教过这样的课程 我不知道保罗胡达克在耶鲁做了什么。 欧洲的大学正在做得更好。 例如，在丹麦，荷兰，瑞典和英国的重要地方强调function性编程。 我对澳大利亚的情况没有什么了解。
我没有看到有人在房间里提到大象，所以我认为这取决于我:)
JavaScript是一种function性语言。 随着越来越多的人用JS做更高级的事情，特别是利用jQuery，Dojo和其他框架的更精细的点，FP将由Web开发者的后门介绍。
结合闭包，FP使得JS代码非常轻便，但仍然可读。
干杯，PS
大多数应用程序很简单，可以用正常的OO方式解决
-
OO方式并不总是“正常的”。 这十年的标准是过去十年的边缘化概念。
-
函数式编程是math。 Lisp上的Paul Graham （替代Lisp函数式编程）：
所以，为什么五十年代的语言不是过时的简单解释是，这不是技术，而是math，math不会过时。 比较Lisp的不是1950年代的硬件，而是1960年发现的Quicksortalgorithm，它仍然是最快的通用algorithm。
我敢打赌，你不知道你使用的是函数式编程：
- Excel公式
- 石英composer php
- 使用Javascript
- 标志（乌龟graphics）
- LINQ
- SQL
- Underscore.js（或Lodash），D3
一般的公司程序员，例如我工作的大多数人都不会理解它，大多数工作环境不会让你编程
那只是一个时间问题。 你的平均公司程序员学习目前的大事。 15年前，他们不了解面向对象。 如果 FP发现，你的“平均公司程序员”将会跟随。
这不是真的在大学教（现在呢？）
变化很大。 在我的大学里，SML是学生介绍的第一语言。 我相信麻省理工学院将LISP作为第一年的课程。 当然，这两个例子可能并不具有代表性，但我相信大多数大学至less提供了一些关于计划生育的选修课，即使它们不是课程的强制性部分。
大多数应用程序很简单，可以用正常的OO方式解决
这不是一个“简单”的问题。 FP中的解决scheme是否会更简单 （或更具可读性，健壮性，优雅性）？ 许多事情“足够简单，以Java解决”，但它仍然需要太多的代码。
无论如何，请记住，FP支持者已经声称这是几十年来的下一件大事。 也许他们是对的，但请记住，他们在5年，10年或15年前提出同样的要求时并不是这样。
但是有一件事情对他们有利的是，最近C＃已经对FP进行了大幅度的转变，从某种意义上说，它实际上将一代程序员变成了FP程序员， 甚至没有注意到他们 。 这可能只是为“FP革命”铺平道路。 也许。 ;）
如果他看不到其他艺术的价值，他就不能理解他所选艺术的完美和不完美之处。 以下规则只允许技巧上的发展，学生和艺术家必须学习更多，并进一步寻求。 研究其他艺术以及策略是有意义的。
谁也没有通过观察他人的活动来了解更多关于自己的内容？ 学习剑学习吉他。 学习拳头学习商业。 只要学习这把剑，就会使你心胸狭窄，不允许你向外扩展。
– 宫本武藏“五戒”
我不认为最现实的人会认为函数式编程会被接受（成为OO的主要范式）。 毕竟，大多数业务问题并不是math问题，而是数据移动和以各种方式显示数据的强制规则，这意味着它不适合单纯的函数式编程范例（monad的学习曲线远远超过OO）。
OTOH，函数式编程是使编程乐趣的原因。 它让你体会到宇宙潜在的math简洁expression的内在，永恒的美。 人们说学习函数式编程会使你成为一个更好的程序员。 这当然是非常主观的。 我个人也不认为这是完全正确的。
它使你成为一个更好的生物。
function语言的一个关键特征是一streamfunction的概念。 这个想法是，你可以将函数作为parameter passing给其他函数，并将其作为值返回。
函数式编程涉及编写不改变状态的代码。 这样做的主要原因是，连续调用函数将产生相同的结果。 你可以使用任何支持一stream函数的语言编写function代码，但是有一些语言，比如Haskell，它们不允许你改变状态。 事实上，你不应该做任何副作用（如打印文本） – 这听起来可能是完全无用的。
Haskell采用了不同的方法来处理IO：单子。 这些对象包含所需的IO操作，由解释器的顶层执行。 在任何其他级别，它们只是系统中的对象。
函数式编程提供了什么好处？ function编程允许用较less的潜在错误编码，因为每个组件都是完全隔离的。 此外，使用recursion和一stream的function允许简单的正确性certificate，这通常反映了代码的结构。
F＃可以赶上，因为微软正在推动它。
优点：
- F＃将成为下一个Visual Studio版本的一部分
- 微软正在build立一段时间的社区 – 传播者，书籍，咨询顾问与高知名度的客户合作，在MS会议上曝光。
- F＃是第一类.Net语言，它是第一个具有非常大基础的函数式语言（不是说我说Lisp，Haskell，Erlang，Scala，OCaml没有很多库，它们不像.Net那么完整是）
- 强烈支持并行
魂斗罗：
- F＃很难开始，即使你对C＃和.Net很好 – 至less对我来说:(
- 可能很难find好的F＃开发人员
所以，我给F＃50:50的机会变得重要。 其他function语言不会在不久的将来。
我会指出，你所说的关于函数式语言的一切，大多数人大约在20年前就在谈论面向对象的语言。 那时听到OO是很常见的：
* The average corporate programmer, eg 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 变化必须来自某个地方。 无论受过早期技术培训的人是否认为改变不是必要的，一个有意义的重要改变将会发生。 尽pipe当时有人反对，但是你认为面向对象方面的改变还是不错的吗？
我一定是密集的，但我还是不明白。 有没有用F＃这样的函数式语言编写的小应用程序的实际例子，您可以查看源代码，看看如何以及为什么使用C＃这样的方法更好？
大多数应用程序可以在[在这里插入你最喜欢的语言，范式等]来解决。
虽然这是事实，但可以使用不同的工具来解决不同的问题。 function只是允许另一个高（更高？）级别的抽象，使得正确使用时可以更有效地完成我们的工作。
我认为有一个原因，就是有些人认为语言能被接受的最重要的部分是语言的好坏 。 不幸的是，事情很less如此简单。 例如，我认为Python接受的最大因素不是语言本身（尽pipe这非常重要）。 Python如此stream行的最大原因是其庞大的标准库和第三方库更大的社区。
像Clojure或F＃这样的语言可能是这个规则的例外，因为它们是build立在JVM / CLR之上的。 结果，我没有答案。
在我看来，那些从来没有学过Lisp或Scheme的大学生现在正在发现它。 正如在这个领域的很多事情，有炒作的倾向和创造高度的期望…
会过去的。
function编程是伟大的。 但是，它不会接pipe世界。 C，C ++，Java，C＃等等仍然在身边。
我认为这将带来更多的跨语言能力，例如用function性语言来实现，然后以其他语言访问这些东西。
在阅读Tim Sweeney，Epic Games的“下一个主stream编程语言：游戏开发者的视angular”时，我的第一个想法是 – 我学习了Haskell。
PPT
Google的HTML版本
事情已经朝着一个function方向发展了一段时间。 过去几年里，两个很酷的新孩子，Ruby和Python，都比function语言更接近于function语言 – 这样一来Lispers就开始支持其中一个，“足够接近”。
随着大规模并行硬件给每个人带来进化的压力 – function语言处于最佳位置来处理这些变化，这已经不是什么新鲜事了，以前认为Haskell或F＃将成为下一个重大事件。
你最近是否在追随编程语言的发展？ 所有主stream编程语言的每个新版本似乎都借用了函数式编程的越来越多的特性。
-
闭包，匿名函数，传递函数和返回函数都是Lisp和ML黑客已知的奇特function。 但是逐渐地，C＃，Delphi，Python，Perl，Javascript已经增加了对闭包的支持。 不可能有任何新兴的语言在没有closures的情况下被认真对待。
-
几种语言，特别是Python，C＃和Ruby，对列表parsing和列表生成器有本地支持。
-
ML在1973年开创了通用编程的先河，但对generics的支持（“参数多态”）在过去5年左右才成为行业标准。 如果我没有记错的话，Fortran在2003年支持generics，其次是Java 2004，2005年是C＃，2008年是Delphi。（我知道C ++从1979年开始支持模板，但是90％的关于C ++ STL的讨论始于“这里有恶魔” 。）
是什么让这些function对程序员有吸引力？ 它应该是显而易见的： 它帮助程序员编写较短的代码 。 如果他们想保持竞争力，未来所有语言都将至less支持 – closures。 在这方面，函数式编程已经是主stream。
大多数应用程序很简单，可以用正常的OO方式解决
谁说不能用简单的东西函数式编程？ 并非每个function程序都需要成为编译器，定理certificate器或大规模并行电信交换机。 除了我更复杂的项目之外，我经常使用F＃来实现特别的一次性脚本。
它正在引起关注，因为它是控制复杂性的最佳工具。 看到：
– Simon Peyton-Jones的幻灯片109-116讲“Haskell的味道”
– Tim Sweeney的“下一个主stream编程语言：游戏开发者的视angular”
签出为什么function编程很重要
我同意第一点，但时代变了。 即使他们是迟到的采用者，如果他们发现有一个好处，公司也会作出回应。 生活是dynamic的。
他们在90年代后期在斯坦福大学教哈斯克尔和ML。 我确信像卡耐基梅隆大学，麻省理工学院，斯坦福大学和其他一些优秀学校这样的学校正在向学生展示。
我同意大部分“在networking上暴露关系数据库”应用程序将持续很长一段时间。 Java EE，.NET，RoR和PHP已经为这个问题制定了一些相当不错的解决scheme。
你遇到了一些重要的问题：这可能是通过其他方式难以解决的问题，这将推动函数式编程。 那会是什么？
大规模的多核硬件和云计算将推动他们吗？
因为FP在生产力，可靠性和可维护性方面具有显着的优势。 许多核心可能是一个杀手级的应用程序，最终让大公司切换，尽pipe大量的遗留代码。此外，即使是像C＃这样的大型商业语言，由于核心问题而具有独特的function风格 – 副作用不适合并发和并行。
我不同意“正常”的程序员不会理解它。 他们会像他们最终理解OOP一样（即使不是那么神秘也很奇怪）。
另外，大多数大学都教FP，许多人甚至把它教作为第一门编程课程。
哇 – 这是一个有趣的讨论。 我自己的想法是：
FP使一些任务相对简单（与非FP语言相比）。 非FP计划语言已经开始从FP计划中获得创意，所以我怀疑这种趋势会持续下去，我们将看到更多的合并，这将有助于人们更容易地实现FP的飞跃。
我不知道这个问题是否会出现，但从我的调查来看，函数式语言几乎肯定值得学习，并且会使你成为一个更好的程序员。 只要理解参照透明度，就可以使得许多devise决策变得容易得多，并且由此产生的程序更容易理解。 基本上，如果遇到问题，那么它往往只是单个函数输出的一个问题，而不是一个不一致的状态问题，这可能是由数百个类/方法/函数中的任何一个引起的以具有副作用的有影响的语言。
FP的无状态本质更自然地映射到Web的无状态本质，因此函数式语言更容易使用更加优雅的RESTful Web应用程序。 与需要使用像VIEWSTATE和SESSION键等非常丑陋的HACKS来维护应用程序状态，并且在基本上无状态的function平台（如Web）上维护（有时是相当泄漏的）有状态命令式语言的抽象相反的是JAVA和.NET框架。
而且，你的应用程序越无状态，它就越容易适应并行处理。 如果你的网站碰巧受欢迎，对于networking来说非常重要。 只是为了获得更好的性能而添加更多硬件到站点并不总是简单明了的。
我的观点是，微软现在已经把它推向了主stream。 对我来说这很有吸引力，因为它可以为我们做什么，因为这是一个新的挑战，因为它对未来的工作机会。
一旦掌握，它将成为另一个进一步帮助我们提高程序员效率的工具。
在讨论中错过的一点是，最好的types系统是在当代FP语言中find的。 更重要的是，编译器可以自动推断所有（或至less大部分）types。
有趣的是，在编写Java时花费了一半的时间来编写types名称，而Java远远不是types安全的。 虽然你可能永远不会在Haskell程序中编写types（除了作为一种编译器检查文档）并且代码是100％types安全的。
除了其他的答案之外，用纯粹的function来expression解决scheme会使得人们更好地理解这个问题。 相反，用function性的方式思考问题解决能力会更好。
*要么是因为function范例更好，要么是因为它会提供额外的攻击angular度。
