Questions tagged «functional-programming»

我正在编写一个程序来模拟网格中蚂蚁的活动（PDF）。蚂蚁可以四处走动，捡东西和丢东西。 问题是，虽然可以通过类属性轻松地跟踪蚂蚁的动作和每个蚂蚁的位置（并且我们可以轻松地创建此类蚂蚁的许多实例），但我的客户说，由于他具有函数式编程的背景，因此他希望使用功能编程进行仿真。 需要明确的是，来自客户端的原始词语仅是“ no class”，而不是“ function programming”。因此，我认为他并不意味着函数式编程，我势在必行。另外，我没有函数编程的经验。 但是，我认为专注于这个问题，特别是关于功能性编程要求，而不只是简单地“必须执行”，这是有益的。 您将如何处理这种情况？您是否会说服客户使用面向对象的编程更清洁，尝试遵循他的要求并为他提供劣质的代码，或者做其他事情？

31 object-oriented  functional-programming  client-relations 

我主要是C / C ++程序员，这意味着我的大部分经验都涉及过程和面向对象的范例。但是，正如许多C ++程序员所知道的那样，多年来，C ++的重点已转移到具有功能的风格，最终在C ++ 0x中增加了lambda和闭包。 无论如何，尽管我在使用C ++ 进行功能样式编码方面有丰富的经验，但是我对诸如Lisp，Haskell等实际功能语言的经验却很少。 我最近开始研究这些语言，因为纯功能语言中的“无副作用”的想法一直吸引着我，特别是在将其应用于并发和分布式计算方面。 但是，出于C ++的背景，我对于这种“无副作用”的哲学与异步编程的工作方式感到困惑。异步编程是指可以分发用户提供的事件处理程序以处理异步发生的事件（程序流之外）的任何框架/ API /编码样式。这包括异步库，例如Boost.ASIO，甚至只是普通的C语言。信号处理程序或Java GUI事件处理程序。 所有这些共同点是，异步编程的性质似乎需要创建副作用（状态），以使程序的主要流程意识到已调用了异步事件处理程序。通常，在Boost.ASIO之类的框架中，事件处理程序会更改对象的状态，从而使事件的影响传播到事件处理程序功能的生存期之外。真的，事件处理程序还能做什么？它不能“返回”值到调用点，因为没有调用点。事件处理程序不是程序主流程的一部分，因此它对实际程序有任何影响的唯一方法是更改​​某些状态（或更改longjmp为另一个执行点）。 因此，似乎异步编程是关于异步产生副作用的。这似乎与函数式编程的目标完全矛盾。这两种范例在功能语言中如何进行协调（实际上）？

31 async  functional-programming  side-effect 

在多年的OO编程中，我了解了区别工会是什么，但我从未真正错过过他们。我最近一直在用C＃进行一些函数式编程，现在我一直希望自己拥有它们。这让我感到困惑，因为从表面上看，区别工会的概念似乎与功能/ OO二分法完全无关。 函数式编程中是否有固有的功能，使有区别的联合比在OO中更有用，或者是通过强迫自己以“更好”的方式分析问题，我只是提高了标准，现在要求更好模型？

30 functional-programming 

我想知道是否可以在Spring + Hibernate项目中从Java切换到Scala，以利用一些Scala功能，例如模式匹配，Option以及对我来说似乎更简洁的语法。我一直在Scala生态系统中寻找默认的ORM，并且发现了类似Activate的想法（但大多数情况下，我尝试查找Hibernate是否可以与Scala一起使用）。搜索此内容，我已经在有关JPA + Scala 的Play文档中阅读了此内容。 但是最重​​要的一点是：如果您拥有功能语言的强大功能，您是否真的需要一个“关系到对象”映射器？ 可能不会。JPA是一种抽象的Java数据转换能力不足的便捷方法，但是当您从Scala开始使用它时，确实感觉不对。 我对如何使用函数式编程来创建完整的应用程序没有深入的了解（这就是为什么我打算使用Scala以便使我能够逐步理解这一点，因为它结合了OO + Functional），所以我不知道为什么我不需要功能语言的ORM，以及解决领域模型持久性的功能方法是什么？ 对于Scala，用于业务逻辑的DDD方法仍然有意义，不是吗？

