F#vs IronPython:什么时候优先选择另一个？

Question

虽然F#和IronPython语言在技术上不同,但我认为它们的潜在用途之间存在很大的重叠.什么时候比另一个更适用？

到目前为止,我认为F#在计算上更有效率,而IronPython从Python继承了更好的库.我很高兴得到纠正.

有一个相关的问题是F#to IronPython/IronRuby,因为C#是VB.NET的？但大多数答案都是关于语言范式而不是它们的实际适用性.

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

1. Python作为标准库的一部分具有非常好的数据结构.前几天我需要一个相当于Python的heap模块,它在标准的F#/ .net库中不可用.指向IronPython.
2. F#可用于构建更方便的库,更易于从其他.Net语言访问.所以对于.Net驻留库我更喜欢F#.
3. 跨平台开发.IronPython在这里更好.F#/ Mono可用是一个小得多的平台集,F#/ OCaml兼容性不易维护,特别是在库方面.
4. IronPython交互式shell在我看来比fsi更容易.因人而异.

因此,问题归结为:除了偏好一种范式而不是另一种或某些团队或公司偏好之外,还有什么理由可以让你选择F#而不是IronPython,反之亦然？假设你对两者都有同样的信心？或者它们是否完全等同于所有实际目的？

编辑:好的,看起来你认为这是一个愚蠢的问题,低估它和答案.但至少它是诚实的.所以请提示一下.是不是可以区分这两者,还是我通过提出这个问题进入一些秘密禁忌？如果它看起来像一个巨魔可以有人请通知我？

Answer 1

因此,问题归结为:除了偏好一种范式而不是另一种或某些团队或公司偏好之外,还有什么理由可以让你选择F#而不是IronPython,反之亦然？假设你对两者都有同样的信心？或者它们是否完全等同于所有实际目的？

通常情况下,"这取决于你在做什么"但是既然你问过,从这里开始:

工具集多样性

在我看来,IronPython与C#本质上是一样的,语法略有不同 - 我知道,它是两种语言的全面推广,具有完全不同的类型系统,但是我们对其他命令的说法并不多. ,OO语言.无论是C#,Java,C++还是Python,您都可以使用大致相同的技术,习惯用法,策略,风格等来解决语言.如果您是.NET开发人员,那么您几乎肯定会使用C#或VB. NET,只要你一直在使用这些语言,你就已经以强制性的方式编写代码了.

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

当然,您可以在C#和Python中编写功能样式,但功能特性是作为事后想法嫁接的.Python却没有多行lambda表达式,而C#是太冗长,偶尔越野车进行使用功能的风格,你想用它的地方,C尤其#有一个整体陷阱的一大堆关于代表和捕捉局部变量,无论是语言缺乏tail-几乎在你想要使用它们的地方调用优化,与F#相比,C#的类型推断是一个笑话.我尝试使用C#作为一种功能性语言,结果非常糟糕:)

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

支持F#的最佳理由不一定是函数式编程本身,而是工具集的真正多样性.与配对IronPython和C#(相同的编程范例和不同类型系统)相比,您可以获得更大的ROI与F#和C#(不同的编程范例和类似类型系统)配对.

我公司的案例研究

好的,所以说,我一直在努力为我的公司推动F#.我不会详细介绍我们的工作,但基本上我的团队会指导用户完成为时代华纳,ComCast和其他有线电视提供商等公司订购有线和电话服务的过程.

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

我要说95%的代码只是导航,操作和处理树状数据结构.现在,我们写的所有东西都是C#而且它是一团糟.顺便提一下,F#的优点之一就是操纵AST和符号处理(参见C#和F#代码对比处理AST),这一切都是可能的,因为模式匹配非常棒.

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

摘要

功能编程范例和模式匹配是我每天享受F#的两个杀手级功能.我可以了解F#的async线程模型,消息传递并发原语,monad支持,活动模式等新功能,但这些都是子弹点评论.对我而言,这两个杀手级功能可以为F#提供基于Python的功能 - 至少对我自己的项目而言.

Answer 2

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

1. F# 是静态类型的，而 Iron Python 不是。
2. 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#。