为什么使用功能语言?[关闭]


332

我在这里看到了很多有关功能语言和内容的讨论。您为什么要使用一种“传统”语言?他们有什么优势?他们最糟糕的是什么?什么是理想的函数式编程应用程序?


约翰·休斯(John Hughes)撰写了一篇关于以下内容的文章:函数编程为何如此重要
Hjulle

Answers:


214

功能语言使用的语言范式不同于命令式和面向对象的语言。他们使用无副作用功能作为该语言的基本构建块。这使很多事情变得复杂,并使很多事情变得更加困难(或者在大多数情况下与人们习惯的事情有所不同)。

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

传统上,函数式编程的主要缺点之一就是缺乏副作用。没有IO编写有用的软件非常困难,但是没有功能上的副作用很难实现IO。因此,大多数人从函数式编程中获得的不仅仅是从单个输入计算单个输出。在F#或Scala等现代混合范例语言中,这更容易。

许多现代语言都包含功能编程语言中的元素。C#3.0具有许多函数式编程功能,您也可以使用Python进行函数式编程。我认为函数式编程之所以流行,主要是因为两个原因:并发在普通编程中已成为一个真正的问题,因为我们越来越多地使用多处理器计算机。并且语言变得越来越容易访问。


14
您可以使用python进行函数式编程,但这确实很糟糕。stackoverflow.com/questions/1017621/...
戈登·古斯塔夫森

28
不是很难写在纯函数式语言IO代码。它们都提供了一种编写IO代码的简单机制,就像在命令性语言中一样。他们所做的只是强制您不能在接口被声明为不执行IO的其他代码中调用IO代码。比方说动态语言程序员会抱怨说,像Java这样的静态类型的语言很难从方法中返回她想要的任何类型,因为她必须返回所要返回的类型声明。
2014年

9
Haskell是纯函数语言的示例,它没有您所说的缺点。实际上,由于副作用是经过封装的,因此使副作用的处理变得更加容易,并且使程序员能够比命令式语言实现更强大的抽象级别……确实,每个人都应该尝试一下Haskell,真正地掌握它并意识到为什么它如此强大。
FtheBuilder

202

我认为关于“捕捉”编程的功能方法没有任何问题,因为它已经被使用了40年(作为一种编程风格)。每当OO程序员编写支持不可变对象的简洁代码时,该代码就是借用了功能概念。

但是,如今,强制执行功能样式的语言越来越多地受到人们的追捧,这些语言在未来是否会占据主导地位是一个悬而未决的问题。我自己的怀疑是,诸如ScalaOCaml之类的混合,多范式语言 可能会以“纯粹”功能语言为主,就像纯OO语言(Smalltalk,Beta等)影响主流编程一样,但还没有结束成为使用最广泛的符号。

最后,我忍不住指出,您对FP的评论与几年前我从程序程序员那里听到的评论高度相似:

  • (神话般的恕我直言)“平均”程序员不理解它。
  • 它没有被广泛教导。
  • 您可以使用它编写的任何程序都可以使用当前技术来编写。

就像图形用户界面和“代码作为业务模型”是帮助OO得到更广泛认可的概念一样,我相信增加使用不变性和更简单(大规模)并行性将帮助更多的程序员看到功能方法所带来的好处。 。但是,尽管过去50多年左右我们所学到的知识构成了数字计算机编程的整个历史,但我认为我们仍有很多东西要学习。从现在开始的20年后,程序员会惊奇地回想到我们当前正在使用的工具的原始性质,包括现在流行的OO和FP语言。


55
只是回首20年。我认为编程并没有发展太多。拥有更好的工具,也许是一门新语言或2种语言,但从根本上讲并不会改变太多。这将需要20多年的时间。我们都曾经以为我们会在2000
bibac

32
奥卡姆虽然是爱尔兰人。
defmeta,2009年

7
@alex奇怪:在面向对象和命令式编程学校中,“好不变性”和“避免副作用”在相当长的一段时间内一直是很好的经验法则。(那么不喜欢什么?;-)
joel.neely

101
@bibac:20年前,我们正在编写C代码,并讨论Clipper或Turbo Pascal的优点。面向对象是学术界的专有领域。提出几乎没有改变的提议是完全荒谬的。
Daniel C. Sobral

24
@Daniel:请提供这些为Clipper的“优点”辩护的人的名单。他们需要被追捕并绳之以法。
David

125

对我来说,主要优点是其固有的并行性,尤其是当我们现在从更多的MHz转向越来越多的内核时。

