为什么是函数式语言?

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

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

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

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

函数式语言使用不同于命令式语言和面向对象语言的范式。他们使用无副作用函数作为语言的基本构建块。这使得很多事情成为可能，也让很多事情变得更加困难(或者在大多数情况下与人们习惯的不同)。

传统上，函数式编程的一大缺点也是没有副作用。如果没有IO，很难编写有用的软件，但是如果函数中没有副作用，IO很难实现。因此，大多数人从函数式编程中得到的最多的就是从一个输入计算一个输出。在现代混合范式语言(如f#或Scala)中，这更容易。

许多现代语言都有函数式编程语言的元素。c# 3.0有很多函数式编程特性，你也可以在Python中进行函数式编程。我认为函数式编程流行的原因主要有两个原因:并发正在成为常规编程中的一个真正的问题，因为我们拥有越来越多的多处理器计算机;而且这些语言越来越容易使用。

除了其他答案之外，用纯函数术语来描述解决方案可以迫使人们更好地理解问题。相反，用函数式的思维方式会培养出更好的解决问题的能力。

*要么是因为功能范式更好，要么是因为它可以提供额外的攻击角度。

结帐为什么函数式编程很重要

我一定是糊涂了，但我还是不明白。是否有像f#这样的函数式语言编写的小型应用程序的实际例子，你可以查看源代码，并了解如何以及为什么使用这种方法比c#更好?

对我来说，主要的优点是它固有的并行性，特别是当我们现在从更多的MHz转向越来越多的内核时。

我不认为它会成为下一个编程范式并完全取代OO类型方法，但我确实认为我们将会达到这样的境地:要么我们需要用函数式语言编写一些代码，要么我们的通用语言将会发展到包含更多的函数式结构。

实际上，在阅读了《黑客与画家》之后，我正在学习LISP，我相信我会从LISP中学到一些东西，这将使我更好地理解我所编程的其他东西。现在我不认为我会在我的日常生活中使用LISP，只是因为有人在1995年创建了一个网站，成为雅虎商店。所以无论如何这是一个双赢(如果它流行起来，我赢了，如果没有，我得到了更多关于如何编程和如何工作的观点)

现在…关于另一个有点相关的问题，我认为明年32核处理器到来后编程会发生很大变化吗?是的，我不知道它是否会是函数式编程，但是…我很确定会有一些不同的东西!

我同意第一点，但是时代变了。公司会做出回应，即使他们是后期采用者，如果他们看到有一个优势。生活是动态的。

90年代末，他们在斯坦福教授哈斯凯尔和ML。我相信卡内基梅隆大学、麻省理工学院、斯坦福大学和其他一些好学校正在向学生们展示它。

我同意大多数“在网络上公开关系数据库”的应用程序将在很长一段时间内继续这样做。对于这个问题，Java EE、. net、RoR和PHP已经演化出了一些非常好的解决方案。

您发现了一些重要的问题:这可能是其他方法无法轻松解决的问题，而这些方法将促进函数式编程。那是什么?

大规模多核硬件和云计算会推动它们向前发展吗?

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

1. OO的方式并不总是“正常的”。这个十年的标准是上个十年的边缘化概念。

2. 函数式编程是数学。Paul Graham谈Lisp(用函数式编程取代Lisp):

简短的解释是 20世纪50年代的语言并没有过时 不是技术而是数学，而且 数学不会过时。正确的 Lisp不是20世纪50年代的东西 硬件，但是，比如说，快速排序 算法，是在 1960年，现在仍然是最快的 通用排序。< / p >

即使您从未专业地使用过函数式语言，了解函数式编程也会使您成为更好的开发人员。它会给你一个新的视角来看待你的代码和编程。

我认为没有理由不去学习它。

我认为能够很好地混合函数式和命令式风格的语言是最有趣的，也是最有可能成功的。

大多数应用程序都可以用[此处插入您最喜欢的语言、范例等]来解决。

尽管如此，不同的工具可以用来解决不同的问题。函数只是允许另一种更高层次的抽象，当正确使用时，它允许我们更有效地完成工作。

大学里并没有真正教授(或者现在有吗?)

我不知道现在的情况，但在90年代中期，我在计算机科学课程中学习了米兰达语言和Lisp语言。尽管从那以后没有使用纯函数语言，但它影响了我解决问题的方式。

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

在90年代中期的CS课程中，面向对象(使用Eiffel教授)的教学与函数式编程相当。两者在当时都是非主流的。面向对象现在可能是“正常”的，但过去并非如此。

我很有兴趣看看f#是否是将FP推向主流的东西。

我认为其中一个原因是有些人认为一门语言是否被接受最重要的部分是它有多好。不幸的是，事情很少这么简单。例如，我认为Python被接受的最大因素不是语言本身(尽管是非常重要)。Python如此受欢迎的最大原因是它庞大的标准库和更大的第三方库社区。

像Clojure或f#这样的语言可能是这个规则的例外，因为它们是构建在JVM/CLR之上的。因此，我没有答案。

f#可能会流行起来，因为微软正在推动它。

正方观点:

• f#将成为Visual Studio下一个版本的一部分
• 微软建立社区已经有一段时间了——布道者、书籍、与知名客户合作的顾问，以及在微软会议上的大量曝光。
• f#是第一个类。net语言，也是第一个具有强大基础的函数式语言(我不是说Lisp, Haskell, Erlang, Scala, OCaml没有很多库，他们只是没有。net那么完整)
• 强烈支持并行

反:

• 即使你精通c#和。net, f#也很难上手——至少对我来说是这样的:(
• 可能很难找到好的f#开发人员

所以，我给f# 50:50的机会变得重要。其他函数式语言在不久的将来也不会出现。

因为FP在生产力、可靠性和可维护性方面有显著的好处。多核可能是一个杀手级应用程序，最终让大公司在大量遗留代码的情况下转换。此外，即使是像c#这样的大型商业语言，也因为多核问题而呈现出一种独特的函数风格——副作用根本不适合并发性和并行性。

我不认为“普通”程序员不能理解它。他们会的，就像他们最终理解了面向对象编程一样(它同样神秘和怪异，如果不是更神秘的话)。

此外，大多数大学都教授FP，许多甚至将其作为第一门编程课程。

一般的公司程序员，例如; 和我一起工作的大多数人都会 不懂它和大多数工作 环境不允许您编程 在< / p >

大学里没有教过这个 (或者是现在?)

变化很大。在我的大学里，SML是学生接触的第一门语言。 我相信麻省理工学院将LISP作为第一年的课程。当然，这两个例子可能不具有代表性，但我相信大多数大学至少提供了一些关于计划生育的选修课，即使他们没有把它作为课程的必修课

大多数应用程序都很简单 以正常的OO方式解决

这并不是一个“足够简单”的问题。在FP中，解决方案会是更简单的(或更可读、健壮、优雅、高性能)吗?许多事情“简单到可以用Java解决”，但它仍然需要大量的代码。

无论如何，请记住，政策政策的支持者几十年来一直声称这是下一个大事件。也许他们是对的，但请记住，5年、10年或15年前他们做出同样的声明时，他们是不对的。

不过，有一件事肯定对他们有利，那就是最近，c#向FP方向急剧转变，以至于它实际上把一代程序员变成了FP程序员，他们甚至没有注意到。这可能会为计划生育“革命”铺平道路。也许吧。；）

在我看来，那些从未在本科阶段学习过Lisp或Scheme的人现在正在发现它。与这个领域的许多事情一样，有一种炒作和创造高期望的倾向……

一切都会过去的。

函数式编程很棒。然而，它不会统治世界。C、c++、Java、c#等语言仍将存在。

我认为这会带来更多的跨语言能力——例如，用函数式语言实现一些东西，然后用其他语言访问这些东西。

事情朝着功能性的方向发展已经有一段时间了。过去几年的两个很酷的新孩子，Ruby和Python，都比之前的函数语言更接近——以至于一些Lispers开始支持其中一个或另一个，认为“足够接近”。

随着大规模并行硬件给每个人带来了进化的压力——函数式语言是应对这些变化的最佳位置——认为Haskell或f#将成为下一个大事件的飞跃并不像以前那么遥远。

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

• 闭包、匿名函数、作为值传递和返回函数曾经是只有Lisp和ML黑客才知道的奇异特性。但是渐渐地，c#、Delphi、Python、Perl、Javascript都增加了对闭包的支持。没有闭包，任何有前途的语言都不可能被认真对待。

• 一些语言，特别是Python、c#和Ruby，都有对列表推导和列表生成器的原生支持。

• ML在1973年开创了泛型编程，但是对泛型(“参数多态性”)的支持直到最近5年左右才成为行业标准。如果我没记错的话，Fortran在2003年支持泛型，接着是Java 2004年，c# 2005年，Delphi 2008年。(我知道c++从1979年就开始支持模板了，但是90%关于c++ STL的讨论都是以“这里有恶魔”开头的。)

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

大多数应用程序都很简单 以正常的OO方式解决

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

我不认为函数式编程方法“流行起来”有任何问题，因为它(作为一种编程风格)已经被使用了大约40年。每当OO程序员编写有利于不可变对象的干净代码时，这些代码就是借用了函数概念。

然而，那些执行函数式风格的语言最近得到了大量的虚拟墨水，这些语言在未来是否会成为主流还是一个悬而未决的问题。我自己的怀疑是混合的，多范式的语言，如Scala或OCaml 将很可能统治“纯粹的”函数语言，就像纯粹的OO语言(Smalltalk, Beta等)影响了主流编程一样，但并没有最终成为最广泛使用的符号

最后，我忍不住要指出，你对FP的评论与我几年前从过程程序员那里听到的评论高度相似:

• (恕我直言，这是神话)“普通”程序员不理解它。
• 这并没有被广泛教授。
• 任何你能用它来写的程序，都能用现有的技术以另一种方式来写。

正如图形用户界面和“代码作为业务模型”是帮助OO得到更广泛认可的概念一样，我相信增加对不可变性和更简单(大规模)并行的使用将帮助更多程序员看到函数方法所提供的好处。但是，尽管我们在在过去的50年左右中学到的东西构成了整个数字计算机编程的历史，我认为我们仍然有很多东西要学。二十年后，程序员会惊讶地发现我们现在使用的工具的原始本质，包括现在流行的OO和FP语言。

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

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

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

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

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

但是我可以告诉你为什么人们对函数式编程是兴奋:许多许多程序员都有一种“转换经验”，他们发现使用函数式语言使他们的工作效率提高了两倍(或者可能是十倍)，同时产生的代码更能适应变化，bug更少。这些人认为函数式编程是一种秘密武器;Paul Graham的超过平均水平就是一个很好的例子。哦，那他的申请呢?电子商务web应用程序。

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

总的来说，美国大学在函数式编程教学方面做得很差。使用Scheme进行编程教学介绍有强大的核心支持，Haskell也在那里享受一些支持，但在教授函数式程序员的高级技术方面很少。我曾在哈佛教授过这样的课程，今年春天还将在塔夫茨大学教授。本杰明·皮尔斯(Benjamin Pierce)在宾夕法尼亚大学教授过这样一门课程。我不知道Paul Hudak在耶鲁做过什么。欧洲大学在这方面做得更好;例如，函数式编程在丹麦、荷兰、瑞典和英国的重要地方被强调。我对大洋洲正在发生的事情不太了解。

它已经在Hadoop中的Map/reduce中流行起来

我认为函数式编程语言成为“下一个大事件”的最大理由是，在未来，多核处理器将成为标准。程序员将不得不利用这一点，而函数式编程为构建顶级并发软件提供了极好的可能性。

附注:当我在波士顿大学(1998 - 02)读大学时，我们花了一个学期学习Scheme，它是LISP的近亲。我们刚开始学的时候，我都想把头发扯下来。课程结束时，一切都变得很自然了。

我没有看到任何人在这里提到房间里的大象，所以我认为这取决于我:)