30 scala  functional-programming 

上面的问题是我在遗留代码中遇到的一个常见问题的抽象示例，或更准确地说，是以前解决该问题的尝试所导致的问题。 我可以想到至少一种旨在解决此问题的.NET框架方法，例如该Enumerable.OfType<T>方法。但是，您最终最终在运行时询问对象的类型这一事实与我不对。 除了问每匹马：“你是独角兽吗？” 还想到以下方法： 尝试获取非独角兽角的长度时引发异常（暴露了不适用于每匹马的功能） 返回一个非独角兽号角长度的默认值或魔术值（需要在所有想要对一组全都是非独角兽的马进行角统计的代码中添加默认检查） 消除继承，并在马上创建一个单独的对象，该对象告诉您马是否为独角兽（这可能会将同一问题推下一层） 我觉得最好用“不回答”来回答。但是，您如何解决这个问题？如果取决于这个问题，您的决定的背景是什么？ 对于这个问题是否仍然存在于功能代码中（或者也许仅存在于支持可变性的功能语言中），我也会感兴趣。 这被标记为以下问题的可能重复： 如何避免向下转换？ 该问题的答案假设一个人拥有一个HornMeasurer，必须进行所有的号角测量。但这是对基于平等原则而形成的代码库的强加，即每个人都应该可以自由地测量马的角。 缺少a时HornMeasurer，可接受的答案的方法反映了上面列出的基于异常的方法。 关于马和独角兽都是马，还是独角兽是马的神奇亚种，评论中也有些困惑。两种可能性都应该考虑-也许一个比另一个更可取吗？

30 design  object-oriented  functional-programming 

表达式的惰性求值似乎会使程序员失去对代码执行顺序的控制。我很难理解为什么程序员会接受或期望这样做。 当我们无法保证将在何时何地评估表达式时，该范式如何用于构建可预期运行的可预测软件？

30 functional-programming  haskell 

在第二版的839页上，史蒂夫·麦康奈尔（Steve McConnell）讨论了程序员在大型程序中“克服复杂性”的所有方式。他的提示最终体现在： “面向对象的编程提供了同时适用于算法和数据的抽象级别，这是仅功能分解无法提供的那种抽象。” 加上他的结论“降低复杂度可以说是成为有效程序员的最重要的关键”（同一页），这似乎对函数式编程构成了很大的挑战。 FP和OO之间的辩论通常由FP支持者围绕复杂性问题进行，这些复杂性问题特别来自于并发或并行化的挑战。但是并发当然不是程序员必须克服的唯一复杂性。也许专注于减少一种复杂性会在其他方面大大增加它的复杂度，以至于在许多情况下，增加收益是不值得的。 如果我们将FP和OO之间的比较术语从并发性或可重用性等特定问题转移到全局复杂性的管理上，那场辩论会如何？ 编辑 我想强调的对比是，OO似乎封装和抽象了数据和算法的复杂性，而函数式编程似乎鼓励在整个程序中使数据结构的实现细节更加“暴露”。 例如，参见Stuart Halloway（Clojure FP的支持者）在这里说，“数据类型的过度规范”是“惯用的OO风格的负面结果”，并主张将AddressBook概念化为简单的矢量或映射而不是更丰富的OO对象。以及其他（非向量化和非地图类）属性和方法。（此外，OO和领域驱动设计的支持者可能会说，将地址簿公开为向量或映射会使封装的数据过度暴露于从域的角度来看无关紧要甚至危险的方法）。

30 object-oriented  functional-programming  object-oriented-design 

