it-swarm.cn

为什么函数式编程在业界并不流行?现在流行吗?

在我上大学的四年中,我们一直在使用多种函数式编程语言来使用许多函数式编程。但是我也使用了许多面向对象的编程,实际上,在做自己的小型项目以准备我的第一份工作时,我更多地使用了面向对象的语言。但是我经常希望在执行这些项目时使用功能性编程语言进行编码。

但是,在找工作时,很少会看到需要功能编程语言知识的工作。

为什么函数式编程语言在业界没有得到更多使用?如今,有关函数式编程语言的新闻很多,所以我想知道函数式编程现在是否在行业中流行起来?

61
Jonas

我要说的是,函数式编程并不流行的原因之一是缺乏知识库。我的经验是,就实施非主流技术而言,公司非常不愿意承担风险,而宁愿投资于久经考验的真实框架(Java,c ++,c#)。只有在有业务需求时(例如在爱立信中),才考虑新的范例。但是,即使在爱立信的案例中,我也听说管理层要求使用c ++,并且Joe Armstrong被迫用c ++编写erlang调用代码!这应该显示出公司多么不情愿实施新技术!

38
ennuikiller

我曾经是一名教授,就像程序员一样,教授们一直在寻找下一个大东西。当他们以为自己找到了一个,就把它当成潮流,所有人聚集在一起。因为他们在向那些认为教授必须非常聪明的学生讲道,否则为什么要当教授,他们却没有抵抗力。

函数式编程就是这样的潮流。当然,这里有很多尼斯有趣的问题需要调查,还有很多有趣的会议文章要写。这不是一个特别新颖的想法,您几乎可以使用任何现代语言来实现它,并且想法不必新颖就可以变得有趣。这也是一项很好的技能。

鉴于此,函数式编程只是箭袋中的一支箭,而不是唯一的一支箭,就像OOP不是唯一的一支箭)。

我与计算机科学学术界的牛肉缺乏与行业的实际互动,无法确定实际意义上的实际含义,即质量控制。如果存在那种质量控制,那么可能会有所不同,重点放在对问题及其解决方案的分类上,需要权衡取舍,而不仅仅是最新的潮流。

67
Mike Dunlavey

因为如今软件开发中最大的问题是管理复杂性的能力。这不是大多数功能编程语言的重点。因此,以do为优先的语言(即,更流行的OOP语言))往往会窃取一些较学术性的更酷的功能功能语言,因此保持领先地位。

25
Fishtoaster

函数式编程肯定已经开始流行-缓慢但肯定地。

例如,由于以下原因,我正在构建的初创公司正在使用功能语言(Clojure)作为主要开发语言:

  • 生产力-学习FP很难,但是一旦掌握了它,就很难说服他与我在C#或Java中所需的功能相比,我大概写了大约1/10的行数来实现任何给定的功能

  • 可靠性-纯函数比有状态对象容易推理和测试。因此,您可以编写更好的测试并更轻松地验证代码的正确性。

  • 并发性-功能语言强调不变性,与并发应用程序相比,它需要在多个内核上有效运行,因此具有巨大优势。不管您是否喜欢,运行在多个内核上都是未来。请参阅 http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey ,以轻松了解为何如此重要

  • 可组合性/模块化-功能语言似乎比复杂的OO还没有找出造成这种情况的所有原因,但部分原因是您没有OO)模型随其拖来拖去的所有“偶然复杂性”。 Stuart Halloway的Radical Simplicity 更深入地探讨了这些想法。