JavaScript是一种函数式语言。随着越来越多的人使用JS做更高级的事情，特别是利用jQuery、Dojo和其他框架的优点，FP将通过web开发人员的后门引入。

与闭包结合使用，FP使JS代码非常轻便，但仍然可读。

我不知道它是否会流行起来，但从我的调查来看，函数式语言几乎肯定是值得学习的，它会让你成为更好的程序员。只要理解了引用透明性，很多设计决策就变得容易多了——产生的程序也更容易推理了。基本上，如果您遇到了问题，那么它往往只是单个函数输出的问题，而不是状态不一致的问题，这种问题可能是由具有副作用的相对语言中数百个类/方法/函数中的任何一个引起的。

FP的无状态本质更自然地映射到web的无状态本质，因此函数式语言更容易让自己更优雅，更RESTFUL的web应用程序。与JAVA和. net框架形成鲜明对比的是，它们需要在本质上无状态的功能平台(如web)上使用VIEWSTATE和SESSION键来维护应用程序状态，并维护有状态命令语言的抽象(有时相当容易泄漏)。

而且，应用程序越无状态，就越容易进行并行处理。如果你的网站很受欢迎，这对网络来说非常重要。向站点添加更多硬件以获得更好的性能并不总是那么简单。

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

• Excel公式
• 石英的作曲家
• JavaScript
• Logo(海龟图形)
• LINQ
• SQL
• 下划线。js(或Lodash)， 李D3 < / >

