F# vs IronPython：什么时候更喜欢另一个？答案

【问题标题】：F# vs IronPython: When is one preferred to the other?F# vs IronPython：什么时候更喜欢另一个？
【发布时间】：2011-03-20 15:57:01
【问题描述】：

虽然 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 更容易。 YMMV。

所以问题归结为：除了偏爱一种范式对另一种范式或某些团队或公司的偏好之外，是否有任何理由让您选择 F# 而不是 IronPython，反之亦然？假设您对两者都同样有信心？或者它们在所有实际用途中完全等效？

编辑：好吧，伙计们，看起来你认为这是一个愚蠢的问题，否决了它的答案。但至少它是诚实的。所以请只是一个提示。问这个问题是不可能区分两者还是我进入了一些秘密禁忌？如果它看起来像一个巨魔，有人可以告诉我吗？

【问题讨论】：

您更喜欢哪一个（在您的职能和政治要求范围内）？
我不认为这是一个愚蠢的问题，但这是一个奇怪的问题。它们是非常不同的开发语言，而且也相当小众，而且我不认为地球上除了你之外，还有几个人不得不做出这个选择。任何这样做的人都可能只是使用他们更熟悉的语言。
如果你的问题是“诚实的”，你就会承认我已经两次反驳了你的第一点，向你推荐了 F# 的内置 Set 数据结构。
@Jon：看。你还没有反驳任何东西。我告诉过你集合和优先级队列之间是有区别的。您刚刚提到 F# Set 可用是昨天，并且您给出了一个错误的使用示例，其中优先级队列用于排序，这不是它的重点。不过，如果您能在另一个问题上说服我或说服其他人 F# Set 用作优先级队列，我将在此处进行修改。
@Kylotan：谢谢。这实际上是一个很好的答案。

标签： .net python f# ironpython

【解决方案1】：

Ironpython 的动态解释可以替代客户端浏览器用户代理中单调的 javascript 语法。 F# 的涵盖自定义类型的静态类型检查允许 SI 或任何此类测量系统可移植库，因此从云中获取数据的后端层可以将其改造成更有意义的有用信息。虽然与大多数编程语言一样，它们可以与这些以及更多的东西互换使用，但这些引用在客户端应用程序中展示了两者的完全不同的优势。 F# 在复合应用程序中扮演关键角色，而 Ironpython 在基于用户代理浏览器的交互中扮演角色。
F# 的静态类型检查和 lambdas 可能会在更接近经典 ASP 水平的几个面向对象的情况下简化 ASP.net。 Ironpython 允许通过用户可修改的脚本进行应用程序扩展，这些脚本与 3rd 方插件扩展一样，不仅在浏览器中流行，而且在媒体播放器、dream-weaver 和其他编辑器中都很流行。
Ironpython 可能被重新分解为纯python 和 .net 依赖部分预见可重用性用例。到目前为止，F# 是基于 .net 的面向对象范式的功能范式面

【讨论】：

【解决方案2】：

F# 和 Iron Python 的两个主要区别是：

F# 是静态类型的，而 Iron Python 不是。
F# 的基础是函数式编程，而 Iron Python 的基础是面向对象的编程。（两者都对其他范式有很好的支持。）

这些是相对较大的差异，它们直接导致了偏好其中一个而不是另一个的主要实际原因。

正如您所说，由于缺少静态类型，Iron Python 比 F# 慢。在计算机语言基准测试中，Iron Python 的中位数是 25 倍，在最坏的情况下慢 120 倍。因此，如果考虑运行时性能，F# 可能更可取。
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=ironpy&lang2=fsharp

由于两者都是 .NET，因此只需做一点工作，就可以使用对方的库。所以我不认为这是一个主要问题，尽管我猜想在 IronPython 中使用 SciPy 是可能的，但从 F# 来说它会很乏味，而且 F# 的相应最佳免费库也不是那么好。

函数式编程可以是一种非常强大的风格，它允许 F# 拥有一些强大的功能，例如工作流，包括 F# 库很好支持的异步工作流。你可以在 Iron Python 中粗略地模拟这些东西，但它的工作并不那么顺利，部分原因是库中缺乏支持。

许多程序员更熟悉面向对象，因此他们可能更喜欢 Python。

静态类型还允许 IDE 为程序员提供更好的支持。可以将每个变量的类型报告给程序员（通过在 VS 中悬停），并且可以在编辑代码时给出错误反馈。作为一名大学讲师，我可以说这种即时反馈对我的学生在学习 F# 时非常有用。这使他们能够管理比其他方式更复杂的程序。

动态类型有时可以让小而简单的程序编写得稍微快一些。如果这是您将要做的唯一编码，那么 Python 可能更可取。但是，如果一个程序有可能成长为更大的东西，那么我更喜欢 F#。

