使用 C# vs F# 或 F# vs C# 有什么好处？ [关闭]答案

【问题标题】：What are the benefits of using C# vs F# or F# vs C#? [closed]使用 C# vs F# 或 F# vs C# 有什么好处？ [关闭]
【发布时间】：2010-10-31 10:33:50
【问题描述】：

我在一家技术公司工作，该公司的原型设计多于产品发货。刚被问到C#和F#有什么区别，MS为什么要创建F#，在什么场景下会比C#好。

我已经使用该语言有一段时间了，我很喜欢它，因此我可以轻松地继续介绍 F# 的强大功能，但是我缺乏 C# 的经验来说明为什么我们应该使用一种而不是另一种。

使用 C# 与 F# 或 F# 与 C# 有什么好处？

【问题讨论】：

在我看来，SO 上已经有很多问题，至少部分回答了您的问题。您是否尝试过使用“[F#] 关键字”而不是“f# 关键字”进行搜索？（例如“[f#] 优势”）

标签： c# .net f#

【解决方案1】：

F# Has Better Performance than C# in Math
您可以在与 C# 相同的解决方案中使用 F# 项目（并从一个到另一个调用）
F# 非常适合复杂的算法编程、金融和科学应用程序
从逻辑上讲，F# 非常适合并行执行（让 F# 代码在并行内核上执行比 C# 更容易）

【讨论】：

关于 F# 的数学性能比 C# 更好：显然，这不是真的。见thoughtfulcode.wordpress.com/2010/12/30/…
@Joh:inline 是一个明显的例子，它可以在 F# 中提供 C# 无法表达的巨大性能改进。
@Jon Harrop：我专门指的是 Rinat 的博客条目。似乎他得到的支持 F# 的时机是由于 C# 代码次优。

【解决方案2】：

您要求比较程序语言和函数语言，所以我觉得您的问题可以在这里得到回答：What is the difference between procedural programming and functional programming?

至于 MS 创建 F# 的原因，答案很简单：创建一种可以访问 .Net 库的函数式语言只是扩大了他们的市场基础。看到语法与 OCaml 几乎相同，他们真的不需要太多努力。

【讨论】：

虽然我认为你的一般回答是正确的，真正的问题是关于编程范式而不是语言的比较，但我觉得你所指问题的答案有点肤浅。
如果您有更好的问题，请随时提出其他问题。这是我从谷歌搜索中找到的评分最高的。
我认为他是想善待你，因为你说 F# 不需要 Micrsoft 付出太多努力。
我不相信回答我问题的其他链接。 C# 在较新的版本中支持许多函数式构造。
C# vs F# != 程序 vs 函数。

【解决方案3】：

这就像问锤子比螺丝刀有什么好处。在非常高的层次上，两者本质上都做同样的事情，但在实现层次上，为你想要完成的事情选择最佳工具很重要。在 c# 中有些任务既困难又耗时，但在 f# 中却很容易——比如试图用螺丝刀敲钉子。你可以做到，当然——这并不理想。

数据操作是我个人可以指出的一个例子，其中 f# 真正闪耀而 c# 可能很笨拙。另一方面，我想说（一般来说）复杂的有状态 UI 在 OO（c#）中比功能性（f#）更容易。（可能会有一些人不同意这一点，因为现在“很酷”来“证明”在 F# 中做 任何事情 是多么容易，但我支持它）。还有无数其他的。

【讨论】：

如果你只有一把锤子，那么一切看起来都像钉子。 -马斯洛
我不会对此投赞成票，因为除了一个数据示例之外，它没有给出任何真实的细节。我知道它们是不同的工具。我在问这两种工具在哪些工作方面最好和最差。我知道飞利浦通常是完成这项工作的最佳工具，即使较小的平头也可以。
哈哈，谢谢@Spencer ;) @gradbot - 没问题！抱歉，我的答案不是您要找的……希望其他人会觉得它有用。
如果你只有一把锤子，那么一切看起来都像拇指。
我同意 gradbot，这是一个很好的答案，因此我没有反对，但它并没有真正涉及到原始问题的细节。这个答案只是一个模糊的概念解释，但确实错过了准确回答问题的重点。