我认为你问题的答案更多地在于“工作的正确工具”这句话，而不是最热门的东西。总会有热门的新技术，也总会有人扑上去。

函数式语言已经出现了一段时间，只是现在它们得到了更多的报道。

呃，很抱歉，我是一个学究，但它已经流行起来了——我们称之为Excel。

http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/

在计算机上运行的绝大多数程序都是用Excel或其众多流行克隆版本之一编写的。

(有许多程序运行多次，而用Excel编写的程序往往不是其中之一-大多数Excel程序都有1个运行实例)

FP无疑是下一个最佳范例。现在哪种语言可能是下一步，这是很难的东西，但我相信可能是Haskell, f#， Clojure, Ocaml或Erlang。或者是带有更多FP结构和更好的并行性/性能支持的Python，或者是带有parrot的Perl 6，看起来非常有趣。

• OOP要花多长时间才能被普通的公司程序员理解?
• 我在乌得勒支大学(Utrecht University)学习函数式编程，我想是在1994年，直到最近几年它才开始在“现实世界”流行起来。
• 没有所谓的“简单应用程序”。: -)

我认为，当我们开始在硬件中添加越来越多的核心时，软件某些关键部分的免费编程(接近)将是必不可少的。给函数式编程多一点时间。在当前和未来的c#版本中，函数式编程将会让那些公司程序员在没有意识到的情况下做好函数式编程的准备……

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

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