我正在尝试使用一种功能语言来开始一个实验项目，并试图在Erlang和Haskell之间做出选择，而这两点我都非常喜欢。 我喜欢Haskell强大的字体系统和纯正的风格。我有一种感觉，它将使编写真正可靠的代码变得更加容易。而且我认为Haskell的强大功能将使我想做的事情变得容易得多。 不利的一面是，我觉得在Haskell上做Web东西的某些框架（例如Yesod）不如其Erlang计数器部分那么先进。 我更喜欢Erlang的线程和容错方法。我觉得Erlang的可伸缩性可能是一个主要优点。 这就引出了我的问题，人们在Haskell和Erlang中实现Web应用程序后端有什么经验。Haskell是否有软件包提供Erlang中一些轻量级线程和actor？

30 functional-programming  haskell  erlang 

UNIX编程环境（经典文本）指出，UNIX编程方法是构建小型的，定义明确的工具，可以将其组合起来以解决更复杂的问题。在学习C和Bash shell时，我发现这是一个功能强大的概念，可用于处理各种编程问题。 仅使用Linux平台，这个概念就很清楚并且一直使用。在命令行上形成的用于重定向I / O，链接系统工具（如ls，grep等）的任何表达式都表明了此概念的强大之处。 让我感到困惑的是，其中许多程序都是使用命令性/过程式编程风格以C语言编写的，但是在命令行上使用它们并将它们结合在一起的方式对我来说更像是函数式编程，其中每个程序都是一个独立的函数，不依赖于它可能加入的任何其他程序的状态。 理解UNIX编程原理是否准确，基本上就是使用可能是用命令式编程风格构建的工具进行的函数式编程吗？

30 unix  functional-programming  paradigms  philosophy 

在学习Haskell的过程中，我遇到了很多教程，试图解释什么是monad，以及为什么monad在Haskell中很重要。他们每个人都使用类比，因此更容易理解其含义。归根结底，我对单子是3种不同的看法： 查看1：将Monad作为标签 有时我认为将monad作为特定类型的标签。例如，一个类型的函数： myfunction :: IO Int myfunction是一个函数，无论何时执行它都会产生一个Int值。结果的类型不是Int，而是IO Int。因此，IO是Int值的标签，警告用户知道Int值是执行IO操作的过程的结果。 因此，此Int值已被标记为来自具有IO的过程的值，因此该值为“脏”。您的过程不再是纯粹的。 视图2：莫纳德（Monad）是可能发生令人讨厌的事情的私人空间。 在所有过程都是纯且严格的系统中，有时您需要产生副作用。因此，monad只是一个很小的空间，允许您做讨厌的副作用。在这个空间中，您可以逃脱纯净的世界，走不纯净的事物，进行过程，然后返回有价值的东西。 图3：Monad的范畴论 我不完全理解这种观点。monad只是同一类别或子类别的函子。例如，您具有Int值，并且作为IO Int子类，它们是在IO过程之后生成的Int值。 这些观点正确吗？哪个更准确？

29 functional-programming  haskell  monad  side-effect 

在F＃中，必须使用rec关键字。在Haskell中，无需显式判断给定函数是否是递归的。 考虑到递归在函数式编程中的作用，F＃设计对我来说似乎很奇怪。这是一个好的语言设计决策，还是仅出于历史原因或由于实施限制而存在？

28 functional-programming  language-design  f# 