我不认为它将成为下一个编程范式并完全替代OO类型的方法,但是我确实认为我们将需要用功能性语言编写一些代码,或者我们将使用通用语言来实现这一点。成长为包含更多功能结构。


4
我们已经看到了这种情况。而且将来还会发生更多。所以我同意这一点100%。
杰森·贝克

棘手的事情是,正是FP的无共享/无副作用方面使得FP非常适合并行处理。这些都是面向对象解决方案不适合的方面-要使有效的混合动力非常困难。也许FP粘在OO节点之间?
James Brady

对于有效的混合动力,请查看D编程语言的2.0分支。这是一个正在进行的Alpha /工作,但正在实现。
dsimcha,2009年

2
我发现这个答案很有趣,我不知道任何功能性语言,为什么它们被认为更适合并行性?
andandandand

26
由于没有共享数据,因此函数没有副作用。您只关心返回值。(对于OO /过程程序员来说,这是一个很难的主意。)因此,只要不将一个函数的输出用作另一个函数的输入,就可以一次调用许多函数。
汤姆·史密斯,

79

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

我说没有理由不学习它。

我认为将功能和命令式风格完美融合的语言最有趣,而且最有可能成功。


好点,但我想看看“它将以何种方式使您成为更好的开发人员”的解释
mt3,2009年

20
不同的编程范例从不同的角度处理问题,并且通常需要“不同的思维方式”或思维方式。用多种不同的思维方式训练自己(暗示学习在哪种情况下使用哪种方式...)从来不是一件坏事。
peSHIr

56

我一直对下一件大事持怀疑态度。很多时候,“下一件大事”纯粹是历史的偶然,无论技术是否良好,都在正确的时间,正确的时间出现在正确的地方。示例:C ++,Tcl / Tk,Perl。所有有缺陷的技术都取得了巨大的成功,因为它们被认为可以解决当今的问题或与根深蒂固的标准几乎完全相同,或两者兼而有之。函数式编程确实确实很棒,但这并不意味着它将被采用。

但是我可以告诉你,为什么人们对函数式编程感到兴奋:许多程序员都有一种“转换经验”,他们发现使用函数式语言使他们在生产时的生产率提高两倍(或者可能是生产率的十倍)。具有更强的变更弹性和更少错误的代码。这些人认为函数式编程是秘密武器。保罗·格雷厄姆(Paul Graham)的《击败平均水平》Beating the Averages)是一个很好的例子。哦,他的申请?电子商务Web应用程序。

自2006年初以来,关于函数式编程和并行性的话题也越来越多。自从至少从1984年以来,像Simon Peyton Jones这样的人就一直担心并行性,所以直到功能语言解决多核问题之前,我都不会屏息。但这确实解释了目前的一些其他嗡嗡声。

总体而言,美国大学在执行功能编程方面做得很差。对于使用Scheme进行入门编程的教学,有强大的支持核心,而Haskell也在那里获得了一些支持,但是对于函数式程序员而言,教授高级技术的方式很少。我曾在哈佛大学教授过这样的课程,今年春天将在塔夫茨大学再次授课。本杰明·皮尔斯(Benjamin Pierce)在宾夕法尼亚州(Penn)教授过这样的课程。我不知道保罗·哈达克(Paul Hudak)是否在耶鲁做过任何事情。欧洲的大学做得更好。例如,在丹麦,荷兰,瑞典和英国的重要地方都强调了函数式编程。我对大洋洲发生的事情不太了解。


我不了解英国的大学。您很有可能会发现这里的许多大学都只教授很少的编程语言(Java,C,如果幸运的话,也许是Perl)。这里的问题是质量上的差异,因为最好的(很少)大学拥有最好的CS课程。
麦克B

我不同意您提供的示例有缺陷,适当或可能适合某些领域,但其通用目的足以在没有庞大学习曲线的情况下被普遍采用。这可能是他们如此成功的最大原因。
gbjbaanb,2009年

我在英国的uni大学(以及Pascal,C,Modula2和Cobol)做过Forth和Lisp,但那是20年前了
。– kpollock

29
我曾在uni(在澳大利亚)教过Java / C ++,但我的一些同事去了不同的大学,在那里他们在Haskell开设了多个部门。它既用于编程入门,又用于最后一年的学习。当我第一次听到他的同事对Java讲师说的话时,我笑了(这时他只知道Haskell)-“什么?! t 知道它是什么类型?!”
雅各布·斯坦利

1
看看在团队中所有这些欧洲人身上C#发生了什么:)
Benjol 2010年