【讨论】：

【解决方案3】：

所以问题归结为：是有什么原因，除了一种范式对另一种范式的偏好或一些团队或公司的偏好，这会让你选择 F# 而不是比 IronPython，反之亦然？假设你同样有信心两个都？或者它们是否完全等价出于所有实际目的？

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

工具集多样性

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

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

当然，您可以在 C# 和 Python 中编写函数式样式，但函数式特性是事后才嫁接的。 Python 缺少多行 lambda，C# 过于冗长，偶尔buggy 无法在您想使用它的地方使用函数式样式，C# 特别是在委托和捕获局部变量方面有一个完整的boatload of gotchas，两种语言都缺乏尾调用优化几乎无处不在，C# 的类型推断与 F# 相比简直就是个笑话。我曾尝试使用 C# 作为函数式语言，但结果非常糟糕：)

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

支持 F# 的最佳理由不一定是函数式编程本身，而是工具集的多样性。与配对 IronPython 和 C#（相同的编程范例和不同的类型系统）相比，配对 F# 和 C#（不同的编程范式和相似的类型系统）可以获得更大的投资回报率。

我公司的案例研究

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

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

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

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

总结

函数式编程范式和模式匹配是我每天都喜欢使用 F# 的两个杀手级功能。我可以讨论 F# 的 async 线程模型、消息传递并发原语、对 monad 的支持、活动模式等新特性，但这些都是要点 cmets。对我来说，正是这两个杀手级特性让 F# 优于 Python —— 至少在我自己的项目中如此。

【讨论】：

我已经接受了这个答案，尽管我还有一些问题。我不懂 C#，在使用 F# 和 IronPython 之前我也不是 .Net 开发人员。我知道函数式编程和命令式编程之间存在很大的鸿沟，但人们倾向于淡化动态类型和类型推断与静态类型之间的区别，这使得 F# 和 IronPython 在表达上比例如 Java。所以 F# 和 C# 的比较可能并不等同于 F# 和 Python 的比较。
Python 缺少多行 lambda，是的。但是，到目前为止，我还不需要在 F# 中使用未命名的多行函数。所以我不会认为这是主要问题。对我来说问题更大的是柯里化和流水线，这两者都可以在 F# 中直接使用。
不过，总结很精彩。可能是最有价值的部分。

【解决方案4】：

F# 和 IronPython 最大的区别在于：

F# 是一种静态语言

和

IronPython 是动态的。

虽然在小级别（例如 100 行脚本）上，动态和静态语言没有太大区别。在软件设计/组件设计方面，这两种语言有两种不同的思维模式。 F# 中的类型系统也比 Python 强大得多。

【讨论】：

我有点好奇您所说的“F# 中的类型系统也比 Python 的强大得多”是什么意思。你能详细说明一下吗？
类型在 Python 中不是问题； EAFP 意味着您基本上可以忽略它们。这导致了一些强大的多态性（想要花哨的strings？只要继承，一切仍然可以工作！），但也会导致一些非常讨厌的错误（哦，我想将两个整数相乘，但是糟糕，一个实际上是一个列表，现在帮助！我的清单真的很大！）。另一方面，F# 使用 ML 强大的类型系统。这意味着它会计算出适合您的类型，并在编译时检查一切是否正常。这可以防止许多错误，但有时会很烦人。
如今它变得比“静态”与“动态”更复杂。几乎所有语言都存在于连续统一体的某个地方，而不是处于一个或另一个极端。例如，如果您关心的唯一动态语言特性是鸭子类型，那么 F# 可以通过其非常丰富的类型约束系统来处理它。

【解决方案5】：

您更喜欢哪一个（在您的职能和政治要求范围内）？哪一个需要更多的初始投资？你想维持哪一个（长期投资）？哪一个最能帮助您解决问题？

IronPython 就是 Python。这也意味着它比 F# 更具动态性——这增加了运行时开销。如果您更喜欢 Python 而不是 F#，并且它对您来说运行得足够快，那么为什么不使用它呢？正如你所提到的，它确实有更好的“Python 库”支持，所以如果你可以利用它来发挥你的优势，那就给 IronPython 打分吧。

另一方面，“只是”受限于 .NET（和 F# 友好）库对于像 F# 这样的语言来说确实不是那么糟糕，只要存在执行您需要执行的操作的库或可以被边缘化。

但是，它确实归结为范式以及开发人员的偏好和经验。

我个人尽可能避免使用动态语言 :-)

【讨论】：

@pst：查看我编辑的问题。我知道范式是其中的重要组成部分，可以这么说，我已经学会了 F# 来熟悉功能。除此之外还有没有区别吗？