Questions tagged «functional-programming»

函数式编程是一种范式,它试图通过对函数的链式评估来解决计算问题,这些函数的输出由输入决定,而不是由程序状态决定。在这种编程方式中,不赞成使用副作用和可变数据,并且通常严格隔离它们。


2
将清洁代码原则应用于功能语言
我目前正在阅读Robert Martin的Clean Code。我认为这很棒,在编写OO代码时,我会牢记他的课程。特别是,我认为他的建议是使用带有有意义名称的小函数,这使我的代码流程更加流畅。最好通过以下引用来总结: [W] e希望能够像读取一组TO段落一样阅读该程序,每个段落都描述了当前的抽象级别,并在下一层向下引用了后续的TO段落。 (清洁代码,第37页:“ TO段落”是一个以不定式表达的句子开头的段落。“要做X,我们执行步骤Y和Z。”“要做Y,我们...”等。 ) 例如: 对于RenderPageWithSetupsAndTeardowns,我们检查该页面是否为测试页面,如果是,则包括设置和拆卸。无论哪种情况,我们都以HTML呈现页面 我也为我的工作编写功能代码。马丁在书中的例子确实读起来好像是一段段落,而且非常清楚-但我不确定“读起来像一组段落”是否适合功能代码使用。 以Haskell标准库为例: maximumBy :: (a -> a -> Ordering) -> [a] -> a maximumBy _ [] = error "List.maximumBy: empty list" maximumBy cmp xs = foldl1 maxBy xs where maxBy x y = case cmp x y of GT -> …

8
用于函数式编程的心理模型或真实世界隐喻
是否有人对函数式编程有一个很好的思维模型或隐喻,可以引用现实世界中的某些东西? 直观的面向对象编程对我来说很有意义。有些东西具有属性,有时它们也可以对它们的属性(方法)进行填充或执行计算。(例如:汽车,造型,猫)。 我对函数式编程毫无恶意,并且我对辩论两者的优点不感兴趣。与面向对象编程一样,我只需要一个隐喻或思维模型即可使用。 在功能范式中进行编程有哪些好的心理模型或现实世界隐喻?关于由功能处理功能组成的功能的某些说明,使一个功能没有固定的位置来站立和思考。

1
功能性中间形式的缺点
我正在为类似于JavaScript的语言编写优化器,并且需要选择一个中间代码表示形式。如今,显而易见的/典型的选择是静态单一分配(SSA)。 但是,C语言中的Modern Compiler Implementation也讨论了功能中间形式,这基本上意味着对中间表示使用纯功能(仅在局部变量方面是纯函数,堆数据仍然是可变的,而在CPS方面则是可变的,只是简单的let块和尾调用)。在易于推理方面具有一些优势。 大概这不是理所当然的,或者每个人都已经在使用这种表示形式了,所以我的问题是,功能性中间形式与SSA相比有哪些缺点?

2
代数数据类型的用途是什么?
我正在阅读有关代数数据类型的信息(感谢Richard Minerich,我对这个概念有了很好的解释)。虽然我认为我了解求和类型和乘积类型等的概念,但我不太了解的是代数数据类型在指定模式匹配之外如何有用。ADT的超出模式匹配功能还能做什么? 编辑:我不是在问开发人员可以用对象无法完成的ADT做些什么。我问是否还有ADT允许的其他操作;例如,如果使用ADT,可以对涉及的类型进行其他推理吗?如果没有它们,ADT是否可以促进某种类型的分析?

5
可以编译为Android Dalvik VM的功能语言吗?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我有一个适合功能编程方法的软件问题,但目标市场将是Android OS。我问是因为有些功能语言可以编译为Java的VM,但是Dalvik字节码!= Java字节码。 另外,您是否知道该dx实用程序是否可以智能地转换.class从Scala等功能语言生成的文件? 编辑:为了给社区增加更多帮助,并帮助我更好地选择,我可以对问题进行一些改进吗? 您是否在Dalvik中使用了任何其他语言?哪个? 我可能会遇到哪些“陷阱”(问题)? 性能可以接受吗?那样的话,我的意思是应用程序仍然对用户有所响应。 我从来没有做过手机开发,但是我在受限的设备上长大,并且我不幻想在该平台上使用非标准语言会产生成本。我只需要知道是否花了这么多钱,就可以将我的方法变成默认语言(即在OOP语言中应用功能原理)。

