我在这里看到很多关于函数式语言的讨论。为什么你要使用传统语言而不是传统语言呢?他们在哪些方面做得更好?他们更不擅长什么?理想的函数式编程应用程序是什么?


当前回答

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

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

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

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

其他回答

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

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

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

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

一般的公司程序员,例如。 和我一起工作的大多数人都会 不懂它和大多数工作 环境不允许您编程 在这

不过,这只是时间问题。一般的公司程序员都在学习当前的大事。15年前,他们不懂面向对象编程。 如果FP流行起来,你的“普通公司程序员”也会跟上。

大学里并没有教过 (还是现在?)

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

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

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

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

不过,有一件事肯定是对他们有利的,那就是最近,c#向FP的方向急转直下,在某种程度上,它实际上正在把一代程序员变成FP程序员,而他们甚至没有注意到。这可能会为计划生育“革命”铺平道路。也许吧。;)

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

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

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

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

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

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