[〜#〜] edit [〜#〜]:为回应Despertar的评论,一个“偶然复杂性”的示例OOP限制模块性的系统是深度克隆与浅层克隆的问题:如果不仔细分析克隆和突变语义,就无法将对象组​​合在一起并以复合结构形式传递它们。可以管理,但是在复杂的系统中,它很快就成为一个严重的问题,如果您仅依赖纯函数数据结构,那么这个问题就不会存在。

24
mikera

缺少杀手级应用

嘿,这边看起来很新鲜。 (挖挖)

我认为大多数编程语言都是通过拥有“杀手级应用程序”而蓬勃发展的,这是该语言所独有的(或以这种方式来看)。这并不是说所有的使用都是那个应用,而是它使语言受到了更大的接受。

对于什么利基推动了我们今天使用的某些语言的采用,我的观点并不十分准确。

  • C:无处不在(这是70年代和80年代后期)
  • C++:GUI框架(90年代初)
  • Java:Applet和Servlet(在90年代后期)
  • Objective-C:iOS应用(之前为OS X应用)
  • Ruby:Rails
  • C#:ASP.NET,WinForms
  • PHP:Wordpress等.
  • Javascript:AJAX,尤其是通过框架
  • lua:游戏脚本,尤其是《魔兽世界》

除此之外,许多强大的销售组织(甲骨文,以及程度较小的微软公司的语言)也进入了专有语言,从而有效地建立了自己的利基市场。

关于该列表的一个非常重要的注意事项:杀手级应用程序指出,该语言的“利基”随着数十年的过去变得越来越具体。请注意列表中的最后一个:游戏脚本。由于另一种语言已经可以很好地完成工作,因此语言越来越难以引起人们的注意。

因此,任何功能语言真正需要起飞的都是一个利基市场。实际上,还没有任何强大的功能语言,但是在较小的领域有很多东西:

  • Emacs LISP:自80年代以来在开发人员中不断使用Emacs。 ( 几乎没有 在其他任何地方使用。)
  • Erlang:任何需要大量并发代理的地方。
  • 计划:教育
  • APL/J/K:财务(为方便起见,我们称其为功能性)
  • 常见的LISP:“ AI”-人们倾向于说它的用途,这是一种祝福和诅咒。

现在,我觉得我脱离讨论的唯一主要语言是Python。 Python做的很有趣;它成功了,但似乎没有成为任何主要利基市场的赢家。这可以表示我以这种方式查看语言受欢迎程度完全是错误的,也可能意味着没有杀手级应用的情况下,足够好的语言可能会受欢迎来提高采用率和接受度,但这是非常困难的,并且可能需要很长时间(Perl也有类似的故事,但几年前就出现了,现在的普及率降低了)。

由此,我可以说出我认为正在使用的哪些功能语言

  • Clojure:网络编程,尤其是。通过Heroku
  • Scala:提升(或者最近可能是Play)-没有Java的JVM

如果您问我接下来在哪里可以找到流行的功能语言,那我想说的是寻找具有交钥匙型云开发(la Heroku或GAE)或交钥匙型移动应用程序开发的功能语言。

12
Jesse Millikan

出于同样的原因,LISP从未真正流行起来(让火焰战争开始!)。与命令式和面向对象的编程相比,函数式编程是一种非常陌生的范例。如果像绝大多数CS学生一样,您从C入手,后来又发展为C++/Java,那么您倾向于不想学习与通常的思维方式完全正交的思维方式。

9
Chinmay Kanchi

让我们考虑一下业务和编程。

有些企业将其软件用作战略资产。这不是典型的。对于大多数企业而言,IT可以支持公司的实际业务。这是必要的费用。他们之所以很保守,是因为他们知道只要花$ X就能获得所需的IT,而如果改用其他东西,如果一切顺利的话,他们将节省不到$ X,而如果一切不好的话,则将损失大量资金。

此外,在企业中,最便宜的事情通常是他们昨天所做的事情。然而,期望改变是昂贵的。如果一家公司要从例如C#/。NET解决方案更改为F#,那么他们就会遇到问题。他们的程序员(可能不是那里最聪明的程序员)将不得不学习一种新语言,并且精通两种语言,并且经常使用这两种语言。会有很长一段时间都用这两种语言编写的例程。如果他们要迁移到Haskell之类的东西,或者如果他们首先使用C++/MFC,那么他们将进行更多的更改,这将花费更多。

另外,在很长的一段时间内,将有大量的C#程序员和Microsoft的持续支持。当前的IT实践可以指望。没有同等水平的机构支持或程序员持续可用性的保证。

因此,对于大多数企业而言,对功能编程的更改在一开始就很昂贵,并且只有从长期来看,IT成本的降低足以使它自己得到回报,这才是值得的。

6
David Thornley

您已经以功能样式编写了代码,只是您不知道。

当需要对代码进行单元测试时,您倾向于编写可测试的函数,这些函数不创建也不依赖于副作用,并且始终在相同的参数上返回相同的结果(所谓的纯函数)。这是功能程序的主要优点。

我认为函数式语言太局限了。因此,命令式语言将取代功能性命令语言,而不是功能性命令语言。如今,几乎每种编程语言都有闭包和lambda。

2
Calmarius

我相信您的问题只有一个真正的答案。您可能会找到很多相关原因说明为什么要这样做,但这是不同的问题。

这里是:

  • 软件架构师提供了他们相信可以使用的解决方案。
  • 大多数架构师都不使用功能语言。
  • 一旦选择了技术和语言,企业就会找到可以与他们合作的人。

流行了吗?这完全取决于对使用功能性语言有信心的人是否正在成为架构师,并选择将其用于他们从事的项目。

1
John Fisher

真正的问题是状态。

功能语言没有全局状态。大多数工业问题都需要大规模的状态(您如何表示分类帐或一组交易),即使小规模的某些功能实际上并不需要它(处理分类帐)。

但是我们正在Von-Neuman体系结构机器上运行代码,这些机器本质上是全状态的。因此,我们实际上并没有摆脱状态,功能语言只是向开发人员隐藏了状态的复杂性。这意味着语言/编译器必须处理后台状态并对其进行管理。

因此,尽管功能语言没有全局状态,但它们的状态信息将作为参数和结果传递。

那么问题就变成了语言可以在感觉背后有效地处理状态吗?尤其是当数据大小远远超过体系结构的大小时。

从硬件方面看

在过去的几年中,该操作系统在可视化地址空间方面提供了很多帮助,因此应用程序无需正式担心它。但是,当内存压力越来越大时,不必担心的应用程序就会陷入硬件崩溃的陷阱(硬件崩溃会使您的进程减慢爬行速度)。

由于程序员无法直接控制功能语言中的状态,因此他们必须依靠编译器来处理此问题,而且我还没有看到能很好地处理此状态的功能语言。

相反,全状态编程器可以直接控制状态,因此可以补偿低内存条件。尽管我还没有看到很多程序员足够聪明。

从行业角度看:

工业界有许多效率低下的全状态编程器。

但是很容易衡量这些程序随时间的改进。您使开发人员团队陷入一个问题,即他们可以通过改善程序处理状态的方式来改进代码。

对于功能性程序,改进更多难以衡量,因为您需要改进将改进程序的工具(我们只是在这里研究应用程序如何有效处理基础状态,而不是程序的整体改进) )。

因此,对于行业而言,我认为这取决于衡量代码改进的能力。

从招聘的角度

有很多统计量充足的程序员可供雇用。功能性程序员很难找到。因此,如果行业转换为功能样式编程,那么您的基本供需模型就会启动,而这并不是他们想要发生的事情(程序员本身就足够昂贵了)。

0
Martin York