32

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

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

结合使用闭包,FP使JS代码非常轻便,但仍然可读。

干杯,PS


2
这就是我真正开始研究函数式编程的方式。没有什么比Prototype.js的list.Each(function(item){})或jQuery的整个操作方法更好。
科里·金

20
Javascript允许人们以一种实用的方式进行编程。它是,但是,一个跨范式语言,允许一个程序以各种不同的方式(这是我比较喜欢,但是这是不相关)... OO,功能,程序等
RHSeeger

+1,请参阅codex.sigpipe.cz/zeta
只是

jQuery对象方法只是列表monad中的操作。将代表容器(或序列)的对象作为输入并返回对象容器作为输出,这是对fmap进行实际改造的一个很好的例子。
贾里德·厄普代克

25

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

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

  2. 函数式编程是数学。Paul Graham谈Lisp(用Lisp替代功能编程):

因此,对于为什么这种1950年代的语言没有过时的简短解释是,它不是技术而是数学,并且数学不会过时。比较Lisp的正确方法不是1950年代的硬件,而是Quicksort算法,该算法于1960年发现,仍然是最快的通用排序算法。


25

我敢打赌,您在使用时不知道自己是函数式编程:

  • Excel公式
  • 石英作曲家
  • 的JavaScript
  • 徽标(海龟图形)
  • LINQ
  • 的SQL
  • Underscore.js(或Lodash),D3

10
Javascript如何被视为函数式编程?
Pacerier 2014年

8
它具有一流的功能,高阶功能,闭包,匿名功能,部分应用程序,库里和构成。
daniel1426 2014年

2
哈哈。一旦编写了一个负载还款Excel公式,该公式比具有嵌套函数的屏幕还要宽。我当时知道我在进行功能编程,但还不知道该术语。
ProfK 2014年

7
请将C添加到该列表中
Mandeep Janjua 2015年

2
@MandeepJanjua:嗯?怎么来的?还是为什么不使用任何语言呢?
Sz。

18

一般的公司程序员(例如,与我一起工作的大多数人)不会理解它,并且大多数工作环境都不允许您在其中编程

不过那只是时间问题。您的普通公司程序员会学到当前的大事。15年前,他们不了解OOP。 如果 FP赶上了潮流,那么您的“普通公司程序员”将紧随其后。

它不是在大学真正教授的(或者现在是吗?)

变化很大。在我的大学中,SML是向学生介绍的第一门语言。我相信麻省理工学院将LISP教授为一年级课程。当然,这两个示例可能并不具有代表性,但是我相信大多数大学至少都提供一些关于FP的可选课程,即使他们没有将FP设置为必修课程。

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

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

无论如何,请记住,FP拥护者声称这是几十年来的下一件大事。也许他们是对的,但请记住,在5、10或15年前提出相同主张时,事实并非如此。

不过,绝对值得他们青睐的一件事是,最近C#向FP迈出了重大步伐,以至于它实际上使一代程序员变成了FP程序员,甚至没有引起他们的注意。这可能只是为FP“革命”铺平了道路。也许。;)


麻省理工学院在CS入门课程中曾经教过Scheme,但是现在使用Python。
mipadi

1
“ 15年前,他们不了解OOP”-问题是15年前,他们也不了解FP。他们今天仍然没有。
杰森·贝克

15

人如果看不到其他艺术的价值,就无法理解自己选择的艺术的完美和不完美。遵循规则只能使技术发展到一定程度,然后学生和艺术家必须学习更多并寻求进一步的发展。研究其他艺术以及战略艺术都是有意义的。

谁没有通过观看他人的活动而对自己有所了解?要学习剑,就要学习吉他。学习拳头学习商业。仅学习剑将使您头脑狭窄,不会让您向外生长。

宫本武藏(Miyamoto Musashi),《五环书》


12

功能语言的一个主要功能是一流功能的概念。这个想法是,您可以将函数作为参数传递给其他函数,然后将它们作为值返回。

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

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

函数式编程提供什么优势?由于每个组件都是完全隔离的,因此函数式编程可以减少潜在的错误编码。另外,使用递归和一流的功能还可以提供简单的正确性证明,这些证明通常反映了代码的结构。


12

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

OTOH,函数式编程使编程变得有趣。它使您欣赏宇宙基本数学的简洁表达所固有的永恒的美丽。人们说学习函数式编程将使您成为更好的程序员。这当然是高度主观的。我个人也不认为那是完全正确的。

它使你变得更好。