在Haskell中我从未完全了解过的一件事是如何拥有多态常量和函数，这些常量和函数的返回类型不能由其输入类型确定，例如 class Foo a where foo::Int -> a 我不喜欢这样的一些原因： 参照透明度： “在Haskell中，给定相同的输入，一个函数将始终返回相同的输出”，但这是真的吗？read "3"在Int上下文中使用时返回3 ，但在上下文中使用时抛出错误(Int,Int)。是的，您可以说这read也是一个类型参数，但是我认为类型参数的隐式性使其失去了某些美感。 单态限制： 关于Haskell的最烦人的事情之一。如果我错了，请纠正我，但是MR的全部原因是看起来共享的计算可能不是因为type参数是隐式的。 输入默认值： 再次是Haskell上最烦人的事情之一。例如，如果您在输出中将函数多态的结果传递给输入中的函数多态，则会发生这种情况。同样，如果我错了，请纠正我，但是如果没有函数的返回类型不能由其输入类型（和多态常量）确定的函数，则不需要这样做。 因此，我的问题是（冒着被盖章为“讨论问题”的风险）：是否有可能在类型检查器不允许这些定义的情况下创建类似于Haskell的语言？如果是这样，该限制的利弊是什么？ 我可以看到一些直接的问题： 例如，如果2仅具有type Integer，2/3则将不再使用当前定义进行类型检查/。但是在这种情况下，我认为具有功能依赖性的类型类可以解决（是的，我知道这是一个扩展）。此外，我认为拥有可以采用不同输入类型的函数比拥有受其输入类型限制的函数要直观得多，但是我们只是将多态值传递给它们。 值的打字喜欢[]和Nothing我看来，像一个难啃的骨头。我还没有想到处理它们的好方法。

28 haskell  functional-programming 

作为Java / C＃/ C ++程序员，我听到了很多关于函数式语言的讨论，但从未发现有必要学习一种。我还听说过，功能语言中引入的更高层次的思维使您成为更好的OOP /过程语言程序员。 有人可以确认吗？它以什么方式提高了您的编程技能？ 为了提高不那么复杂的语言的技能，学习语言的最佳选择是什么？

28 object-oriented  functional-programming 

以下代码示例为我的问题提供了上下文。 用委托初始化Room类。在Room类的第一个实现中，没有防范引发异常的委托的措施。此类异常将上升到North属性，在该North属性上评估委托（请注意：Main（）方法演示了如何在客户端代码中使用Room实例）： public sealed class Room { private readonly Func<Room> north; public Room(Func<Room> north) { this.north = north; } public Room North { get { return this.north(); } } public static void Main(string[] args) { Func<Room> evilDelegate = () => { throw new Exception(); }; var kitchen = new Room(north: …

27 c#  functional-programming  pure-function 

我第一次读过一篇经典的文章，名为《关于将系统分解为模块的标准》。这对我来说很有意义，并且可能是OOP所基于的那些文章之一。结论： 我们试图通过这些示例来证明，根据流程图将系统分解为模块几乎总是不正确的。...然后每个模块都被设计为对其他模块隐藏这样的决定 以我未受过教育和缺乏经验的观点，函数式编程与本文完全相反。我的理解是函数式编程使数据流变得惯用了。数据从一个函数传递到另一个函数，每个函数都密切了解数据并在此过程中“更改”它。而且我想我已经看过Rich Hickey的演讲，他在演讲中谈到数据隐藏是如何被高估或不必要的，但我不确定。 首先，我想知道我的评估是否正确。FP范式和本文在哲学上是否不一致？ 假设他们不同意，FP如何“弥补”缺乏数据隐藏的能力？也许他们牺牲了数据隐藏，但获得了X，Y和Z。我想知道为什么X，Y和Z比数据隐藏更有益的原因。 或者，假设他们不同意，也许FP认为数据隐藏很糟糕。如果是这样，为什么会认为数据隐藏不好？ 假设他们同意，我想知道什么是FP数据隐藏实现。很明显在OOP中看到了这一点。您可以拥有一个private班级以外的人无法访问的字段。在FP中，没有明显的比喻。 我觉得还有其他问题要问，但我不知道我要问。也可以随意回答。 更新资料 我发现尼尔·福特（Neal Ford）的演讲中有一个非常相关的幻灯片。我将屏幕截图嵌入此处：

27 design  object-oriented  functional-programming  object-oriented-design