我在这里看到了很多有关函数式语言和东西的讨论。我们为什么要在"传统"语言中使用一种语言？他们有什么更好的选择？他们最糟糕的是什么？什么是理想的函数式编程应用程序？

解决方案

回答

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

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

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

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

回答

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

函数式编程的最大优点之一是，无副作用函数的执行顺序并不重要。例如，在Erlang中，它用于以非常透明的方式启用并发。

而且由于函数语言中的函数的行为与数学函数非常相似，因此很容易将其转换为函数语言。在某些情况下，这可以使代码更具可读性。

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

回答

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

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

回答

*或者是因为功能范例更好，或者是因为它将提供额外的攻角。

回答

查看为什么函数式编程很重要

回答

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

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

回答

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

在阅读了Hackers and Painters之后，我实际上正在学习LISP，并且我确实相信我将从LISP中学习到一些东西，这些东西可以使我更好地理解我编写的所有其他内容。现在，我不认为我会每天真正使用LISP，因为1995年某个人创建了一个网站，成为Yahoo Stores。因此无论如何都是双赢的(如果成功了，如果没有成功，我将对如何编程以及如何工作有更多的看法)

回答

现在...关于另一个相关问题，我认为明年32个核心proc的到来，编程会发生很大变化吗？是的，我不知道这是否将是函数式编程，但是...我很确定会有所不同！

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

他们在90年代后期在斯坦福大学教授Haskell和ML。我敢肯定，卡内基·梅隆大学，麻省理工学院，斯坦福大学和其他一些好的学校都在向学生们展示它。

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

我们碰到了一些重要的事情：这可能是无法通过其他增强函数式编程的方法轻松解决的问题。那会是什么？

回答

Most applications are simple enough to be solved in normal OO ways

• OO方法并非总是"正常"的。这十年的标准是过去十年的边缘化概念。
• 函数式编程是数学。 Paul Graham谈Lisp(用Lisp替代功能编程)：

So the short explanation of why this
  1950s language is not obsolete is that
  it was not technology but math, and
  math doesn’t get stale. The right
  thing to compare Lisp to is not 1950s
  hardware, but, say, the Quicksort
  algorithm, which was discovered in
  1960 and is still the fastest
  general-purpose sort.

回答

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

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

我说没有理由不学习它。

回答

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

大多数应用程序都可以用[在这里插入我们喜欢的语言，范例等]解决。

回答

It's not really taught at universities (or is it nowadays?)

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

Most applications are simple enough to be solved in normal OO ways

我现在不知道，但是在1990年代中期，我在CS课程中同时接受了Miranda和Lisp的教育。尽管此后未使用纯函数式语言，但它影响了我解决问题的方式。

在90年代中期的同一门CS课程中，面向对象程序设计(使用Eiffel授课)几乎与功能编程相提并论。当时两者都不是主流。 OO可能现在是"正常的"，但事实并非如此。

回答

我很想知道Fis是否将FP推向了主流。

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

回答

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

Fco可能会流行，因为微软正在推动它。

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

优点：

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

相反：

回答

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

因为FP在生产率，可靠性和可维护性方面具有显着优势。多核可能是一个杀手级应用，尽管有大量的遗留代码，最终还是让大公司转换了。此外，甚至像Care之类的大型商业语言，由于多核问题的副作用，也具有独特的功能风格，根本不会不适合并发和并行。

我不同意"普通"程序员不会理解它。就像他们最终了解OOP一样，他们将(这同样是神秘和怪异的，如果不是更多的话)。

回答

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

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

It's not really taught at universities
  (or is it nowadays?)

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

Most applications are simple enough to
  be solved in normal OO ways

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

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

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

回答

不过，绝对值得一提的是，最近，Chas向FP迈出了重大步伐，在某种程度上，它实际上使一代程序员变成了FP程序员，甚至没有引起他们的注意。这可能只是为FP"革命"铺平了道路。可能是。 ;)

回答

函数式编程已经受到IMHO的追捧，但还不是很明显。这种语言的优势在于数学/算法，这就是Halo Guys将其用于TrueSkill的原因之一。

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

会过去的。

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

回答

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

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

回答

而且，由于大规模并行硬件在应对变化的最佳位置上对所有人和功能语言施加了不断发展的压力，因此与以往认为Haskell或者Fwill是下一个大问题相比，这已经不是什么飞跃了。