6
我不认为OO本质上比FP容易。这确实取决于您的背景(我是一个数学专家,您猜我觉得容易得多吗?
temp2290,2009年

14
Monad不难理解。不要买那废话。
Rayne,2009年

-1 OOP比FP难
有人在2009年

-1如果FP仅适用于漂亮的数学问题,我们不会使用OCaml或Haskell编写优化编译器。
gracchus 2014年

8

我一定很稠密,但我还是不明白。是否有用F#这样的功能语言编写的小型应用程序的实际示例,您可以在其中查看源代码,并了解使用这种方法比使用C#更好和如何的原因。


好评+1。@Mendelt:“更方便”?您是说看代码时头疼更快吗?
帕特里克·奥诺涅兹

2
请参阅以下F#库:quanttec.com/fparsec/tutorial.html。我很想看看带有解析器的C#中的示例代码,即使它们被编译为相同的指令,它们的外观和可读性也仅为F#代码的一半。并尝试将FParsec从F#移植到C#,看看代码是如何膨胀的。
贾里德·厄普代克

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的更改是件好事吗?


2
*一般的公司程序员,例如与我一起工作的大多数人,不会理解它,并且大多数工作环境都不允许您在其中编程- 在我工作过的许多地方,OOP 仍然是这样:)(当然,他们他们正在做OOP,但不是)
tolanj

7

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

优点:

  • F#将成为Visual Studio下一版本的一部分
  • 微软正在建立社区已有一段时间了,他们是与知名客户合作的传播者,书籍,顾问,在MS会议上的知名度很高。
  • F#是一流的.Net语言,它是第一个具有真正基础的功能语言(并不是说Lisp,Haskell,Erlang,Scala,OCaml没有很多库,它们不如.Net完整)是)
  • 强烈支持并行

相反:

  • 即使您精通C#和.Net,也很难启动F#-至少对我而言:(
  • 可能很难找到好的F#开发人员

因此,我给F#50:50的机会,使其变得很重要。其他功能语言不会在不久的将来实现。


6
我认为Scala是JRE的相当深厚的基础。
cdmckay

2
关于库,这实际上取决于您在做什么。F#针对金融领域,也适用于科学计算,但OCaml实际上具有比.NET更好的此类应用程序库。例如,当我从OCaml进入F#时,我找不到合适的FFT,最终用C#然后是F#编写(并出售)自己的FFT。
乔恩·哈罗普

1
LINQ是一个很好的桥梁使用功能概念与C#和VB.Net ......我觉得这是更痛苦的阅读相比,F#的时候
马修粉饰的

5

我认为原因是有些人认为一种语言是否被接受的最重要部分是该语言的质量。不幸的是,事情很少如此简单。例如,我认为背后Python的接受的最大因素不是语言本身(尽管这非常重要的)。Python如此受欢迎的最大原因是其庞大的标准库和更大的第三方库社区。

考虑到它们是基于JVM / CLR构建的,因此Clojure或F#之类的语言可能是该规则的例外。结果,我没有答案。


+1,但不要忘记营销的力量,而且您公司的大量旧代码不会因为一些很酷的新趋势而切换语言。
2009年

您忘了提及:Google正在普及python。
郝沃林2009年

4

大多数应用程序都可以通过[在此处插入您喜欢的语言,范例等]解决。

尽管这是事实,但是可以使用不同的工具来解决不同的问题。功能性仅允许另一个更高(更高?)级别的抽象,如果使用得当,它可以更有效地完成我们的工作。


4

在我看来,那些从未学习过Lisp或Scheme的人现在正在发现它。与该领域的许多事情一样,有一种大肆宣传和创造高期望的趋势。

会过去的。

函数式编程很棒。但是,它不会接管世界。C,C ++,Java,C#等仍然存在。

我认为这将带来更多的跨语言功能-例如以功能语言实现事物,然后以其他语言提供对该事物的访问权限。


1
C#现在是一种功能编程语言(与Lisp一样多),因为它具有一流的词法闭包。实际上,它们已经在WPF和TPL中使用。因此,函数式编程显然已经在这里。
乔恩·哈罗普


3

事情已经朝着功能性方向发展了一段时间。过去几年中,两个很酷的新手Ruby和Python都比以前的语言更接近于功能语言-如此之多,以至于有些Lispers已经开始“足够接近”地支持一种或另一种。

而且,由于大规模并行硬件给所有人带来了发展压力,而功能语言正处于应对变化的最佳位置,因此,以为Haskell或F#将是下一个大问题已经不是什么遥不可及的了。