4
为什么不依赖于更改状态有什么好处?
这个问题出自问题/software/25569/is-haskell-worth-learning 通常,对于Haskell如何提高您在其他语言中的编码技能,通常会重复声明一些,此外,这是因为Haskell是无状态的,这是一件好事。 为什么? 我见过有人将其与只用左手打字,或者闭上眼睛一天,仅依靠触摸来进行比较。当然,还有更多呢? 它与硬件内存访问有关,还是与其他性能提升有关?

5
像Elm所说的那样,拥有“没有运行时异常”有什么好处?
某些语言声称具有“无运行时异常”,这是与具有它们的其他语言相比的明显优势。 我对此事感到困惑。 据我所知,运行时异常只是一种工具,使用得当: 您可以传达“脏”状态(抛出意外数据) 添加堆栈,您可以指向错误链 您可以区分混乱(例如,在无效输入上返回空值)和需要开发人员注意的不安全用法(例如,在无效输入上引发异常) 您可以通过异常消息为错误添加详细信息,从而提供进一步有用的详细信息,以帮助调试(理论上) 另一方面,我发现很难调试“吞噬”异常的软件。例如 try { myFailingCode(); } catch { // no logs, no crashes, just a dirty state } 因此,问题是:拥有“无运行时异常”的强大的理论优势是什么? 例 https://guide.elm-lang.org/ 实际上没有运行时错误。没有空值。没有未定义不是函数。

4
API和函数式编程
从我(有限地)接触函数式编程语言(例如Clojure)开始,似乎数据封装的作用不那么重要。通常,各种本机类型(例如地图或集合)是代表对象的首选数据。此外,该数据通常是不可变的。 例如,这是Clojure的成名人物里奇·希基(Rich Hickey)在接受此事采访时最著名的名言之一: Fogus:遵循了这个想法,Clojure并未对其类型进行数据隐藏封装,这一事实使某些人感到惊讶。您为什么决定放弃数据隐藏? Hickey:让我们清楚一点,Clojure强烈强调对抽象的编程。但是在某个时候,某人将需要访问数据。而且,如果您有“私有”的概念,则需要相应的特权和信任的概念。这就增加了很多复杂性和很小的价值,在系统中产生了僵化,并常常迫使事物生活在不应有的地方。这是将简单信息放入类时发生的其他损失的补充。在某种程度上,数据是不可变的,提供访问的危害很小,除了有人可能会依赖可能发生变化的事物之外。好吧,好吧,人们在现实生活中一直如此,当事情发生变化时,他们就会适应。如果他们是理性的,他们知道,当他们基于可能会改变的事物做出决定时,将来可能需要适应。因此,这是一项风险管理决策,我认为程序员应该可以自由做出。如果人们不希望对抽象编程,也不愿意与实现细节相结合,那么他们永远都不会成为优秀的程序员。 来自面向对象的世界,这似乎使我多年来学到的一些基本原则变得复杂。其中包括信息隐藏,德米特定律和统一访问原则等。封装的共同点是使我们能够为其他人定义API,让他们知道应该和不应该接触的内容。从本质上讲,创建一个合同,允许某些代码的维护者自由地进行更改和重构,而不必担心它将如何在用户代码中引入错误(开放/封闭原则)。它还为其他程序员提供了一个干净,精心设计的界面,以使他们知道可以使用哪些工具来获取或建立该数据。 当允许直接访问数据时,该API合同被破坏,所有这些封装好处似乎都消失了。同样,严格不变的数据似乎在遍历特定于域的结构(对象,结构,记录)时,在表示状态和可以对该状态执行的操作的意义上要有用得多。 当代码库的大小变得巨大而需要定义API且许多开发人员参与处理系统的特定部分时,功能代码库如何解决似乎出现的这些问题?是否存在这种情况的示例,以说明在这些类型的代码库中如何处理此情况?

9
说服高层管理人员考虑使用函数式编程,有什么好的事实依据?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 对于为什么函数式编程是一个好主意,有大量的“理论”论证(要解决一个开放的问题,太多了,这是正确的)。 但是,大多数都是基于理论(“优雅”等)或针对开发人员的论证。 问题是,当他们的目标是向大公司的高级管理层介绍这个想法时,大多数人完全没有用,其中一些人甚至都不是开发人员,而所有人都在乎业务论点:成本,人力资本管理,产品交付,客户服务和收入;以及理论上无法完全支持的定量事实。 就考虑将功能性编程作为一种概念(不是任何特定的语言)进行考虑,相对于过程/ OOP的典型组合,例如Java / C ++ /(Perl | Python),是否有任何令人信服的论点可以解决这些业务问题?。 最好是,我正在寻找定量的和/或基于研究或案例研究的论据。例如,“根据此参考,Lisp / F#中的多线程系统的错误率是Java的10%”或“ 80%的顶尖毕业生表示对期望的技术(称为函数式编程)的偏爱是前三大兴趣之一”。 我知道Graham提出了函数式编程的用例以备不时之需,并假设他的某些论点对较大的成熟公司有效,对此他持开放态度。 psI完全意识到,您可以在Perl中完成类似于函数式编程的工作,可能是Python,甚至(甚至)Java 8或C ++14。但是,这并不意味着使用Perl,C ++或Java的组织会认可函数vs即使是那些语言中的OOP /过程方法 就此语言而言,“大”定义为足以拥有专门的开发工程/工具组的大小,该组指示允许所有开发人员使用/执行的操作;至少有数百名低端开发者。

3
高阶函数的命名约定?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 高阶函数有命名约定吗?即,返回其他功能的功能。 Javascript中的示例: function onlyDivisibleBy(div) { // <-- higher order function return function (n) { return n % div === 0; } } var arr = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]; arr.filter(onlyDivisibleBy(3)); // [0, 3, 6, 9] arr.filter(onlyDivisibleBy(5)); // [0, 5] 我倾向于按照上面的方式编写它:也就是说,在调用点进行了易读性优化(我读了上面的最后几行,即“过滤数组以使项只能被5整除”),但是在定义点从使用它的上下文来看,从其名称了解该函数的作用并不容易。

2
没有作为过程实现的延续的例子是什么?
关于SO上的回调和延续之间的区别的有趣讨论引发了这个问题。根据定义,延续是完成计算所需逻辑的抽象表示。在大多数语言中,这表现为一个自变量过程,您可以将需要继续处理的任何值传递给该过程。 用纯函数式语言(其中所有函数都是纯函数并且是头等公民),我认为延续可以完全建模为函数。毕竟,这就是我以前对到目前为止的理解。但是,世界充满了状态(叹息),因此一般定义不需要连续捕获程序状态-它只需要包含意图。 为了帮助我理解,是否可以用功能语言提供一个示例,其中以比功能更抽象的方式表示延续?我知道Scheme可以让您以一流的方式(call / cc)来获取当前的延续,但是即使如此,似乎传递给call / cc的一个参数过程只是以另一种形式给出了当前的延续调用/ cc函数可以将其结果应用到的自变量过程。


5
接口的功能编程替代方案是什么?
如果我想以“功能性”风格进行编程,我将用什么替换接口? interface IFace { string Name { get; set; } int Id { get; } } class Foo : IFace { ... } 也许一个Tuple<>? Tuple<Func<string> /*get_Name*/, Action<String> /*set_Name*/, Func<int> /*get_Id*/> Foo; 首先使用接口的唯一原因是,我总是希望某些属性/方法可用。 编辑:有关我在想什么/尝试的更多详细信息。 说,我有一个方法,它具有三个功能: static class Blarf { public static void DoSomething(Func<string> getName, Action<string> setName, Func<int> getId); } 对于BarI 的实例,可以使用此方法: …

4
groovy是否将部分应用程序称为“ currying”?
Groovy有一个称为“ currying”的概念。这是他们的Wiki中的一个示例: def divide = { a, b -> a / b } def halver = divide.rcurry(2) assert halver(8) == 4 我对这里发生的事情的理解是,右边的参数divide绑定到了值2。这似乎是部分应用的一种形式。 术语currying通常用于将包含一系列参数的函数转换为仅包含一个参数并返回另一个函数的函数。例如,以下是curryHaskell 中的函数类型: curry :: ((a, b) -> c) -> (a -> (b -> c)) 对于谁没有用过Haskell的人a,b并且c都是通用的参数。 curry接受一个带有两个参数的函数,然后返回一个函数,该函数接受a并返回一个b到的函数c。我为该类型添加了额外的一对括号,以使其更加清楚。 我是否误解了groovy示例中发生的事情,还是只是误命名了部分应用程序?或实际上是两者兼而有之:也就是说,将其转换divide为咖喱函数,然后部分地应用于2此新函数。

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.