我在这里看到很多关于函数式语言和东西的讨论.你为什么要使用"传统"语言？他们做得更好？他们更糟糕的是什么？什么是理想的函数式编程应用程序？
功能语言使用与命令式和面向对象语言不同的范例.他们使用无副作用的函数作为语言的基本构建块.这使得许多事情变得更加困难(或者在大多数情况下与人们习惯的不同).
函数式编程的最大优点之一是无副作用函数的执行顺序并不重要.例如,在Erlang中,这用于以非常透明的方式启用并发.因为函数式语言中的函数与数学函数非常相似,所以很容易将它们转换为函数式语言.在某些情况下,这可以使代码更具可读性.
传统上,函数式编程的一大缺点也是缺乏副作用.在没有IO的情况下编写有用的软件非常困难,但IO很难在没有功能副作用的情况下实现.所以大多数人从来没有比从单个输入计算单个输出更多的功能编程.在像F#或Scala这样的现代混合范式语言中,这更容易.
许多现代语言都有来自函数式编程语言的元素.C#3.0有很多函数式编程功能,你也可以在Python中进行函数式编程.我认为函数式编程普及的原因主要是由于两个原因:并发性在普通编程中成为一个真正的问题,因为我们正在使用越来越多的多处理器计算机; 并且语言越来越容易获得.
我不认为编程"追赶"的功能方法有任何疑问,因为它已经使用了(作为一种编程风格)大约40年.每当OO程序员编写有利于不可变对象的干净代码时,该代码就是借用功能概念.
然而,强制执行功能风格的语言现在正在获得大量虚拟墨迹,以及这些语言将来是否会占据主导地位是一个悬而未决的问题.我自己怀疑Scala或OCaml等混合,多范式语言 可能会主导"纯粹"功能语言,就像纯OO语言(Smalltalk,Beta等)影响主流编程但尚未结束作为最广泛使用的符号.
最后,我无法抗拒地指出你的评论是FP与我多年前从程序程序员那里听到的评论高度平行:
(神话般的,恕我直言)"普通"程序员不理解它.
它没有被广泛传授.
您可以用它编写的任何程序都可以使用当前技术以另一种方式编写.
正如图形用户界面和"代码作为业务模型"是帮助OO得到更广泛认可的概念一样,我相信增加使用不变性和更简单(大规模)并行性将有助于更多程序员看到功能方法提供的好处.但是,尽管我们在过去50多年中已经了解了数字计算机编程的整个历史,但我认为我们还有很多需要学习的东西.二十年后,程序员将惊讶于我们目前使用的工具的原始性质,包括现在流行的OO和FP语言.
对我来说,主要的优点是它固有的并行性,特别是当我们正在从更多的MHz转向越来越多的内核时.
我认为它不会成为下一个编程范式并完全取代OO类型的方法,但我认为我们会发现我们需要用函数式语言编写一些代码,或者我们的通用语言将会成长为包含更多功能性结构.
即使您从未专业地使用函数式语言,理解函数式编程也会使您成为更好的开发人员.它将为您提供有关代码和编程的新视角.
我说没有理由不学习它.
我认为能够很好地融合功能和命令式风格的语言是最有趣的,并且最有可能成功.
我总是对下一件大事持怀疑态度.很多时候,下一件大事是纯粹的历史事故,无论技术是否好,都能在合适的时间出现在正确的地方.示例:C++,Tcl/Tk,Perl.所有有缺陷的技术都非常成功,因为它们被认为可以解决当时的问题,或者与根深蒂固的标准几乎相同,或两者兼而有之.功能编程可能确实很好,但这并不意味着它将被采用.
但我可以告诉你为什么人们对函数式编程感到兴奋:很多很多程序员都有过一种"转换体验",他们发现使用函数式语言可以使他们在生成时生成效率提高两倍(或者生产率提高十倍)代码更易于修改并且错误更少.这些人认为函数式编程是一种秘密武器; 这种心态的一个很好的例子是保罗格雷厄姆的击败平均数.哦,还有他的申请？电子商务网络应用程序.
自2006年初以来,关于函数式编程和并行性的讨论也很多.自从至少1984年以来,像Simon Peyton Jones这样的人一直在担心并行性问题,我不会屏住呼吸,直到函数式语言解决多核问题.但它确实解释了一些关于现在的额外嗡嗡声.
总的来说,美国大学在教授函数式编程方面做得很差.使用Scheme教授介绍编程有很强的核心支持,而Haskell也有一些支持,但是对功能程序员教授高级技术的方式却很少.我在哈佛大学教过这样一门课程,今年春天将在塔夫茨大学再次这样做.本杰明皮尔斯在宾夕法尼亚大学教过这样的课程.我不知道Paul Hudak在耶鲁大学做过什么.欧洲的大学做得更好; 例如,在丹麦,荷兰,瑞典和英国的重要地方强调功能性节目.我对澳大拉西亚的情况了解不多.
我没有看到有人在这里提到大象,所以我认为这取决于我:)
JavaScript是一种功能语言.随着越来越多的人用JS做更高级的事情,特别是利用jQuery,Dojo和其他框架的更精细点,FP将由Web开发人员的后门引入.
结合闭包,FP使JS代码非常轻巧,但仍然可读.
干杯,PS
大多数应用程序都很简单,可以通过正常的OO方式解决
OO方式并非总是"正常".这个十年的标准是过去十年的边缘化概念.
函数式编程是数学.关于Lisp的Paul Graham(Lisp的替代函数式编程):
因此,对于20世纪50年代语言为何没有过时的简短解释是,它不是技术而是数学,而数学并不是陈旧的.比较Lisp的正确之处不是20世纪50年代的硬件,而是Quicksort算法,它在1960年被发现并且仍然是最快的通用类型.
我敢打赌,当你使用时,你不知道你是函数式编程:
Excel公式
Quartz Composer
使用Javascript
徽标(龟图形)
LINQ
SQL
Underscore.js(或Lodash),D3
一般的企业程序员,例如我与之合作的大多数人,都不会理解它,大多数工作环境都不允许你在其中编程
那个只是时间问题.您的普通企业程序员可以学习当前的大事.15年前,他们不了解OOP. IF FP迎来了,您的"普通企业程序员"将会跟进.
它不是真的在大学教过(或者现在是不是？)
变化很大.在我的大学,SML是学生介绍的第一语言.我相信麻省理工学院教授LISP作为第一年的课程.当然,这两个例子可能不具有代表性,但我相信大多数大学至少提供一些关于FP的可选课程,即使它们没有成为课程的强制性部分.
大多数应用程序都很简单,可以通过正常的OO方式解决
然而,这并不是一个"足够简单"的问题.FP中的解决方案是否更简单(或更可读,更健壮,更优雅,更高效)？很多东西"很简单,可以在Java中解决",但它仍然需要一些神奇的代码.
在任何情况下,请记住,FP支持者声称它已成为几十年来的下一件大事.也许他们是对的,但请记住,他们在5年,10年或15年前做出同样的主张时并非如此.
然而,对他们有利的一件事是,最近,C#已经向FP急剧转向,实际上它将一代程序员转变为FP程序员,而他们甚至没有注意到.这可能只是为FP"革命"铺平了道路.也许.;)
如果他不能看到其他艺术的价值,他就无法理解他所选艺术的完美和不完美.遵循规则只允许在技术上达到一定程度,然后学生和艺术家必须学习更多并进一步寻求.研究其他艺术以及策略是有意义的.
通过观察他人的活动,谁还没有学到更多关于自己的东西？学习剑学习吉他.学习拳头学习商业.只是研究剑将使你心胸狭窄,不允许你向外生长.
- 宫本武藏,"五环之书"
我不认为大多数现实的人认为函数式编程会流行(成为像OO这样的主要范例).毕竟,大多数业务问题都不是很好的数学问题,而是毛茸茸的命令规则来移动数据并以各种方式显示它们,这意味着它不适合纯函数式编程范例(monad的学习曲线远远超过OO.)
OTOH,函数式编程使编程变得有趣.它让你欣赏宇宙底层数学的简洁表达所固有的,永恒的美.人们说学习函数式编程会让你成为更好的程序员.这当然是非常主观的.我个人认为这也不完全正确.
它会让你变得更有感染力.
功能语言的一个关键特性是一流功能的概念.这个想法是你可以将函数作为参数传递给其他函数并将它们作为值返回.
函数式编程涉及编写不改变状态的代码.这样做的主要原因是对函数的连续调用将产生相同的结果.您可以使用支持第一类函数的任何语言编写功能代码,但有些语言(如Haskell)不允许您更改状态.事实上,你根本不应该产生任何副作用(比如打印文本) - 听起来它可能完全没用.
相反,Haskell采用了不同的IO方法:monads.这些对象包含由解释器顶层执行的所需IO操作.在任何其他级别,它们只是系统中的对象.
函数式编程有哪些优点？功能编程允许编码具有较少的错误潜力,因为每个组件都是完全隔离的.此外,使用递归和第一类函数可以简单地证明正确性,这通常反映了代码的结构.
我必须密集,但我仍然没有得到它.有没有用F#这样的函数式语言编写的小应用程序的实际示例,您可以查看源代码,看看如何以及为什么使用这种方法比使用C#更好？
我想指出的是,一切你曾经说过关于函数式编程语言,大多数人都在大约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的改变是好的？
F#可能会流行,因为微软正在推动它.
优点:
F#将成为下一版Visual Studio的一部分
微软正在建立一段时间的社区 - 传播者,书籍,与知名客户合作的顾问,以及在MS会议上的重要曝光.
F#是一流的.Net语言,它是第一个带有非常大的基础的函数式语言(不是说我说Lisp,Haskell,Erlang,Scala,OCaml没有很多库,它们不像.Net那么完整是)
对并行性的强烈支持
魂斗罗:
即使你对C#和.Net很好,F#也很难开始 - 至少对我而言:(
可能很难找到优秀的F#开发人员
所以,我给F#50:50的机会变得重要.其他功能语言不会在不久的将来成功.
我认为一个原因是有些人认为语言是否被接受最重要的部分是语言有多好.不幸的是,事情很少这么简单.例如,我认为背后Python的接受的最大因素不是语言本身(尽管这是非常重要的).Python如此受欢迎的最大原因是它庞大的标准库以及更大的第三方库社区.
考虑到它们是基于JVM/CLR构建的,Clojure或F#等语言可能是规则的例外.结果,我没有他们的答案.
京公网安备 11010802040832号 | 京ICP备19059560号-6 