F#与IronPython：何时优先选择其中一种？
虽然F#和IronPython在技术上有很大不同，但我认为它们的潜在用途有很多重叠。那么，什么时候用一个比另一个更合适呢？
到目前为止，我觉得F#在计算效率上更高，而IronPython则继承了Python更好的库。我很乐意接受纠正。
有一个相关的问题F#和IronPython/IronRuby的关系是否就像C#和VB.NET的关系？，但那里的大部分回答讨论的是语言的范式，而不是它们的实际适用性。
编辑：我想我应该多加一点背景。我对Python有很好的经验，最近刚学会F#，之前在Erlang上有过一些犹豫的函数式编程尝试。目前我觉得将来可以继续使用Python或F#。我想决定在什么情况下使用哪个。例如：
- Python的标准库中有非常好的数据结构。前几天我需要一个类似Python的
heap模块，但在标准的F#/.net库中找不到。这个时候IronPython更有优势。 - F#可以用来构建更方便的库，其他.NET语言更容易访问。所以对于一个在.NET环境下的库，我更倾向于使用F#。
- 跨平台开发。IronPython在这方面更好。F#/Mono能用的平台要小得多，而且F#/OCaml的兼容性在库方面也不容易维护。
- 我觉得IronPython的交互式命令行比fsi更容易使用。你的体验可能不同。
所以问题归结为：除了对某种范式的偏好或团队、公司的偏好之外，还有什么理由让你选择F#而不是IronPython，或者反过来？假设你对两者都同样自信？还是说它们在实际应用中是完全等价的？
编辑：好吧，大家，看起来你们觉得这个问题很愚蠢，给它和回答都投了反对票。但至少这是诚实的。所以请给我一点提示。是否不可能区分这两者，还是我在问这个问题时触碰了某种禁忌？如果这看起来像是个恶搞，能不能有人告诉我一下？
5 个回答
F#和IronPython之间最大的区别是：
F#是一种静态语言。
而
IronPython是一种动态语言。
在小规模的情况下（比如一个100行的脚本），动态语言和静态语言的差别不大。但在软件设计或者组件设计上，这两种语言的思维方式就完全不同了。F#的类型系统比Python的要强大得多。
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#。
所以问题归结为：除了个人对某种编程范式的偏好，或者团队或公司的选择之外，还有什么理由让你选择F#而不是IronPython，或者反过来？假设你对这两种语言都很熟悉？或者在实际应用中，它们完全相同吗？
通常情况下，“这要看你在做什么”。但既然你问了，那就从这里开始：
工具多样性
在我看来，IronPython基本上和C#差不多，只是语法稍微不同而已——我知道，这对这两种有着完全不同类型系统的语言来说是个笼统的说法，但我实在没什么更多的可以说的，毕竟它们都是命令式的面向对象语言。不管是C#、Java、C++还是Python，解决问题的方法、习惯、策略和风格大致相同。如果你是个.NET开发者，你几乎肯定用过C#或VB.NET，并且在使用这些语言时，你已经在用命令式风格写代码了。
支持F#的最大理由就是它更鼓励函数式编程风格，减少通过面向对象继承的抽象，强调函数组合，默认使用不可变性，而不是事后才考虑这些。如果你想写函数式代码，就需要用函数式语言。
当然，你可以在C#和Python中写函数式风格的代码，但这些功能往往是事后添加的。Python缺少多行的lambda表达式，而C#则太啰嗦，有时还会出现一些bug，让你在想用函数式风格的地方很难使用，尤其是C#在处理委托和捕获局部变量时有很多坑，而这两种语言几乎在你想用的地方都缺少尾调用优化，C#的类型推断相比F#简直是个笑话。我尝试用C#作为函数式语言，结果可笑得很 :)
大多数人可能会承认，问题让用C#或Python编写函数式风格的代码变得困难，但并不是不可能。然而，根据我的经验，问题不在于语言本身，而在于你团队中的程序员。如果你有10到12个人在用命令式语言写代码，你就很难长期坚持函数式风格——这些语言并没有什么机制来阻止命令式风格。而且既然程序员们已经习惯了这种风格，那你得到的就是这种风格。除非你团队里有一些非常狂热且有点受虐倾向的函数式编程爱好者，否则我认为在命令式语言中很难长期强制执行纯粹的函数式编程风格。
支持F#的最佳理由并不一定是函数式编程本身，而是工具集的多样性。将F#和C#搭配使用（不同的编程范式和相似的类型系统）能获得更高的投资回报，而将IronPython和C#搭配使用（相同的编程范式和不同的类型系统）则不然。
我公司的案例研究
好吧，既然这样，我一直在推动我们公司使用F#。我不想详细讲我们做什么，但基本上我的团队帮助用户完成为像时代华纳、康卡斯特和其他有线电视提供商订购电话和有线电视服务的过程。
这实际上比听起来要复杂得多。首先，有一个复杂的规则引擎来确定产品的可用性、产品之间的依赖关系和排除关系等等。我们遍历规则引擎图，构建出一个决策树，然后把这个树交给客户端，让他们展示给用户并收集用户输入，客户端将GUI映射回我们的决策树结构，我们再遍历树并根据规则引擎验证所有内容等等。
我可以说，我们95%的代码都是在导航、操作和处理树状数据结构。目前，我们写的所有代码都是C#，这有点乱。顺便提一下，F#的一个强项就是操作抽象语法树（AST）和符号处理（可以参考C#和F#处理AST的代码比较），而这一切都得益于模式匹配的强大。
模式匹配是个非常强大的特性，正是我们C#代码所需要的清理工具，这就是我们需要F#的原因。我们对IronPython没有任何需求，因为它在符号处理方面并不比C#更好。
总结
函数式编程范式和模式匹配是我每天都在享受的F#的两个强大特性。我可以谈谈F#的async线程模型、消息传递并发原语、对单子（monads）的支持、像活跃模式这样的新特性等等，但那些都只是一些简单的要点。对我来说，这两个强大特性使得F#在我的项目中优于Python。