.net - F# 与 IronPython : When is one preferred to the other?

Question

虽然 F# 和 IronPython 语言在技术上不同，但在我看来，它们的潜在用途之间存在很大的重叠。什么时候一种比另一种更适用？

到目前为止，在我看来，F# 在计算上更高效，而 IronPython 从 Python 继承了一个更好的库。我很高兴得到纠正。

有一个有点相关的问题 is F# to IronPython/IronRuby as C# is to VB.NET?但是那里的大多数答案都与语言范式有关，而不是它们的实际适用性。

编辑 : 我想我应该添加更多背景。总的来说，我对 Python 有很好的经验，并且在之前的几个犹豫不决的函数式编程步骤之后刚刚学习了 F#，主要是在 Erlang 中。我目前觉得将来可以继续使用 Python 或 F#。我想决定我应该使用哪一个以及在哪里。例如:

作为标准库的一部分，Python 具有非常好的数据结构。前几天我需要一个相当于 Python 的 heap模块，它在标准 F#/.net 库中不可用。指向 IronPython。

F# 可用于构建更方便的库，更易于从其他 .Net 语言访问。因此，对于 .Net 驻留库，我更喜欢 F#。

跨平台开发。 IronPython 在这里更好。 F#/Mono 可用的平台要小得多，而且 F#/OCaml 兼容性不容易维护，尤其是在库方面。

IronPython 交互式 shell 在我看来比 fsi 更容易。天啊。

所以问题归结为:除了对一种范式的偏爱或某些团队或公司的偏爱之外，是否有任何原因会让您选择 F# 而不是 IronPython，反之亦然？假设你对两者都同样有信心？或者它们在所有实际用途上都完全相同吗？

编辑 :好的，伙计们，看起来您认为这是一个愚蠢的问题，对它和答案投了反对票。但至少它是诚实的。所以请只是一个提示。是否无法区分两者，或者我问这个问题是否进入了一些 secret 禁忌？如果它看起来像巨魔，有人可以告诉我吗？

Answer 1

So the question boils down to: are there any reasons, apart from a preference of one paradigm to another or some team or corporate preferences, that would make you pick F# rather than IronPython or vice versa? Assuming you are equally confident in both? Or are they exactly equivalent for all practical purposes?

通常情况下，“这取决于你在做什么”但是既然你问了，就从这里开始:

工具集多样性

在我看来，IronPython 本质上与 C# 相同，但语法略有不同——我知道，它是对具有完全不同类型系统的两种语言的全面概括，但对于另一种命令式，我无话可说，OO语言。无论是 C#、Java、C++ 还是 Python，您都使用大致相同的技术、习惯用法、策略、风格等来解决语言问题。如果您是 .NET 开发人员，那么您几乎肯定使用过 C# 或 VB。 NET，并且只要您一直在使用这些语言，您就已经在以命令式风格编写代码。

支持 F# 的最大的一点就是它鼓励更多的函数式编程风格，通过 OO 继承淡化抽象，支持函数组合，将不变性作为默认值而不是事后的想法，等等。如果要编写函数式代码，则需要使用函数式语言。

当然，您可以用 C# 和 Python 编写函数式风格，但函数式特性是事后才嫁接的。 Python 缺少多行 lambda，C# 过于冗长，偶尔 buggy为了在你想用的地方使用函数式风格，C#特别有一个完整的 boatload of gotchas关于委托(delegate)和捕获局部变量，这两种语言几乎在您想要使用它们的任何地方都缺乏尾调用优化，与 F# 相比，C# 的类型推断是一个笑话。我试过使用 C# 作为一种函数式语言，但结果非常糟糕:)

现在大多数人可能会承认问题使使用 C# 或 Python 以函数式风格编程变得困难，但并非不可能。但是，根据我的经验，不是语言使之成为不可能，而是您团队中的程序员。如果您有 10 或 12 个人用命令式语言编写代码，那么您将无法长期强制执行函数式风格——这些语言不会采取任何措施来阻止命令式风格。由于程序员已经以这种风格编码，这就是你所得到的。除非你的团队中有一些真正的铁杆和有点自虐的 FP 爱好者，否则我认为不能在命令式语言中强制执行纯函数式编程风格很长时间。

支持 F# 的最佳论据不一定是函数式编程本身，而是工具集的多样性。与将 IronPython 和 C#(相同的编程范式和不同的类型系统)配对相比，将 F# 和 C#(不同的编程范式和类似的类型系统)配对可以获得更大的 ROI。

我公司案例

好吧，话虽如此，我一直在努力在我的公司插入 F#。我不会详细介绍我们的工作，但基本上我的团队会指导用户完成为时代华纳、ComCast 和其他有线电视提供商等公司订购有线电视和电话服务的过程。

它确实是一个比听起来更复杂的过程。首先，有一个复杂的规则引擎，用于确定产品的可用性、产品之间的依赖关系和排除等。我们遍历规则引擎图并从中构建决策树，然后将树交给客户端，以便他们可以将其显示给用户并收集用户输入，客户端将 GUI 映射回我们的决策树结构，我们遍历树并根据规则引擎验证所有内容，等等。

我想说我们 95% 的代码只是导航、操作和处理树状数据结构。现在，我们编写的所有内容都是 C# 并且有点乱。顺便说一句，F# 的优势之一是操纵 AST 和符号处理(参见 C# and F# code for processing ASTs 的比较)，这一切皆有可能，因为模式匹配很棒。

模式匹配是一个真正的杀手级功能，正是我们的 C# 代码需要清理它的功能，这就是我们需要 F# 的原因。我们对 IronPython 没有任何用处，因为它在符号处理方面并不比 C# 好。

摘要

函数式编程范式和模式匹配是我每天都喜欢使用 F# 的两个杀手级功能。我可以去 F# 的 async线程模型、消息传递并发原语、对 monad 的支持、事件模式等新颖功能等，但这些都是要点注释。对我来说，这两个杀手级功能使 F# 胜过 Python 成为可能——至少对于我自己的项目是这样。