首页 文章

为何选择功能语言[关闭]

提问于
浏览
314

我在这里看到很多关于函数式语言和东西的讨论 . 你为什么要使用“传统”语言?他们做得更好?他们更糟糕的是什么?什么是理想的函数式编程应用程序?

30 回答

  • 11

    在阅读Tim Sweeney,Epic Games的“下一个主流编程语言:游戏开发者的视角”时,我的第一个想法是 - 我学习了Haskell .

    PPT

    Google's HTML Version

  • 2

    事情一直在朝着功能方向发展 . 过去几年中两个很酷的新孩子,Ruby和Python,都比以前更接近函数式语言 - 以至于一些Lispers开始支持其中一个或者“足够接近” .

    随着大规模并行硬件对每个人施加进化压力 - 以及处理变化的最佳位置的函数式语言 - 它并不像以前那样认为Haskell或F#将成为下一个重大事件 .

  • 8

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

    函数式编程的最大优点之一是无副作用函数的执行顺序并不重要 . 例如,在Erlang中,这用于以非常透明的方式启用并发 . 因为函数式语言中的函数与数学函数非常相似,所以很容易将它们转换为函数式语言 . 在某些情况下,这可以使代码更具可读性 .

    传统上,函数式编程的一大缺点也是缺乏副作用 . 在没有IO的情况下编写有用的软件非常困难,但IO很难在没有功能副作用的情况下实现 . 所以大多数人从来没有比从单个输入计算单个输出更多的功能编程 . 在像F#或Scala这样的现代混合范式语言中,这更容易 .

    许多现代语言都有来自函数式编程语言的元素 . C#3.0有很多函数式编程功能,你也可以在Python中进行函数式编程 . 我认为函数式编程普及的原因主要是由于两个原因:并发在正常编程中遇到了一个真正的问题,因为我们得到越来越多的多处理器计算机;并且语言越来越容易获得 .

  • 14

    我不认为编程“追赶”的功能方法有任何疑问,因为它已经使用了(作为一种编程风格)大约40年 . 每当OO程序员编写有利于不可变对象的干净代码时,该代码就是借用功能概念 .

    然而,强制执行功能风格的语言现在正在获得大量虚拟墨迹,以及这些语言将来是否会占据主导地位是一个悬而未决的问题 . 我自己的怀疑是混合的,多范式的语言,如ScalaOCaml,可能会超过"purist"功能语言,就像纯OO语言(Smalltalk,Beta等)影响主流编程一样,但最终没有像最广泛使用的符号 .

    最后,我无法抗拒地指出你的评论是FP与我多年前从程序程序员那里听到的评论高度平行:

    • (神秘的,恕我直言)"average"程序员不理解它 .

    • 没有广泛传授 .

    • 任何可以用它编写的程序都可以用现有技术以另一种方式编写 .

    正如图形用户界面和"code as a model of the business"是帮助OO得到更广泛认可的概念一样,我相信增加使用不变性和更简单(大规模)并行性将有助于更多程序员看到功能方法提供的好处 . 但是,尽管我们已经在_1748548中学到了构成数字计算机编程的整个历史,但我认为我们还有很多需要学习的东西 . 二十年后,程序员将惊讶于我们目前使用的工具的原始性质,包括现在流行的OO和FP语言 .

  • 11

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

    我认为它不会成为下一个编程范式并完全取代OO类型的方法,但我认为我们会发现我们需要用函数式语言编写一些代码,或者我们的通用语言将会成长为包含更多功能性结构 .

  • 204

    即使您从未专业地使用函数式语言,理解函数式编程也会使您成为更好的开发人员 . 它将为您提供有关代码和编程的新视角 .

    我说没有理由不学习它 .

    我认为能够很好地融合功能和命令式风格的语言是最有趣的,并且最有可能成功 .

  • 8

    我总是对Next Big持怀疑态度事情 . 很多时候,下一件大事是纯粹的历史事故,无论技术是否好,都能在合适的时间出现在正确的地方 . 例子:C,Tcl / Tk,Perl . 所有有缺陷的技术都非常成功,因为它们被认为可以解决当时的问题,或者与根深蒂固的标准几乎相同,或两者兼而有之 . 功能编程可能确实很好,但这并不意味着它将被采用 .

    但我可以告诉你为什么人们对函数式编程感到兴奋:很多很多程序员都有一种"conversion experience",他们发现使用函数式语言可以使它们生成两倍的效率(或者 生产环境 率的十倍)更有弹性,变化更少,错误更少 . 这些人认为函数式编程是一种秘密武器;这种心态的一个很好的例子是保罗格雷厄姆的Beating the Averages . 哦,还有他的申请?电子商务网络应用程序 .

    自2006年初以来,关于函数式编程和并行性的讨论也很多 . 自从至少1984年以来,像Simon Peyton Jones这样的人一直在担心并行性,我不会屏住呼吸,直到功能语言解决多核问题 . 但它确实解释了一些关于现在的额外嗡嗡声 .

    总的来说,美国大学在教授函数式编程方面做得很差 . 对于teaching intro programming using Scheme有很强的支持核心,Haskell也在那里得到了一些支持,但是哈佛大学已经在哈佛大学教过这样的课程,并且今年 Spring 天将在塔夫茨大学再次这样做 . 本杰明皮尔斯在宾夕法尼亚大学教过这样的课程 . 我不是在澳大拉西亚发生的事情 .

  • 125

    我没有看到有人在这里提到大象,所以我认为这取决于我:)

    JavaScript是一种功能语言 . 随着越来越多的人用JS做更高级的事情,特别是利用jQuery,Dojo和其他框架的更精细点,FP将由Web开发人员的后门引入 .

    结合闭包,FP使JS代码非常轻巧,但仍然可读 .

    干杯,PS

  • 2

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

    • OO方式并非总是“正常” . 这个十年的标准是过去十年的边缘化概念 .

    • 功能编程是数学 . Paul Graham on Lisp(替换Lisp的函数式编程):

    因此,为什么这种20世纪50年代的语言没有过时的简短解释是,它不是技术而是数学,数学不会变得陈旧 . 比较Lisp的正确之处不是20世纪50年代的硬件,而是Quicksort算法,它在1960年被发现并且仍然是最快的通用类型 .

  • 25

    我敢打赌,当你使用时,你不知道你是函数式编程:

    • Excel公式

    • Quartz Composer

    • Javascript

    • Logo(龟图)

    • LINQ

    • SQL

    • Underscore.js(或Lodash),D3

  • 77

    普通的公司程序员,例如与我合作的大多数人都不会理解它,大多数工作环境都不允许你在其中编程

    那个只是时间问题 . 您的普通企业程序员可以学习当前的大事 . 15年前,他们不了解OOP . 如果有人参与,你的_1748556将会跟进 .

    在大学里没有真正的教学(现在是不是?)

    变化很大 . 在我的大学,SML是学生介绍的第一语言 . 我相信麻省理工学院教授LISP作为第一年的课程 . 当然,这两个例子可能不具有代表性,但我相信大多数大学至少提供一些关于FP的可选课程,即使它们没有成为课程的强制性部分 .

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

    但这并不是"simple enough"的问题 . FP中的解决方案是否更简单(或更可读,更健壮,更优雅,更高效)?很多东西都是"simple enough to be solved in Java",但它仍然需要一些神奇的代码 .

    在任何情况下,请记住,FP支持者声称它已成为几十年来的下一件大事 . 也许他们是对的,但请记住,他们在5年,10年或15年前做出同样的主张时并非如此 .

    然而,对他们有利的一件事是,最近,C#已经向FP急剧转向,实际上它将一代程序员转变为FP程序员,而他们甚至没有注意到 . 这可能只是为FP铺平了道路"revolution" . 也许 . ;)

  • 4

    如果他不能看到其他艺术的 Value ,他就无法理解他所选艺术的完美和不完美 . 遵循规则只允许在技术上达到一定程度,然后学生和艺术家必须学习更多并进一步寻求 . 研究其他艺术以及策略是有意义的 .

    通过观察他人的活动,谁还没有学到更多关于自己的东西?学习剑学习吉他 . 学习拳头学习商业 . 只是研究剑将使你心胸狭窄,不允许你向外生长 .

    • 宫本武藏,“五环之书”
  • 5

    功能语言的一个关键特性是一流功能的概念 . 这个想法是你可以将函数作为参数传递给其他函数并将它们作为值返回 .

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

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

    函数式编程有哪些优点?功能编程允许编码具有较少的错误潜力,因为每个组件都是完全隔离的 . 此外,使用递归和第一类函数可以简单地证明正确性,这通常反映了代码的结构 .

  • 7

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

    OTOH,函数式编程使编程变得有趣 . 它让你欣赏宇宙底层数学的简洁表达所固有的,永恒的美 . 人们说学习函数式编程会让你成为更好的程序员 . 这当然是非常主观的 . 我个人认为这也不完全正确 .

    它会让你变得更有感染力 .

  • 2

    我必须密集,但我仍然没有得到它 . 有没有用F#这样的函数式语言编写的小应用程序的实际示例,您可以查看源代码,看看如何以及为什么使用这种方法比使用C#更好?

  • 18

    我会指出你所说的关于函数式语言的所有内容,大多数人在大约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的改变是好的?

  • 4

    F#可能会流行,因为微软正在推动它 .

    优点:

    • F#将成为下一版Visual Studio的一部分

    • 微软正在 Build 社区已有一段时间了 - 与高端客户合作的福音传教士,书籍,顾问,以及在MS Session 上的重要曝光 .

    • F#是一流的.Net语言,它是第一个带有非常大的基础的函数式语言(不是说我说Lisp,Haskell,Erlang,Scala,OCaml没有很多库,它们不像它那样完整 . 网是)

    • 对并行性的强力支持

    魂斗罗:

    • F#很难开始,即使你对C#和.Net很好 - 至少对我来说:(

    • 可能很难找到优秀的F#开发人员

    所以,我给F#50:50的机会变得重要 . 其他功能语言不会在不久的将来成功 .

  • 3

    我认为一个原因是 some people feel that the most important part of whether a language will be accepted is how good the language is . 不幸的是,事情很少这么简单 . 例如,我认为Python语言本身背后的最大因素(虽然这很漂亮重要) . Python如此受欢迎的最大原因是它庞大的标准库以及更大的第三方库社区 .

    考虑到它们是基于JVM / CLR构建的,Clojure或F#等语言可能是规则的例外 . 结果,我没有他们的答案 .

  • 3

    大多数应用程序可以通过[插入您喜欢的语言,范例等]来解决 .

    虽然这是事实,但可以使用不同的工具来解决不同的问题 . 功能只允许另一个高(更高?)级别的抽象,允许在正确使用时更有效地完成工作 .

  • 194

    在我看来,那些从未学过Lisp或Scheme作为本科生的人现在正在发现它 . 与这个领域的很多事情一样,人们倾向于炒作并创造很高的期望......

    会过去的 .

    功能编程很棒 . 但是,它不会接管世界 . C,C,Java,C#等仍然存在 .

    我认为会有更多的跨语言能力 - 例如用功能语言实现事物,然后用其他语言访问这些东西 .

  • 55

    您最近是否一直在关注编程语言的发展?所有主流编程语言的每个新版本似乎都从功能编程中借用了越来越多的功能 .

    • 闭包,匿名函数,传递函数和返回函数作为值,这些函数只是Lisp和ML黑客所知的异域特征 . 但逐渐地,C#,Delphi,Python,Perl,Javascript,增加了对闭包的支持 . 如果没有关闭,任何崭露头角的语言都不可能被认真对待 .

    • 有几种语言,特别是Python,C#和Ruby,它们对列表推导和列表生成器有本机支持 .

    • ML在1973年开创了泛型编程,但对泛型(“参数多态”)的支持在过去5年左右才成为行业标准 . 如果我没记错的话,Fortran在2003年支持泛型,其次是2005年的Java 2004,C#,2008年的Delphi . (我知道C自1979年以来一直支持模板,但是关于C的STL的90%的讨论都是从这里开始的 . 恶魔” . )

    是什么让这些功能吸引程序员?它应该是显而易见的: it helps programmers write shorter code . 如果他们想要保持竞争力,未来所有语言都将支持 - 至少 - 关闭 . 在这方面,功能性编程已经成为主流 .

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

    谁说不能将函数式编程用于简单的事情呢?并非每个功能程序都需要是编译器,定理证明器或大规模并行电信交换机 . 除了我更复杂的项目之外,我经常使用F#作为临时一次性脚本 .

  • 33

    它是控制复杂性的最佳工具 . 看到:

    • Simon Peyton-Jones谈话的幻灯片109-116 "A Taste of Haskell"
    • 蒂姆斯威尼的"The Next Mainstream Programming Language: A Game Developer's Perspective"
  • 2
  • 25

    我同意第一点,但时间会改变 . 即使他们是后期采用者,如果他们认为有优势,公司也会做出回应 . 生活充满活力 .

    他们在90年代后期在斯坦福大学教授Haskell和ML . 我确信像卡内基梅隆大学,麻省理工学院,斯坦福大学和其他好学校这样的学校都会向学生们展示 .

    我同意大多数“暴露网络上的关系数据库”应用程序将在这种情况下持续很长时间 . Java EE,.NET,RoR和PHP已经为这个问题发展了一些非常好的解决方案 .

    你已经找到了一些重要的东西:它可能是一个无法通过其他方法轻松解决的问题,这些方法将促进函数式编程 . 那会是什么?

    将大规模的多核硬件和 Cloud 计算推动它们发展?

  • 3

    因为FP在 生产环境 率,可靠性和可维护性方面具有显着优势 . 尽管存在大量的遗留代码,但很多核心可能是一个杀手级的应用程序最终让大公司转换 . 此外,即使像C#这样的大型商业语言也会因许多核心问题而产生不同的功能 - 副作用只是简单的不适合并发性和并行性 .

    我不同意“普通”程序员不会理解它 . 他们会像他们最终理解OOP一样(这也是神秘而奇怪的,如果不是更多的话) .

    此外,大多数大学都教授FP,许多大学甚至教它作为第一门编程课程 .

  • 2

    哇 - 这是一个有趣的讨论 . 我自己的想法:

    FP使一些任务相对简单(与非FP语言相比) . 非FP语言已经开始从FP中获取想法,所以我怀疑这种趋势将继续下去,我们将看到更多的合并,这应该有助于人们更容易实现FP的飞跃 .

  • 4

    我不知道它是否会流行,但从我的调查来看,功能语言几乎肯定值得学习,并会让你成为一个更好的程序员 . 只需了解参考透明度,就可以使很多设计决策变得更加容易,并且所得到的程序更容易推理 . 基本上,如果遇到问题,那么它往往只是单个函数输出的问题,而不是不一致状态的问题,这可能是由数百个类/方法/函数中的任何一个引起的在一种具有副作用的比较语言中 .

    FP的无状态特性更自然地映射到Web的无状态特性,因此功能语言更容易为更优雅的RESTFUL Web应用程序提供支持 . 与JAVA和.NET框架形成对比,这些框架需要使用像VIEWSTATE和SESSION键这样可怕的丑陋HACK来维护应用程序状态,并在基本无状态的功能平台(如Web)上维护有状态命令语言的(偶尔相当漏洞)抽象 .

    而且,您的应用程序越无用状态,它就越容易适用于并行处理 . 如果您的网站很受欢迎,那么对网络来说非常重要 . 为站点添加更多硬件以获得更好的性能并不总是直截了当的 .

  • 1

    我的观点是,现在微软已经将其推向主流市场 . 对我而言,这是有吸引力的,因为它可以为我们做些什么,因为这是一个新的挑战,并且由于工作机会,它对未来感到不满 .

    一旦掌握,它将成为另一个工具,进一步帮助我们提高程序员的工作效率 .

  • 3

    在讨论中遗漏的一点是,当代FP语言中找到了最好的类型系统 . 更重要的是,编译器可以自动推断所有(或至少大多数)类型 .

    有趣的是,在编写Java时,花费一半的时间编写类型名称,但Java到目前为止并不是类型安全的 . 虽然您可能永远不会在Haskell程序中编写类型(除了作为一种编译器检查文档)并且代码是100%类型安全的 .

  • 2

    除了其他答案之外,用纯函数术语来解决方案迫使人们更好地理解问题 . 相反,以功能性方式思考将发展出更好的解决问题的能力 .

    *要么因为功能范例更好,要么因为它会提供额外的攻击角度 .

相关问题