一些想法:

• FP和命令式编程(OO、结构化等)之间的争论，从Lisp和Fortran之争开始就一直很激烈。我认为你提出的问题很好，但要认识到这些问题并不是特别新的。
• 关于FP的部分宣传是我们似乎认识到并发性是非常困难的，而OO中的锁和其他机制(例如Java)只是一种解决方案。FP通过actor和无状态计算的强大功能等思想带来了令人耳目一新的巨变。对于那些与OO打交道的人来说，这一前景似乎极具吸引力。
• 是的，学校教授FP。事实上，滑铁卢大学和其他大学在一年级课程中提供Scheme (参考这里)。
• 对于普通的程序员，我确信在20世纪90年代早期也有人对c++提出过同样的观点。看看发生了什么。如果企业可以通过技术获得优势，你可以打赌，人们会接受培训。

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

当阅读Tim Sweeney的《The Next主流编程语言:A Game Developer’s Perspective》时，我的第一个想法是——我必须学习Haskell。

PPT .

谷歌的HTML版本

Slava Akhmechet有一篇很棒的文章，叫做为我们其余的人编写函数式编程(顺便说一句，正是这篇文章让我进入了FP)。在FP带来的好处中，他非常规地强调了以下几点(我认为这有助于软件工程师的吸引力):

• 单元测试
• 调试
• 并发性
• 热码部署
• 机器辅助证明与优化