3

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

  • 闭包,匿名函数,传递和返回函数作为值,这些值曾经是只有Lisp和ML黑客才知道的奇特功能。但是逐渐地,C#,Delphi,Python,Perl,Javascript添加了对闭包的支持。没有封闭就不可能认真对待任何新兴语言。

  • 几种语言(尤其是Python,C#和Ruby)对列表推导和列表生成器具有本机支持。

  • ML于1973年开创了泛型编程的先河,但是对泛型(“参数多态性”)的支持仅在最近5年左右才成为行业标准。如果我没记错的话,Fortran在2003年支持泛型,其次是Java 2004,C#在2005年,Delphi在2008年。(我知道C ++自1979年以来就支持模板,但是90%的C ++ STL讨论都始于“这里有妖魔”。 )

是什么使这些功能吸引程序员?它应该显而易见:它可以帮助程序员编写较短的代码。如果将来所有语言都想保持竞争力,它们将至少支持关闭。在这方面,函数式编程已经成为主流。

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

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




2

我同意第一点,但时代在变。即使公司采用了较晚的采用方法,但如果发现有优势的话,公司也会做出回应。生活是动态的。

他们在90年代后期在斯坦福大学教授Haskell和ML。我敢肯定,卡内基·梅隆大学,麻省理工学院,斯坦福大学和其他好学校等地方都在向学生们介绍它。

我同意大多数“在网络上公开关系数据库”应用程序将长期保持这种状态。Java EE,.NET,RoR和PHP已经为该问题开发了一些非常好的解决方案。

您遇到了一些重要问题:可能是其他无法通过增强功能编程的方法轻松解决的问题。那会是什么?

大型多核硬件和云计算会推动它们前进吗?


2

因为FP在生产率,可靠性和可维护性方面具有显着优势。多核可能是一个杀手级应用,尽管有大量的遗留代码,但最终还是让大公司进行了转换。此外,由于许多核的关注,甚至C#之类的大型商业语言也呈现出独特的功能风格-副作用很简单与并发和并行性不太匹配。

我不同意“普通”程序员不会理解它。就像他们最终了解OOP一样,他们将(对于OOP来说同样神秘又奇怪)。

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


抱歉,FP的时间是OOP的3倍左右。这根本不是需要更多时间的问题。要使FP成为主流,还需要做更多的工作。
杰森·贝克

您怎么会错过我的帖子中我解释的“更多内容”很可能是多核的部分?而“周围”的东西并不真正相关。人们了解OOP,因为当时OOP提供了切实的好处,FP才刚刚成为现实。
塞巴斯蒂安

2

哇-这是一个有趣的讨论。我对此的想法:

FP使某些任务相对简单(与非FP语言相比)。非FP语言已经开始从FP中汲取灵感,因此我怀疑这种趋势会持续下去,并且我们将看到更多的合并,这将有助于人们简化向FP的过渡。


2

我不知道它是否会流行,但是从我的调查来看,功能语言几乎肯定值得学习,它将使您成为更好的程序员。仅仅了解参照透明性,就可以使许多设计决策变得容易得多,并且由此产生的程序也更容易推论。基本上,如果遇到问题,那么它往往仅是单个函数的输出问题,而不是状态不一致的问题,这可能是由数百个类/方法/函数中的任何一个引起的以含蓄的语言出现副作用。

FP的无状态性质更自然地映射到Web的无状态性质,因此功能性语言更容易将其自身应用到更优雅的RESTFUL Web应用程序中。与JAVA和.NET框架形成对比,后者需要借助诸如VIEWSTATE和SESSION密钥之类的丑陋的HACK来维护应用程序状态,并在基本无状态的功能平台(如Web)上维护有状态命令性语言的(有时是非常泄漏的)抽象。

而且,您的应用程序越无状态,它越容易进行并行处理。如果您的网站正变得流行,那么这对网络来说非常重要。仅向站点添加更多硬件以获得更好的性能并不总是那么容易。


2

我的观点是,由于微软将其进一步推向了主流,它将立即流行起来。对我来说,它之所以具有吸引力是因为它可以为我们做些什么,因为这是一个新的挑战,并且因为它对未来充满了渴望。

一旦掌握,它将成为进一步帮助我们提高程序员生产力的另一种工具。


2

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

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


1

除了其他答案之外,以纯功能术语转换解决方案还可以使人们更好地理解问题。相反,以功能风格进行思考会发展出更好的*问题解决能力。

*要么是因为功能范例更好,要么是因为它将提供额外的攻角。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.