【解决方案4】：

如果您将 F# 与 C#、C++、VB 进行比较，它还不是另一种编程语言。 C#、C、VB 都是命令式或过程式编程语言。 F# 是一种函数式编程语言。

函数式编程语言（与命令式语言相比）的两个主要优点是 1. 它们没有副作用。这使得关于程序属性的数学推理变得容易得多。 2. 职能是一等公民。您可以将函数作为参数传递给另一个函数，就像传递其他值一样容易。

命令式和函数式编程语言都有其用途。虽然我还没有在 F# 中做任何认真的工作，但我们目前正在我们的一个基于 C# 的产品中实现调度组件，并且将通过在 F# 中编写相同的调度程序来做一个实验，看看是否正确实现比使用 C# 等效项更容易验证。

【讨论】：

-1。 F# 是一种多范式 (OO+FP) 语言。只有纯粹函数式语言没有副作用（如 Haskell），但 F# 不是纯粹的。

【解决方案5】：

函数式编程相对于命令式语言的一般优势：

在 F# 等函数式编程语言中，您可以更轻松、更接近其定义、更简洁地表述许多问题，并且您的代码更不容易出错（不变性、更强大的类型系统、直观的递归算法）。您可以根据自己的意思编写代码，而不是计算机要您说的内容；-) 当您在 Google 上搜索或什至在 SO 上搜索时，您会发现很多这样的讨论。

特殊 F# 优势：

使用async {}-expressions，异步编程非常简单直观 - 即使使用 ParallelFX，相应的 C# 代码也要大得多
Very easy integration 的编译器编译器和特定领域的语言
根据需要扩展语言：LOP
Units of measure
更灵活的语法
通常更短、更优雅的解决方案

看看this document

C# 的优势在于，它通常比函数式编程语言更准确地用于“命令式”应用程序（用户界面、命令式算法），它使用的 .NET 框架是命令式设计的，并且使用范围更广。

此外，您可以在一个解决方案中同时使用 F# 和 C#，这样您就可以结合两种语言的优点并在需要的地方使用它们。

【讨论】：

它们以非常奇怪的方式结合在一起。例如，您可以重载 F# 中的 > 运算符。然后 C# 开发人员可以使用它。但是，F# 开发人员不能。没错，F# 可以发出它不能消费的运算符重载。
“此文档”链接已损坏...

【解决方案6】：

F# 本质上是函数式编程语言的 C++。他们保留了 Objective Caml 中的几乎所有内容，包括非常愚蠢的部分，并将其放在 .NET 运行时之上，这样它也将 .NET 中的所有坏东西都带入了。

例如，使用 Objective Caml，您会得到一种类型的 null，即选项。使用 F#，您可以获得三种类型的 null、option、Nullable 和引用 null。这意味着如果您有一个选项，您需要先检查它是否为“None”，然后您需要检查它是否为“Some(null)”。

F# 就像旧的 Java 克隆 J# 一样，只是为了吸引注意力而使用的混蛋语言。有些人会喜欢它，其中一些人甚至会使用它，但最终它仍然是一个 20 年历史的语言。

【讨论】：

希望大众对他们有所了解，F# 5 会更加务实。
我同意 Nullable 应该让编译器为我们做一些神奇的别名。我不确定让“Some null”等同于 None 是否总是有效 - 一些互操作代码可能依赖它。但是参考null？您将如何解决 .NET 中的一个主要漏洞？将每个引用类型包装在一个选项中？实际上，这似乎只是某些互操作场景的问题。
FWIW，我从事 F# 专业编码已有好几年了（比世界上几乎任何其他人都长），我从未在任何地方的任何 F# 代码中看到过这个问题或代码 Some null。在人们可能抱怨的所有事情中，这必须在列表中waaay...
将 F# 与 C++ 进行比较有点牵强。 C++ 的许多部分具有未定义或不明确的语义，F# 简单且定义明确。 .NET 运行时的质量无法与 F# 相媲美，因为任何 .NET 语言都会有同样的问题。
在 2 年多的专业 F# 编程中，比如 @Jon，我从未见过任何与“Some null”相关的问题。另一方面，我从 .Net 框架的特性中获益良多。