然后继续讨论FP中更多传统讨论的方面的优点，如高阶函数、咖喱、惰性求值、优化、抽象控制结构(尽管没有讨论单子)、无限数据结构、严格性、延续、模式匹配、闭包等。

强烈推荐!

很多人都提到了函数式语言。

除了Javascript，还有一些最常用的函数式语言。

Excel、SQL、XSLT、XQuery、J、K等应用于金融领域。

当然是Erlang。

所以我想说，从这个列表中，函数式编程技术每天都在主流中使用。

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

然而，f#将是另一个来源，可能会满足非计算机科学家的设计需求。让我们面对现实吧，计算机科学家在创造一种全新的做事方式方面做得很好。面向对象编程很棒。但有时你只需要一种方法来解一个方程，得到一个解并画出它。就是这样。然后像f#这样的语言就可以满足要求了。或者你想要构建一个有限状态机，f#也可以是一个解决方案，但C也可以是一个解决方案。

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

讨论中忽略的一点是，最好的类型系统存在于当代FP语言中。更重要的是，编译器可以自动推断所有(或至少大部分)类型。

有趣的是，在编程Java时，有一半的时间花在编写类型名上，然而Java到目前为止还不是类型安全的。虽然你可能从来没有在Haskell程序中写过类型(除非作为一种编译器检查的文档)，但代码是100%类型安全的。

微软正在Visual Studio上大力推广f#的下一个版本。它是一种像Scala一样的混合语言，并且可以很好地与。net框架的其余部分集成。我认为许多微软公司将使用它来加速高度并行的数据处理应用程序和功能的开发。

我很难想象纯函数式语言会成为当今的通用语言，其中的原因我就不赘述了(因为它们是煽风点火的材料)。也就是说，无论哪种语言(如果允许的话)，函数式编程都能带来好处。对我来说，更容易测试我的代码。我经常和数据库打交道……我倾向于:

1. 编写一个函数来获取数据、操作数据并返回数据
2. 编写一个非常简单的包装器，调用数据库，然后返回通过函数传递该数据的结果

这样做允许我为操作函数编写单元测试，而不需要创建模拟之类的东西。

我确实认为纯函数式语言非常有趣……我只是觉得对我来说重要的是我们能从他们身上学到什么，而不是我们能用他们做什么。

我要指出的是，你所说的关于函数式语言的一切，大约20年前，大多数人都在谈论面向对象语言。在那时候，OO是很常见的:

* 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

改变必须来自某个地方。无论接受过早期技术培训的人是否认为变革没有必要，有意义的重要变革都会发生。尽管当时有很多人反对，但你认为向OO的转变是好的吗?

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

函数式编程已经存在很长一段时间了，因为LISP是最早拥有编译器的语言之一，而且自从MIT的LISP机器问世以来。这不是一种新的范式(OO更新得多)，但主流软件平台倾向于用易于转换为汇编语言的语言编写，它们的api非常倾向于命令式代码(UNIX使用C, Windows使用C, Macintosh使用Pascal和后来的C)。

我认为过去几年的新创新是api的多样性，尤其是在平台api无关紧要的web开发领域。因为你没有直接对Win32 API或POSIX API进行编码，这就给了人们尝试函数式语言的自由。

如果一个人看不到其他艺术的价值，他就无法理解他所选择的艺术的完美和不完美。遵循规则只允许在技术上发展到一定程度，然后学生和艺术家必须学习更多，进一步探索。在学习战略艺术的同时，学习其他艺术也是有意义的。

谁没有通过观察别人的活动来更多地了解自己呢?要学剑，就要学吉他。要学商业，先学商业。只学习刀剑会使你心胸狭窄，不能向外成长。

——宫本武藏《五环之书》

我不认为函数式语言能解决任何问题，这只是管理层试图推销的一种炒作，记住唯一的事实:

没有灵丹妙药。

其余的都是胡扯，他们还说OO会解决我们的问题，Web服务会解决我们的问题，Xml会解决我们的问题，但最后上面的真理适用了，一切都失败了。而且，20年后，谁说我们还会使用二进制计算机呢?为什么不是量子计算机呢?没有人能预测未来，至少在这个星球上不能。(这是第二条真理)