F vs Ironpython:一个优先于另一个的是什么时候?

所以问题归结为: 除了 一种模式对另一种模式的偏好 或者一些团队或公司偏好, 那会让你更愿意选择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 关于委托和捕获局部变量,这两种语言几乎在您想使用它们的任何地方都缺乏尾调用优化,与f相比,c的类型推理是一个笑话。我试过用C作为一种功能性语言,结果非常糟糕:)

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

支持f的最佳论据不一定是函数式编程本身,而是工具集的多样性。与Ironpython和C(相同的编程范式和不同的类型系统)的组合相比,F和C(不同的编程范式和相似的类型系统)的ROI组合更大。

我公司案例研究

好吧,这么说来,我一直在努力争取我公司的F。我不会详细介绍我们所做的工作,但实际上,我的团队指导用户为时代华纳、康卡斯特和其他有线电视提供商等公司订购有线和电话服务。

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

我想说95%的代码只是简单地导航、操作和处理树型数据结构。现在,我们写的每一篇都是C和它的一种混乱。顺便说一下,F的优势之一是操纵AST和符号处理(参见 C# and F# code for processing ASTs 因为模式匹配很棒。

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

总结

功能编程范式和模式匹配是我每天喜欢的两个杀手级功能。我可以去F的地方 async 线程模型、消息传递并发原语、monad支持、诸如活动模式之类的新特性等等,但这些都是要点注释。对我来说,这两个杀手级的特性使F比Python更具优势——至少在我自己的项目中是如此。

F和Ironpython最大的区别在于:

F是一种静态语言

和

Ironpython是动态的。

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

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

1. F是静态类型,而Iron python不是。
2. 函数f的基础是函数编程,而铁Python的基础是面向对象的程序设计。(两者都对其他模式有很好的支持。)

这些都是相对较大的差异,它们直接导致了一个比另一个更倾向于另一个的主要实际原因。

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

因为两者都是.NET,所以每个人只需做一点工作就可以使用彼此的库。所以我不认为这是一个主要的问题,尽管我猜在Ironpython中使用scipy是可能的,但是从f开始它会很冗长,并且相应的f的最佳免费库并没有那么好。

函数式编程可以是一种非常强大的风格,并且允许f_具有一些强大的功能,例如工作流,包括f_库很好支持的异步工作流。您可以在Ironpython中大致模拟这类内容,但它不能很顺利地工作,部分原因是库中缺乏支持。

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

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

动态输入有时允许小而简单的程序更快地被编写。如果这是您将要进行的唯一编码,那么最好使用Python。但是,如果一个项目有可能发展成更大的项目,那么我更喜欢F。

你更喜欢哪一个(在你的职能和政治要求的范围内)?哪一个需要更多的初始投资?你想维持哪一个(长期投资)?哪一个能帮你最好地解决你的问题?

铁蟒是,嗯,蟒蛇。这也意味着它比F更具动态性——这增加了运行时开销。如果您喜欢python而不是f,并且它的运行速度足够快,那么为什么不使用它呢?正如您所提到的,它确实有更好的“python库”支持,所以如果您可以利用这一优势,那么就可以获得Ironpython。

另一方面,“just”被限制在.NET(和f友好的)库中,对于f这样的语言来说,并不是那么糟糕,只要库可以做你需要做的事情,或者可以被边缘化。

然而,它 真的可以归结为 以及开发人员的偏好和经验。

我个人尽量避免使用动态语言:—)

Ironpython的动态解释作为客户端浏览器用户代理中单调的javascript语法的一种替代方案而大放异彩。f的静态类型检查覆盖了自定义类型,允许SI或任何此类测量系统可移植库,因此后端层从云端获取数据可以将其重构为更有意义的有用信息。尽管和大多数编程语言一样,它们可以互换使用,但这些引文在客户端应用程序中显示了这两种语言的各自优势。F在复合应用程序中扮演着关键角色,而Ironpython在基于浏览器的用户代理交互中扮演着重要角色。
f的静态类型检查和lambda可能会在一些面向对象的情况下简化ASP.NET,使其更接近经典ASP的级别。Ironpython允许通过用户可修改的脚本进行应用程序扩展,这些脚本以及第三方插件扩展不仅在浏览器、媒体播放器、Dream Weaver和其他编辑器中流行。
Ironpython可能被重新分解为纯python和.net依赖的部分,从而预测可重用性用例。到目前为止,F是其他基于面向对象范式的智能.NET的功能范式面。