【解决方案7】：

按照我的理解回答您的问题：为什么使用 C#？（你说你已经在 F# 上出售了。）

首先。这不仅仅是“功能与 OO”。这是“功能+ OO与OO”。 C# 的功能特性非常初级。 F# 不是。同时，F# 几乎完成了 C# 的所有 OO 功能。在大多数情况下，F# 最终成为 C# 功能的超集。

但是，在某些情况下 F# 可能不是最佳选择：

互操作。有很多库对 F# 来说并不太舒服。也许他们利用了某些 C# OO 的东西，而 F# 没有这样做，或者他们依赖于 C# 编译器的内部结构。例如，表达式。虽然您可以轻松地将 F# 引用转换为表达式，但结果并不总是与 C# 完全相同。某些图书馆对此有问题。
- 是的，互操作是一个很大的网络，可能会导致与某些库的一些摩擦。
- 如果您有一个庞大的现有代码库，我认为互操作也包括在内。仅仅开始在 F# 中编写部件可能没有意义。
设计工具。 F# 没有。并不意味着它不能有，但现在你不能用 F# 代码隐藏创建一个 WinForms 应用程序。即使在受支持的地方（例如在 ASPX 页面中），您目前也无法获得 IntelliSense。因此，您需要仔细考虑生成代码的边界在哪里。在一个几乎完全使用各种设计器的非常小的项目中，将 F# 用于“胶水”或逻辑可能不值得。在较大的项目中，这可能不会成为问题。
- 这不是内在问题。与 Rex M 的回答不同，我看不到 C# 或 F# 的任何内在特性，它们可以更好地使用大量可变字段来制作 UI。也许他指的是必须编写“可变”并使用
- 还取决于使用的库/设计器。我们喜欢为所有控制器使用带有 F# 的 ASP.NET MVC，然后使用 C# Web 项目来获取 ASPX 设计器。我们在 C# 和 F# 之间混合实际的 ASPX“内联代码”，具体取决于我们在该页面上需要什么。（IntelliSense 与 F# 类型。）
其他工具。他们可能只期待 C#，不知道如何处理 F# 项目或编译代码。此外，F# 的库不作为 .NET 的一部分提供，因此您可以提供一些额外的内容。
但是第一大问题呢？人们。如果您的开发人员都不想学习 F#，或者更糟的是，在理解某些方面有严重的困难，那么您可能就完蛋了。（不过，在这种情况下，我认为无论如何你都是敬酒。）哦，如果管理层拒绝，那可能是个问题。

我不久前写过这个：Why NOT F#?

【讨论】：

【解决方案8】：

我最喜欢 .NET 的一个方面是泛型。即使您使用 F# 编写过程代码，您仍然可以从类型推断中受益。它使编写通用代码变得容易。

在 C# 中，默认情况下您会编写具体代码，而您必须付出一些额外的工作来编写通用代码。

在 F# 中，您默认编写通用代码。经过一年多的 F# 和 C# 编程后，我发现我用 F# 编写的库代码比我用 C# 编写的代码更简洁、更通用，因此也更具可重用性。我错过了很多用 C# 编写泛型代码的机会，可能是因为我被强制性的类型注释蒙蔽了双眼。

然而，根据个人的品味和编程风格，在某些情况下使用 C# 更可取。

C# 不强制类型之间的声明顺序，并且它对文件的编译顺序不敏感。
C# 有一些因类型推断而 F# 无法承受的隐式转换。

【讨论】：