F# 之于 IronPython/IronRuby 就像 C# 之于 VB.NET 一样？
我刚刚听了 Chris Smith 的播客谈论 F#，其中他谈到 F# 是一种如何允许您以与 C#/VB.NET 不同的方式处理问题的语言，即，而不是“到处乱推数据”您“将数据转换链接在一起”，以及 F# 如何“变得像 XML”，您可以在选择的语言（C# 或 VB.NET）之外使用它，以便以更有效的方式解决某些问题。
这让我开始思考.NET 语言之间的关系，以下是我对它们的理解：
- C# 和 VB.NET 在语法上有区别，但没有本质上的不同，即 C# 程序员不会为了“以新的方式解决问题”而学习 VB.NET，
- ，C# 或 VB.NET 程序员会学习 F#，以便“以函数式方式解决编程问题”
但是 关于 IronPython 和 IronRuby？ Chris 提到“F# 从 Ruby 和 Python 学到了很多东西”，因此我认为 F# 与 IronRuby/IronPython 有着类似的关系，而 C# 与 VB.NET 有着类似的关系。 然而，通过谷歌搜索发现，IronRuby 和 IronPython 都是基于 DLR 构建的，但 F# 不是。
如何最好地理解 F#、IronRuby 和 IronPython 之间的关系？
I just listened to podcast of Chris Smith talking about F# in which he talks about how F# is a language which allows you to approach problems in a different way than in C#/VB.NET, i.e. instead of "pushing bits around" you "chain together data transformations", and that how F# will "become like XML", something that you use in addition to your language of choice (C# or VB.NET) in order to solve certain problems in a more efficient way.
This got me to thinking about the relationship of the .NET languages, here's how I understand them:
- C# and VB.NET are syntactically but not substantially different, i.e. a C# programmer would not learn VB.NET in order to "approach problems in a new way"
- however, a C# or VB.NET programmer would learn F# in order to "approach programming problems in a functional way"
But what about IronPython and IronRuby? Chris mentioned that "F# learned a lot from Ruby and Python" so I would think that F# has a similar relationship to IronRuby/IronPython and C# has to VB.NET. However, a little googling around tells me that IronRuby and IronPython are both built on the DLR but F# is not.
How are the relationships between F#, IronRuby and IronPython to be best understood?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
从语言角度来看，F# 和 IronPython/IronRuby 相差数光年。 F# 是一种函数式、高度类型化的编译语言。 IronRuby/IronPython 是动态类型、解释性语言。
我相信 IronPython 确实还支持编译，但我不是 100% 确定，而且对 ruby 的支持更少。
VB.Net 和 C# 之间的关系更为密切。
F# and IronPython/IronRuby are light years apart from a language perspective. F# is a functional, highly typed compiled language. IronRuby/IronPython are dynamically typed, interpreted languages.
I believe IronPython does additionally support compilation but I'm not 100% sure, and less about ruby.
The relationship between VB.Net and C# is much closer.
在许多方面，F# 和 Ruby/Python 表面上很相似。 所有这三种语言都允许您简洁地表达想法，而不会在代码中添加多种类型。 然而，F# 实际上与 Ruby 和 Python 有很大不同，因为 F# 是静态类型语言，而 Ruby 和 Python 是动态类型的。 惯用的 F# 代码很少提及类型，但编译器会推断类型，并且编译器会在编译期间标记任何类型错误。 对于 Ruby 和 Python，使用错误类型的值只会在运行时生成错误。 Ruby 和 Python 的活力意味着两者都比 F# 更适合元编程（例如，可以在运行时修改类型）。 另一方面，F# 对于大多数任务来说都具有更高的性能（与 C# 相比），并且提供了许多很好的函数抽象，例如具有模式匹配的可区分联合。 确实，学好这些语言中的任何一种都会让您以不同于 C# 或 VB.NET 的方式思考问题，但您的方法在 F# 和 Python/Ruby 之间也可能有很大差异。
In many ways F# and Ruby/Python are superficially similar. All three languages allow you to concisely express ideas without littering your code with many types. However, F# is actually very different from Ruby and Python, since F# is a statically typed language, while Ruby and Python are dynamically typed. Idiomatic F# code rarely mentions types, but the compiler infers types and any type errors will be flagged by the compiler during compilation. For Ruby and Python, using a value at the wrong type will only generate errors at run-time. Ruby and Python’s dynamism means that both are more amenable to metaprogramming than F# is (types can be modified at runtime, for instance). On the other hand, F# is going to be more performant for most tasks (comparable to C#), and offers many nice functional abstractions such as discriminated unions with pattern matching. It’s certainly true that learning any of these languages well will lead you to think about problems differently than you do in C# or VB.NET, but your approach will probably vary a lot between F# and Python/Ruby as well.
我想说 F# 从 OCaml 学到的东西比从 Ruby 和 Python 学到的东西加起来还要多。 唯一真正的比较是，F# 将 ML 引入 .NET，就像 IronPython/Ruby 将 Python/Ruby 引入 .NET 一样。
I'd say F# learned a whole lot more from OCaml than it did from Ruby and Python combined. The only real comparison is that F# is brings ML to .NET in the same way that IronPython/Ruby bring Python/Ruby to .NET.
F# 更像是一种“工具”语言，其中存在最好通过函数式方法解决的特定问题。 F# 本质上是线程安全的，这有望有助于扩展应用程序以使用多个处理器。 我看到 F# 被用来构建将在 VB.NET 或 C# 中使用的组件来处理特定问题。
F# is more of a "tool" language where there are specific problems that are best tackled with a functional approach. F# is inherently thread safe which gives hope that it will be helpful in scaling an application to use multiple processors. I see F# being used to build components that will be used in VB.NET or C# to handle specific problems.
F# 的某些方面与动态语言相似； 然而，JaredPar 的回答确实概括了这一点。 F# 属于它自己的函数式编程类别，而 IronRuby 和 IronPython 是动态语言和 C#/VB OO 语言。 他们都可以做同样的事情，只是取决于你想如何做。 对于给定的问题，每种方法都有其优点和缺点。
There are aspects of F# that are similar to dynamic languages; however, JaredPar's answer sums it up really. F# is in it's own category of functional programming where as IronRuby and IronPython are dynamic languages and C#/VB OO Languages. They can all do the same things and just depends on how you want to do it. Each has it's pros and cons for a given problem.
注意：这主要是我对这个主题的想法和观察的汇编。 我白天是 C# 程序员，晚上是 Python 程序员。
是的，我同意人们所说的一些内容，但我有一些时间，想阐述和分享我的想法。
F# 是一种函数式语言。 这意味着你实际上更关心动词。 它仍然是静态类型并在 CLR 上运行，但您可以以不同的方式构建代码并以不同的方式解决问题。 通常人们认为函数式语言在结构上更数学化，更容易形式化证明。 当然，这通常被认为主要是学术性的。
C# 和其他静态类型的 OO 语言实际上更关注名词，以进一步加深我的类比。 因此，您构建代码并解决与此相关的问题。 当然，维护状态和对对象使用非确定性方法也存在自然问题，这些问题在 OO 语言中更常见。
当然，F# 借鉴了 OO 语言的一些功能和思想，而 C# 则借鉴了函数式语言的思想和功能。
比较 Python 和 C# 更多的是动态类型和静态类型之间的区别（尽管 Python 确实提供了一些 C# 仍然没有的功能特性）。 动态类型通常更容易处理内省/反射活动和运行时修改，同时增加了由于“常规”代码中使用的拼写错误或不正确的对象而导致运行时错误的风险。
静态语言通常需要一些动态语言所没有的开发人员开销。 开销似乎通常是由于必须创建层来抽象事物并创建继承层次结构和接口来处理所需/想要的抽象。 因为您试图避免对类型的依赖。
看起来静态语言在更大的团队中更容易管理。 另外，您可以通过所有检查和工具轻松地获得重构的优势。
NOTE: This is mostly a compilation of my thoughts and observations on the subject. I'm a C# programmer by day and Python by night.
Yeah I agree with some of the stuff that has been said, but I have some time and feel like elaborating and sharing my thoughts.
F# is a functional language. Which means you are really more concerned with the verbs so to speak. It is still statically typed and runs on the CLR, but you structure your code differently and work through problems differently. Usually people think that functional languages are more mathematical in structure and easier to prove formally. Of course that is generally regarded as mostly academic.
C# and other statically typed OO languages are really more focused on the nouns to further my analogy. So you structure your code and work through problems in regards to that. Of course there are also natural problems with maintaining state and having non-deterministic methods on objects that tend to come up more often in OO languages.
And of course F# has some features and ideas borrowed from OO languages while C# has ideas and features borrowed from functional.
Comparing Python and C# is more about the difference between dynamic and static typing (although python does offer some functional features that C# still does not). Dynamic typing usually being far easier to handle introspection/reflection activities and run-time modification while adding the risk of run-time errors due to typos or incorrect objects used in "regular" code.
Static languages usually have some developer overhead that dynamic languages do not have. The overhead seems to usually be due to having to create layers to abstract things away and creating inheritance hierarchies and interfaces to work with the needed/wanted abstraction. Since you are trying to avoid dependencies to types.
It seems like statics languages can be much easier to manage in larger teams. Plus you get the advantages of refactoring very easily with all the checking and tools out there.