我在这里看到很多关于函数式语言和东西的讨论。为什么要使用“传统”语言而不是“传统”语言？他们在哪些方面做得更好？他们最差的是什么？什么是理想的函数式编程应用程序？
mabwi
问问题
187359 次
48 回答
220
函数式语言使用与命令式和面向对象语言不同的范式。他们使用无副作用函数作为语言的基本构建块。这可以实现很多事情并使很多事情变得更加困难（或者在大多数情况下与人们习惯的不同）。
函数式编程的最大优势之一是无副作用函数的执行顺序并不重要。例如，在 Erlang 中，这用于以非常透明的方式启用并发。而且由于函数式语言中的函数的行为与数学函数非常相似，因此很容易将它们翻译成函数式语言。在某些情况下，这可以使代码更具可读性。
传统上，函数式编程的一大缺点也是没有副作用。没有 IO 很难写出有用的软件，但没有函数副作用的 IO 很难实现。因此，大多数人从函数式编程中获得的不仅仅是从单个输入计算单个输出。在 F# 或 Scala 等现代混合范式语言中，这更容易。
许多现代语言都有来自函数式编程语言的元素。C# 3.0 有很多函数式编程特性，你也可以在 Python 中进行函数式编程。我认为函数式编程流行的原因主要有两个原因：并发正在成为普通编程中的一个真正问题，因为我们越来越多的多处理器计算机；并且语言变得越来越容易使用。
于 2008-08-31T00:38:05.340 回答
202
我认为编程“流行”的函数式方法没有任何问题，因为它已经使用了大约 40 年（作为一种编程风格）。每当 OO 程序员编写有利于不可变对象的干净代码时，该代码就是在借用函数概念。
然而，如今强制执行函数式风格的语言正在获得大量的虚拟墨水，这些语言是否会在未来占据主导地位是一个悬而未决的问题。我自己的怀疑是， Scala或OCaml等混合、多范式语言 可能会以与纯 OO 语言（Smalltalk、Beta 等）影响主流编程但尚未结束的方式相同的方式主导“纯粹的”函数式语言作为最广泛使用的符号。
最后，我忍不住指出，您对 FP 的评论与我在几年前从程序程序员那里听到的评论高度相似：
- （神话，恕我直言）“普通”程序员不理解它。
- 它没有被广泛教授。
- 您可以使用它编写的任何程序都可以使用当前技术以另一种方式编写。
正如图形用户界面和“作为业务模型的代码”是帮助 OO 得到更广泛认可的概念一样，我相信更多地使用不变性和更简单（大规模）并行性将帮助更多程序员看到函数式方法提供的好处. 但是，在构成数字计算机编程整个历史的过去 50 年左右的时间里，尽管我们学到了很多东西，但我认为我们还有很多东西要学。20 年后，程序员回顾我们目前使用的工具的原始性质，会惊叹不已，包括现在流行的 OO 和 FP 语言。
于 2009-01-04T21:10:58.207 回答
125
对我来说主要的优点是它固有的并行性，尤其是当我们现在正从更多的 MHz 转向越来越多的内核时。
我不认为它会成为下一个编程范式并完全取代 OO 类型的方法，但我确实认为我们将达到需要用函数式语言编写一些代码，或者我们的通用语言将成长为包括更多的功能性结构。
于 2009-01-04T17:16:30.693 回答
79
即使您从未专业地使用函数式语言工作，了解函数式编程也会使您成为更好的开发人员。它会给你一个关于你的代码和编程的新视角。
我说没有理由不学习它。
我认为能够很好地混合函数式和命令式风格的语言是最有趣的，也是最有可能成功的。
于 2009-01-04T17:19:39.593 回答
58
我总是对下一件大事持怀疑态度。很多时候，下一件大事纯粹是历史的偶然，无论技术好坏，在正确的时间出现在正确的地方。示例：C++、Tcl/Tk、Perl。所有有缺陷的技术，都取得了巨大的成功，因为它们被认为要么解决了当时的问题，要么与根深蒂固的标准几乎相同，或者两者兼而有之。函数式编程可能确实很棒，但这并不意味着它会被采用。
但我可以告诉你为什么人们对函数式编程感到兴奋：很多很多程序员都有过一种“转换经验”，他们发现使用函数式语言可以使他们的生产力提高一倍（或者可能是十倍）代码更容易改变并且错误更少。这些人认为函数式编程是一种秘密武器；这种心态的一个很好的例子是保罗格雷厄姆的击败平均水平。哦，他的申请呢？电子商务网络应用程序。
自 2006 年初以来，也出现了一些关于函数式编程和并行性的讨论。由于像Simon Peyton Jones这样的人至少从 1984 年开始就断断续续地担心并行性，所以在函数式语言解决多核问题之前，我不会屏住呼吸。但它确实解释了现在的一些额外的嗡嗡声。
总的来说，美国大学在教授函数式编程方面做得很差。使用 Scheme 教授入门编程有一个强大的核心支持，Haskell 在那里也享有一些支持，但在教授函数式程序员高级技术的方式上却很少。我在哈佛教过这样一门课程，今年春天在塔夫茨会再教一次。本杰明·皮尔斯曾在宾夕法尼亚大学教授过这样的课程。我不知道 Paul Hudak 是否在耶鲁做过什么。欧洲的大学做得更好；例如，丹麦、荷兰、瑞典和英国的重要地方都强调函数式编程。我对大洋洲发生的事情知之甚少。
于 2009-01-04T21:54:47.917 回答
32
我没有看到有人提到这里房间里的大象，所以我认为这取决于我:)
JavaScript 是一种函数式语言。随着越来越多的人用 JS 做更高级的事情，特别是利用 jQuery、Dojo 和其他框架的优点，FP 将被 web 开发人员的后门引入。
结合闭包，FP 使 JS 代码变得非常轻巧，但仍然可读。
干杯，PS
于 2009-01-05T10:37:57.203 回答
26
大多数应用程序都很简单，可以通过正常的 OO 方式解决
OO 方式并不总是“正常”的。这十年的标准是上十年的边缘化概念。
函数式编程是数学。Paul Graham 谈 Lisp（用函数式编程代替 Lisp）：
因此，为什么这门 1950 年代的语言没有过时的简短解释是，它不是技术而是数学，而且数学不会过时。与 Lisp 比较的正确方法不是 1950 年代的硬件，而是快速排序算法，它于 1960 年被发现，仍然是最快的通用排序算法。
于 2009-01-04T17:18:46.147 回答
25
我敢打赌，当您使用时，您不知道自己是函数式编程：
- Excel 公式
- 石英作曲家
- JavaScript
- 标志（海龟图形）
- LINQ
- SQL
- Underscore.js（或 Lodash），D3
于 2009-01-05T11:42:44.330 回答
18
普通的公司程序员，例如与我一起工作的大多数人，不会理解它，并且大多数工作环境不会让你在其中编程
不过，那只是时间问题。您的普通公司程序员会了解当前的大事。15 年前，他们不了解 OOP。 如果FP 流行起来，你的“普通公司程序员”就会跟上。
它并没有在大学里真正教授过（或者现在是这样吗？）
变化很大。在我的大学，SML 是学生接触的第一门语言。我相信麻省理工学院教授 LISP 作为第一年的课程。当然，这两个例子可能不具有代表性，但我相信大多数大学至少会提供一些关于 FP 的选修课程，即使它们没有将其作为课程的必修部分。
大多数应用程序都很简单，可以通过正常的 OO 方式解决
不过，这并不是“足够简单”的问题。FP 中的解决方案会更简单（或更易读、更健壮、更优雅、更高效）吗？许多事情“简单到可以用 Java 解决”，但它仍然需要大量的代码。
无论如何，请记住，FP 的支持者已经声称它是几十年来的下一件大事。也许他们是对的，但请记住，当他们在 5、10 或 15 年前提出同样的主张时，他们并不是这样。
不过，绝对对他们有利的一件事是，最近，C# 急剧转向 FP，以至于它实际上将一代程序员变成了 FP 程序员，而他们甚至没有注意到. 这可能只是为FP“革命”铺平了道路。也许。;)
于 2009-01-04T17:42:25.460 回答
15
如果人看不到其他艺术的价值，他就无法理解他所选择的艺术的完美与不完美。遵循规则只允许发展到一定程度的技术，然后学生和艺术家必须学习更多并进一步寻求。学习其他艺术以及策略艺术是有意义的。
谁没有通过观察别人的活动更多地了解自己？学剑学吉他。学第一学商学。光学剑会使你心胸狭窄，不能向外成长。
——宫本武藏《五轮书》
于 2010-08-05T14:58:56.547 回答
12
函数式语言的一个关键特性是一等函数的概念。这个想法是您可以将函数作为参数传递给其他函数并将它们作为值返回。
函数式编程涉及编写不改变状态的代码。这样做的主要原因是对函数的连续调用将产生相同的结果。您可以使用任何支持一流函数的语言编写函数式代码，但是有些语言（例如 Haskell）不允许您更改状态。事实上，你根本不应该产生任何副作用（比如打印出文本）——这听起来可能完全没用。
相反，Haskell 对 IO 采用了不同的方法：monads。这些对象包含要由解释器的顶层执行的所需 IO 操作。在任何其他级别，它们只是系统中的对象。
函数式编程有什么优势？函数式编程允许以更少的潜在错误进行编码，因为每个组件都是完全隔离的。此外，使用递归和一等函数允许简单的正确性证明，这通常反映了代码的结构。
于 2008-08-31T00:29:54.377 回答
12
我不认为大多数现实的人认为函数式编程会流行（成为像 OO 这样的主要范式）。毕竟，大多数业务问题都不是漂亮的数学问题，而是用于移动数据并以各种方式显示它们的毛茸茸的命令式规则，这意味着它不适合纯函数式编程范式（monad 的学习曲线远远超过 OO。）
OTOH，函数式编程使编程变得有趣。它让你欣赏宇宙基础数学的简洁表达的内在、永恒之美。人们说学习函数式编程会让你成为一个更好的程序员。这当然是非常主观的。我个人认为这也不完全正确。
它让你成为一个更好的众生。
于 2009-01-04T21:43:27.173 回答
8
我一定很密集，但我还是不明白。是否有使用 F# 之类的函数式语言编写的小型应用程序的实际示例，您可以在其中查看源代码并了解使用这种方法比使用 C# 更好的方法和原因？
于 2008-12-16T07:34:50.643 回答
8
我要指出，你所说的关于函数式语言的一切，大多数人在大约 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 的改变是好的吗？
于 2009-09-17T17:52:53.580 回答
7
F# 可能会流行起来，因为微软正在推动它。
临：
- F# 将成为下一个版本的 Visual Studio 的一部分
- 一段时间以来，微软一直在建立社区——传道者、书籍、与知名客户合作的顾问，以及在 MS 会议上的大量曝光。
- F# 是一流的 .Net 语言，它是第一个具有非常大基础的函数式语言（并不是说 Lisp、Haskell、Erlang、Scala、OCaml 没有很多库，它们只是不如 .Net 完整是）
- 对并行性的强大支持
反对：
- 即使您擅长 C# 和 .Net，F# 也很难开始 - 至少对我而言 :(
- 可能很难找到好的 F# 开发人员
所以，我给 F# 50:50 的机会变得重要。其他函数式语言在不久的将来不会实现。
于 2009-01-04T17:38:37.060 回答
5
我想一个原因是，有些人觉得一种语言能不能被接受，最重要的就是语言有多好。不幸的是，事情很少这么简单。例如，我认为 Python 被接受的最大因素不是语言本身（尽管这非常重要）。Python 如此受欢迎的最大原因是其庞大的标准库和更大的第三方库社区。
考虑到 Clojure 或 F# 等语言是基于 JVM/CLR 构建的，因此可能是例外。结果，我对他们没有答案。
于 2009-01-04T17:31:57.930 回答
4
大多数应用程序都可以通过 [在此处插入您喜欢的语言、范例等] 来解决。
虽然这是真的，但可以使用不同的工具来解决不同的问题。功能只是允许另一个更高（更高？）级别的抽象，如果使用正确，可以更有效地完成我们的工作。
于 2009-01-04T17:21:54.987 回答
4
在我看来，那些在本科时从未学过 Lisp 或 Scheme 的人现在正在发现它。与该领域的许多事情一样，存在炒作和创造高期望的趋势......
会过去的。
函数式编程很棒。但是，它不会接管世界。C、C++、Java、C#等仍然存在。
我认为这会带来更多的跨语言能力——例如用函数式语言实现东西，然后用其他语言访问这些东西。
于 2009-01-04T18:05:49.517 回答
4
于 2009-01-08T06:56:12.627 回答
3
于 2008-09-04T01:17:59.127 回答
3
一段时间以来，事情一直在朝着功能方向发展。过去几年的两个很酷的新孩子，Ruby 和 Python，都比它们之前的语言更接近函数式语言——以至于一些 Lisper 已经开始支持其中一种，因为它“足够接近”。
由于大规模并行硬件给每个人带来了进化压力——而函数式语言处于应对变化的最佳位置——这并不像以前认为 Haskell 或 F# 将成为下一件大事那样飞跃。
于 2009-01-04T18:07:17.377 回答
3
您最近是否一直在关注编程语言的发展？所有主流编程语言的每一个新版本似乎都从函数式编程中借用了越来越多的特性。
闭包、匿名函数、作为值传递和返回函数曾经是只有 Lisp 和 ML 黑客才知道的奇异特性。但逐渐地，C#、Delphi、Python、Perl、Javascript 都增加了对闭包的支持。如果没有闭包，任何新兴语言都不可能被认真对待。
几种语言，尤其是 Python、C# 和 Ruby，对列表推导和列表生成器具有原生支持。
ML 在 1973 年开创了泛型编程，但对泛型（“参数多态性”）的支持在过去 5 年左右才成为行业标准。如果我没记错的话，Fortran 在 2003 年支持泛型，随后是 Java 2004、C# 在 2005 年、Delphi 在 2008 年。（我知道 C++ 从 1979 年开始就支持模板，但是关于 C++ 的 STL 的 90% 的讨论都是从“这里有恶魔”开始的.)
是什么让这些功能对程序员有吸引力？这应该很明显：它可以帮助程序员编写更短的代码。如果想要保持竞争力，未来所有语言都将至少支持关闭。在这方面，函数式编程已经是主流。
大多数应用程序都很简单，可以通过正常的 OO 方式解决
谁说不能将函数式编程也用于简单的事情？并非每个功能程序都需要是编译器、定理证明器或大规模并行电信交换机。除了更复杂的项目之外，我还经常将 F# 用于临时一次性脚本。
于 2009-01-04T20:55:58.953 回答
3
它之所以流行，是因为它是控制复杂性的最佳工具。请参阅：
- Simon Peyton-Jones 的幻灯片 109-116 演讲“Haskell 的味道”
- Tim Sweeney 的“下一个主流编程语言：游戏开发者的视角”
于 2009-01-05T11:59:03.033 回答
2
我同意第一点，但时代变了。公司会做出回应，即使他们是后期采用者，如果他们看到有优势的话。生活是动态的。
90 年代后期，他们在斯坦福大学教授 Haskell 和 ML。我敢肯定，卡内基梅隆大学、麻省理工学院、斯坦福大学和其他好学校都在向学生展示它。
我同意大多数“在网络上公开关系数据库”的应用程序将在很长一段时间内以这种方式继续存在。Java EE、.NET、RoR 和 PHP 已经为这个问题发展了一些非常好的解决方案。
您遇到了重要的事情：这可能是无法通过其他方式轻松解决的问题，这将促进函数式编程。那会是什么？
大规模多核硬件和云计算会推动它们前进吗？
于 2009-01-04T17:18:07.537 回答
2
因为 FP 在生产力、可靠性和可维护性方面具有显着优势。众核可能是一个杀手级应用程序，尽管有大量遗留代码，但最终还是让大公司转向。此外，由于多核问题，甚至像 C# 这样的大型商业语言也呈现出独特的功能风格 - 副作用只是不适合并发性和并行性。
我不同意“普通”程序员不会理解它。他们会的，就像他们最终理解了 OOP 一样（即使不是更神秘也很奇怪）。
此外，大多数大学都教授 FP，许多大学甚至将其作为第一门编程课程来教授。
于 2009-01-04T17:40:42.373 回答
2
哇——这是一个有趣的讨论。对此我个人的想法：
FP 使一些任务相对简单（与非 FP 语言相比）。非 FP 语言已经开始从 FP 中汲取灵感，所以我怀疑这种趋势将继续下去，我们将看到更多的合并，这将有助于人们更轻松地过渡到 FP。
于 2009-01-04T21:51:03.010 回答
2
我不知道它是否会流行起来，但根据我的调查，函数式语言几乎肯定值得学习，并且会让你成为一个更好的程序员。仅仅理解引用透明性就可以让很多设计决策变得更加容易——并且由此产生的程序更容易推理。基本上，如果您遇到问题，那么它往往只是单个函数的输出问题，而不是状态不一致的问题，这可能是由数百个类/方法/函数中的任何一个引起的用带有副作用的比喻性语言。
FP 的无状态特性更自然地映射到 Web 的无状态特性，因此函数式语言更容易为更优雅、RESTFUL 的 web 应用程序提供帮助。与 JAVA 和 .NET 框架相比，它们需要借助 VIEWSTATE 和 SESSION 键等丑陋的 HACKS 来维护应用程序状态，并在 Web 等本质上无状态的功能平台上维护有状态命令式语言的（有时非常容易泄露）抽象。
而且，您的应用程序越无状态，它就越容易适合并行处理。如果您的网站碰巧流行起来，这对网络非常重要。向站点添加更多硬件以获得更好的性能并不总是那么简单。
于 2009-01-05T11:34:50.740 回答
2
我的观点是，现在微软已经将它推向了主流，它将会流行起来。对我来说，它很有吸引力，因为它可以为我们做些什么，因为它是一个新的挑战，也因为它对未来的工作机会感到不满。
一旦掌握了它，它将成为进一步帮助我们提高程序员工作效率的另一种工具。
于 2009-01-05T14:57:32.563 回答
2
讨论中遗漏的一点是，最好的类型系统可以在当代 FP 语言中找到。更重要的是，编译器可以自动推断所有（或至少大多数）类型。
有趣的是，人们在编写 Java 时会花费一半的时间来编写类型名称，但 Java 到目前为止还不是类型安全的。虽然您可能永远不会在 Haskell 程序中编写类型（除了作为一种编译器检查的文档）并且代码是 100% 类型安全的。
于 2009-04-03T07:24:07.577 回答
1
除了其他答案之外，以纯函数形式提出解决方案会迫使人们更好地理解问题。相反，以实用的方式思考会培养出更好的*解决问题的能力。
*要么是因为功能范式更好，要么是因为它可以提供额外的攻角。
于 2008-09-04T00:20:05.800 回答
1
在阅读 Hackers and Painters 之后，我实际上正在学习 LISP，我相信我会从 LISP 中学到一些东西，这将使我对我编程的所有其他内容有更好的理解。现在我不认为我会在日常生活中真正使用 LISP，因为 1995 年有人创建了一个成为 Yahoo Stores 的网站。所以无论如何它都是双赢的（如果它流行起来我赢了，如果没有，我会得到更多关于如何编程和东西如何工作的观点）
现在......关于另一个有点相关的问题，我认为明年 32 核 proc 到货后编程会发生很大变化吗？是的，我不知道它是否会是函数式编程，但是......我很确定会有一些不同的东西！
于 2009-01-04T17:17:10.800 回答
1
它并没有在大学里真正教授过（或者现在是这样吗？）
我不知道现在的情况，但在 1990 年代中期，我在我的 CS 课程中同时学习了 Miranda 和 Lisp。尽管从那以后没有使用纯函数式语言，但它影响了我解决问题的方式。
大多数应用程序都很简单，可以通过正常的 OO 方式解决
在同一个 90 年代中期的 CS 课程中，OO（使用 Eiffel 授课）的授课方式与函数式编程几乎相提并论。当时两者都不是主流。OO 现在可能是“正常的”，但从来都不是这样。
我有兴趣看看 F# 是否是推动 FP 成为主流的东西。
于 2009-01-04T17:29:22.257 回答
1
我认为函数式编程语言成为“下一件大事”的最大理由是，未来多核处理器将成为常态。程序员将不得不利用这一点，而函数式编程为构建顶级并发软件提供了非常好的可能性。
PS 当我在波士顿大学（'98-'02）上大学时，我们花了一个学期的学习计划，这是 LISP 的近亲。当我们第一次开始学习它时，我想把头发扯掉。到课程结束时，这是非常自然的。
于 2009-01-05T02:23:31.727 回答
1
- 普通公司程序员需要多长时间才能理解 OOP……？
- 我于 1994 年在乌得勒支大学教授函数式编程——我想——在过去的几年里，我才看到它开始在“现实世界”中流行起来。
- 没有所谓的“简单应用程序”。;-)
我认为，当我们开始在硬件中获得越来越多的内核时，对软件的某些关键部分进行（接近）无副作用编程将是必不可少的。给函数式编程多一点时间。而当前和未来版本的 C# 中的函数式编程将大大有助于那些企业程序员为函数式编程做好准备，而他们甚至没有意识到这一点......
于 2009-01-05T14:37:48.937 回答
1
一些想法：
- FP 和命令式编程（OO、结构化等）之间的争论自 Lisp 与 Fortran 以来一直很激烈。我认为你提出了很好的问题，但认识到它们并不是特别新。
- 对 FP 的争论部分在于，我们似乎认识到并发性非常困难，而 OO（例如 Java）中的锁和其他机制只是一种解决方案。FP 通过 Actors 和无状态计算的力量等理念提供了令人耳目一新的巨变。对于那些与 OO 搏斗的人来说，这种情况似乎非常吸引人。
- 是的，学校教 FP。事实上，滑铁卢大学和其他大学在一年级课程中都提供了 Scheme（参考这里）。
- 对于普通程序员，我敢肯定，早在 1990 年代初期，针对 C++ 的论点就会出现相同的情况。看看发生了什么。 如果企业可以通过技术获得优势，你可以打赌人们会接受培训。
这并不是说这是肯定的，或者在 3 到 5 年内不会出现反弹（一如既往）。不过，FP的趋势是有可取之处的，值得关注。
于 2009-01-06T21:31:07.683 回答
1
Slava Akhmechet有一篇很棒的文章，名为《Functional Programming For The Rest of Us》（顺便说一句，这篇文章让我进入了 FP）。在 FP 带来的好处中，他非正统地强调了以下几点（我相信这有助于吸引软件工程师）：
- 单元测试
- 调试
- 并发
- 热代码部署
- 机器辅助证明和优化
然后继续讨论 FP 更传统的讨论方面的优点，例如高阶函数、柯里化、惰性求值、优化、抽象控制结构（尽管不讨论单子）、无限数据结构、严格性、延续、模式匹配、闭包和很快。
强烈推荐 ！
于 2009-01-09T03:28:43.217 回答
1
我很难想象一种纯粹的函数式语言会成为当时的通用语言，我不会讨论的原因（因为它们是火焰素材）。话虽如此，以函数式编程可以提供任何语言的好处（如果它允许的话）。对我来说，这是更容易测试我的代码的能力。我经常使用数据库......我倾向于：
- 编写一个获取数据、操作数据并返回数据的函数
- 编写一个简单的包装器来调用数据库，然后返回通过我的函数传递数据的结果
这样做允许我为我的操作函数编写单元测试，而无需创建模拟等。
我确实认为纯函数式语言非常有趣……我只是认为对我来说重要的是我们可以从中学到什么，而不是我们可以用它们做什么。
于 2009-05-27T15:47:40.187 回答
0
于 2009-01-04T22:01:59.930 回答
0
我认为你的问题的答案更多地在于“工作的正确工具”这一陈述，而不是最热门的事情。总会有炙手可热的新技术出现，而且总会有人跃跃欲试。
函数式语言已经存在了一段时间，只是现在它们受到了更多的关注。
于 2009-01-05T11:45:59.890 回答
0
呃，很抱歉成为一个书呆子，但它已经流行起来了——我们称之为 Excel。
http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/
在计算机上运行的绝大多数程序都是用 Excel 或其许多流行的克隆之一编写的。
（有很多程序运行了很多次，而用 Excel 编写的程序往往不是这些程序 - 大多数 Excel 程序都有 1 个运行实例）
于 2009-01-05T12:15:05.310 回答
0
FP 肯定是下一个最佳范例。现在哪种语言可能是下一步，这是困难的事情，但我相信可能是 Haskell、F#、Clojure、Ocaml 或 Erlang。或者可以是具有更多 FP 结构和更好地支持并行性/性能的 Python，或者是带有 parrot 的 Perl 6，看起来非常有趣。
于 2009-01-05T14:23:02.150 回答
0
很多人都提到了函数式语言。
但是除了 Javascript 之外，目前使用的一些最常用的函数式语言。
Excel、SQL、XSLT、XQuery、J 和 K 用于金融领域。
当然是二郎。
所以我想说，从那个列表中可以看出，函数式编程技术每天都在主流中使用。
于 2009-01-18T19:23:40.550 回答
0
函数式编程很可能是工程师和科学家用来解决他们面临的问题的工具。它不会像早期的语言那样占据世界。然而，最难击败的产品是 Excel，如果我是一名工程师并且需要进行计算，Excel 非常棒。
然而，F# 将成为另一个来源，并且可能会满足非计算机科学家的设计需求。让我们面对现实吧，计算机科学家在创造一种全新的做事方式方面做得非常出色。面向对象编程很棒。但有时你只需要一种方法来求解方程，得到一个解并绘制它。就是这样。然后像 F# 这样的语言就可以满足要求。或者，也许您想构建一个有限状态机，F# 再次可能是解决方案之一，但 C 也可能是解决方案。
但在并行处理方面，Excel 大放异彩，F# 也将及时出现。不过，以友好的方式，F#= 友好。
于 2009-04-01T00:07:22.390 回答
0
Microsoft 确实在 Visual Studio 上推动 F# 的下一个版本。它是一种混合语言，例如 Scala，并且与 .net 框架的其余部分很好地集成在一起。我认为许多微软商店将使用它来加速高度并行数据处理应用程序和功能的开发。
于 2009-05-27T11:21:03.220 回答
0
我个人认为对于分布式系统和多线程/并行编程的函数式编程很快会有突破。只要它通过编程库与现有的 OOP 范式集成。所以......纯粹的功能方法 - 在我看来 - 将保持学术性。
于 2009-11-03T09:32:46.020 回答
0
函数式编程已经存在了很长时间，因为 LISP 是最早拥有编译器的语言之一，而且自 MIT 的 LISP 机器开始。这不是一个新范式（OO 更新得多），但占主导地位的软件平台倾向于用易于翻译成汇编语言的语言编写，并且它们的 API 非常支持命令式代码（UNIX 与 C、Windows 与 C 和 Macintosh 与 Pascal和后来的C）。
我认为过去几年的新创新是为了迎合各种 API，特别是对于平台 API 无关紧要的 Web 开发之类的事情。由于您没有直接对 Win32 API 或 POSIX API 进行编码，因此人们可以自由地尝试函数式语言。
于 2009-11-06T14:39:45.183 回答
-3
函数式编程已经在恕我直言，只是还不是很明显。这种语言的优势在于数学/算法，这也是 Halo Guys 将其用于他们的 TrueSkill 东西的原因之一。
于 2009-01-04T18:00:23.223 回答
-9
我不认为函数式语言能解决任何问题，这只是管理层试图推销的炒作，记住唯一的事实：
没有银弹。
其余的都是胡说八道，他们还说 OO 会解决我们的问题，Web Services 会解决我们的问题，Xml 会解决我们的问题，但最后还是应用了上述事实，一切都失败了。另外，二十年后，谁说我们将使用二进制计算机？为什么不是量子计算机？没有人能预测未来，至少在这个星球上不能。（这是第二个真理）
于 2010-10-13T21:45:11.797 回答