时间:2010-07-25 03:34:33

标签: .net python f# ironpython

5 个答案:

答案 0 :(得分:27)

  

所以问题归结为:是   有什么理由,除了一个   一种范式偏好另一种范式   或某些团队或公司偏好,   这会让你选择F#而不是   比IronPython还是反之?   假设你同样有信心   都?或者它们完全相同   出于所有实际目的?

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

工具集多样性

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

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

当然,你可以在C#和Python中编写功能样式,但功能特性是作为事后的想法嫁接的。 Python缺少多行lambdas,C#太冗长,偶尔buggy在你想要使用它的地方使用函数样式,C#特别有关于委托的整个boatload of gotchas和捕获局部变量,两种语言几乎无处可寻,无法在你想要使用它们的地方进行尾调用,C#的类型推断与F#相比是一个笑话。我尝试使用C#作为一种功能性语言,结果非常糟糕:)

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

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

我公司的案例研究

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

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

我会说95%的代码只是导航,操作和处理树状数据结构。现在,我们写的所有东西都是C#而且它是一团糟。顺便提一下,F#的一个优点是操纵AST和符号处理(参见C# and F# code for processing ASTs的比较),这一切都可能因为模式匹配很棒。

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

<强>摘要

功能性编程范式和模式匹配是我每天享受F#的两个杀手级功能。我可以使用F#的async线程模型,消息传递并发原语,monad支持,活动模式等新功能,但这些都是项目符号注释。对我而言,这两个杀手级功能可以为F#提供基于Python的功能 - 至少对我自己的项目而言。

答案 1 :(得分:4)

答案 2 :(得分:4)

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

  1. F#是静态类型,而Iron Python不是。
  2. F#的基础是函数式编程,而Iron Python的基础是面向对象的编程。 (两者都对其他范例有很好的支持。)
  3. 这些是相对较大的差异,它们直接导致偏好一方的主要实际原因。

    正如你所说,由于缺乏静态类型,Iron Python比F#慢。在计算机语言基准测试中,Iron Python的中位数为25x,最差情况下为120x。因此,如果考虑运行时性能,则可能更喜欢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 :(得分:1)

答案 4 :(得分:0)

Ironpython的动态解释可以替代客户端浏览器用户代理中单调的javascript语法。 F#的静态类型检查覆盖自定义类型允许SI或任何此类测量系统可移植库,因此从云端获取数据的后端层可以更有意义地将其重新编码为有用信息。虽然像大多数编程语言一样,它们可以互换地用于这些和更多的东西,但这些引用在客户端应用程序中展示了两者的完全不同的优势。 F#在复合应用程序中起着至关重要的作用,而Ironpython在基于用户代理浏览器的交互中扮演着重要角色。
F#的静态类型检查和lambdas可能会在几个面向对象的场合下简化ASP.net,接近传统ASP的水平。 Ironpython允许用户可修改脚本实现应用程序的可扩展性,以及第三方插件扩展,这些扩展不仅受到浏览器,媒体播放器,梦想织布工和其他编辑者的欢迎。
Ironpython可能被重新考虑在内纯python和.net依赖部分预见可重用性用例。到目前为止,F#作为基于面向对象的其他范式的功能范式面临.net