• 闭包，匿名函数，传递和返回函数作为值，这些值曾经是只有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讨论都始于"这里有魔鬼" )

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

Most applications are simple enough to
  be solved in normal OO ways

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

回答

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

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

但是，如今，强制执行功能样式的语言越来越多地受到人们的追捧，这些语言在未来是否会占主导地位是一个悬而未决的问题。我自己的怀疑是诸如Scala或者OCaml之类的混合，多范式语言
就像纯OO语言(Smalltalk，Beta等)已经影响了主流编程，但它并没有成为最广泛使用的表示法一样，它们可能会在"纯粹的"功能语言中占据主导地位。

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

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

回答

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

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

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

回答

它使你变得更好。

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

回答

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

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

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

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

回答

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

回答

它已经在Hadoop中的Map / reduce上流行起来

我认为函数式编程语言成为"下一件大事"的最大论据是，未来多核处理器将成为规范。程序员必须利用这一点，而函数式编程确实为构建顶级并发软件提供了绝佳的可能性。

回答

P.S.当我在波士顿大学上大学时('98 -'02)，我们花了一个学期的学习计划，这是LISP的近亲。当我们刚开始学习它时，我想把头发扯下来。在课程结束时，这是非常自然的。

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

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

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

回答

干杯，
聚苯乙烯

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

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

回答

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

• Excel公式
• 石英作曲家
• Java脚本
• 徽标(海龟图形)
• LINQ
• 的SQL
• Underscore.js(或者Lodash)，D3

回答

我敢打赌，我们在使用时不知道自己是函数式编程：

我认为，问题的答案更多地在于"最合适的工具"这一说法，而不是最热门的说法。总是会有炙手可热的新技术，而且总会有人跳起来。

回答

功能语言已经存在了一段时间，只是现在它们受到了越来越多的关注。

回答

它之所以流行，是因为它是控制复杂性的最佳工具。
看：
西蒙·佩顿·琼斯的幻灯片109-116讲"哈斯克尔的味道"
蒂姆·斯威尼(Tim Sweeney)的"下一代主流编程语言：游戏开发者的观点"

嗯，很抱歉成为一名学徒，但是它已经流行起来了，我们称之为Excel。

http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/

在计算机上运行的绝大多数程序都是用Excel或者它的许多流行克隆之一编写的。

回答

(有很多程序可以运行很多次，并且用Excel编写的程序往往不是大多数Excel程序都具有1个运行实例的程序)

回答

• 一般的公司程序员花了OOP多长时间...？
• 我在1994年曾在乌得勒支大学(Utrecht University)教过函数式编程，但直到最近几年才开始在"现实世界"中流行起来。
• 没有所谓的"简单应用程序"。 ;-)

FP是可以肯定的下一个最佳范例。现在下一步可能是哪种语言，这很困难，但我相信可能是Haskell，F＃，Clojure，Ocaml或者Erlang。或者是具有更多FP构造并更好地支持并行性/性能的Python，或者具有鹦鹉的Perl 6看起来非常有趣。

回答

我认为，当我们开始在硬件中获得越来越多的内核时，对软件某些关键部分进行(逼近)无副作用编程将至关重要。给功能编程更多的时间。在当前和将来的C版本中，大量的功能投入将大大帮助那些企业程序员甚至在没有意识到的情况下进行函数式编程。

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

回答

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

• 自Lisp与Fortran以来，FP与命令式编程(OO，结构化等)之间的争论一直很激烈。我认为我们提出了很好的问题，但是意识到它们并不是特别新。
• FP上的hoopla的部分原因是，我们似乎认识到并发非常困难，并且OO中的锁和其他机制(例如Java)只是一种解决方案。 FP通过Actor和无状态计算的功能等思想提供了令人耳目一新的巨变。对于那些与OO进行角力的人来说，这种情况似乎很有吸引力。
• 是的，学校教FP。实际上，滑铁卢大学和其他大学在第一年的课程中提供了该计划(请参阅此处)。
• 关于普通程序员，我敢肯定，在1990年代初，针对C ++的观点也相同。看看发生了什么。如果企业可以通过技术获得优势，那么我们可以打赌人们将接受培训。

一些想法：

回答

这并不是说这是肯定的事情，也不是说3-5年内不会出现反弹(总是如此)。但是，FP的趋势是值得的，值得观察。

在阅读Epic Games的Tim Sweeney撰写的"下一代主流编程语言：游戏开发者的观点"时，我的第一个念头是我必须学习Haskell。

PPT

回答

Google的HTML版本

• 单元测试
• 调试
• 并发
• 热门代码部署
• 机器辅助证明和优化

Slava Akhmechet上有一篇很棒的文章叫做《我们其余的人的功能编程》(这是使我成为FPbtw的文章)。在FP带来的好处中，他非常规地强调了以下内容(我认为这有助于吸引软件工程师)：

然后继续讨论更传统讨论的FP方面的好处，例如高阶函数，递归，惰性求值，优化，抽象控制结构(尽管不讨论monad)，无限数据结构，严格性，连续性，模式匹配，闭包和很快。

回答

强烈推荐 ！

很多人提到功能语言。

但是，除了Javascript外，今天还使用了一些最常用的功能语言。

Excel，SQL，XSLT，XQuery，J和K用于财务领域。

当然是Erlang。

回答

因此，我要说的是，每天都要在主流中使用函数式编程技术。

函数式编程可能是工程师，科学家用来解决他们所面临的问题的工具。它不会像以前的语言那样带动世界。但是，要击败的最难的产品是Excel，如果我是一名工程师并且需要进行计算，则Excel很棒。

但是，Fis将成为另一个来源，并且很可能会满足非计算机科学家的设计需求。面对现实，计算机科学家在创造一种全新的全新工作方式方面做得非常出色。面向对象的编程很棒。但是有时我们只需要一种方法来求解方程式，即可得到一个解并对其进行图形化。而已。然后使用"填写帐单"之类的语言。或者，也许我们想构建一个有限状态机，Fagain可能是解决方案之一，但是C也可能是解决方案。

回答

但是，当涉及到并行处理时，Excel会大放异彩，而Fwill也会及时出现。但是以友好的方式，F＃=友好的。

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

回答

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

回答

微软实际上是在Visual Studio上推动Fwith的下一个版本。它是一种混合语言，例如Scala，并且与.net框架的其余部分很好地集成在一起。我认为许多Microsoft商店都将使用它来加快高度并行数据处理应用程序和功能的开发。

• 编写一个接受数据，对其进行处理并返回数据的函数
• 写一个死的简单包装器，该包装器调用数据库，然后返回通过我的函数传递数据的结果

我很难想象纯功能性语言是当今的通用语言，我之所以不愿意使用它(是因为它们是草料)的原因。话虽这么说，无论语言如何(如果允许)，以功能方式进行编程都可以带来好处。对我来说，它可以更轻松地测试我的代码。我经常使用数据库...我倾向于：

这样做使我可以为我的操纵函数编写单元测试，而无需创建模拟等。

回答

我确实认为纯函数式语言非常有趣……我只是认为对我们而言重要的是我们可以从它们中学到的东西，而不是我们可以用它们来做的事情。

* 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

我要指出的是，关于功能语言的所有内容，大约20年前，大多数人都在谈论面向对象的语言。那时，听说OO非常普遍：

回答

变化必须来自某个地方。无论接受过早期技术培训的人员是否认为不必要进行更改，有意义且重要的更改都将实现。尽管当时所有反对它的人都认为面向对象的更改是件好事吗？

回答

我个人认为对于分布式系统和多线程/并行编程，功能性编程将很快获得突破。只要它通过编程库与现有的OOP范例集成即可。所以...我认为纯功能性方法仍将是学术性的。

自LISP是最早使用编译器的语言之一以来，以及自MIT的LISP机器以来，函数式编程已经存在了很长时间。这不是一个新的范例(OO更新)，但是主流软件平台倾向于使用易于转换为汇编语言的语言编写，并且它们的API极大地支持命令式代码(带有C的UNIX，带有C的Windows和带有Pascal的Macintosh)然后C)。

回答

我认为最近几年的新创新是要迎接各种API，特别是对于平台API无关的Web开发之类的事情。由于我们没有直接使用Win32 API或者POSIX API进行编码，因此人们可以自由地试用功能语言。

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

谁没有通过观看他人的活动而对自己有所了解？要学习剑，请学习吉他。学习拳头学习商业。仅学习剑将使我们头脑狭窄，并且不会让我们向外生长。

回答

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

我认为功能语言不会解决任何问题，这只是管理层试图推销的炒作，请记住唯一的事实：

没有银弹。

段落数量不匹配