F# 在哪些领域“绝对没有使用意义”？ [关闭]答案

【问题标题】：In what areas does F# make "absolute no sense in using"? [closed]F# 在哪些领域“绝对没有使用意义”？ [关闭]
【发布时间】：2011-07-14 01:23:16
【问题描述】：

Don Syme 在他的 SPLASH 演讲中说 F# 并不是要替代 C#，即使它具有一般功能。他接着说，有些领域 F# 使用起来毫无意义，但没有在论文上展开。

谁能告诉我在使用 F# 时应该避免哪些区域？
您还可以提及 C# 的亮点。

【问题讨论】：

我认为他这样说是为了让 C# 团队和管理层开心（一些关于策略的事情）。这有点像在 Java 会议上谈论 Scala。
这怎么跑题了？这怎么和编程无关？ “有关 Stack Overflow 的问题通常与编程或软件开发有关，在常见问题解答中定义的范围内。
不提名字，我能想到至少有一个 F# 拥护者不喜欢这个消息（F# 并不是要取代 C#）... ;p
@kunjan kshetri：这是一个“软弱”的问题，会引起争论，而且没有“正确”的答案。通常这类问题属于programmers.stackexchange.com
抱歉各位，投票重新开放。

标签： c# oop f# functional-programming

【解决方案1】：

好问题。我想说，开发人员、经理和客户方面存在零语言原因和许多不幸的技能、能力和态度原因。

【讨论】：

【解决方案2】：

您可能需要三思而后行将其用于操作系统内核开发或低级嵌入式系统:-)

【讨论】：

我的意思是嵌入在低级别的东西中，您不希望隐藏成本，例如虚拟机或您无法控制的方法。换句话说，非常适合 asm 或 C 的东西。
@harpo - 我要争辩的一点是，没有什么比使用过程或 OO 语言的好处更能阻止函数式语言与硬件交互。
再深入一点，我认为功能性想法比程序或 OO 想法更好地转化为硬件设计。
@paxdiablo - 除了 RabbitCore（它是64k，没有链接器），我的许多实现都可以使用功能样式更清洁。我认为 C 的选择取决于开发人员的惯性和经验。
@Ritch：虽然功能思想可能适用于（并行）逻辑电路的设计，但这与适用于硬件-软件接口的效果不同。大多数外围设备都是高度有状态的，您需要一种顺序方法来使用它们，它映射到一种比函数式语言更好的命令式语言。 OTOH F# 不是纯粹的函数式语言。

【解决方案3】：

Web 应用程序中的框架，例如ASP.NET MVC 更适合 C#。 “绝对没有意义”是一个极端，我会说“在正常情况下”。

当然，它可以用于 Web 应用程序引用的库，但不能用于实际应用程序本身。

【讨论】：

为什么像 ASP.NET MVC 这样的框架更适合 C#？现在，这只是你的说法，我不明白你背后的原因......
将 F# 用于 Web 应用程序是有意义的。例如，请参阅 Webshaper。

【解决方案4】：

我的看法是，替换像 C# 这样丰富而成熟的语言会非常昂贵。因此，例如，目前，如果使用 Visual Studio WinForms 设计器可以为您提供优势，C# 绝对是 WinForms 开发的最佳选择：F# 没有 WinForms 设计器。

C# 目前也有更好的 LINQ-to-SQL 支持。我敢肯定还有很多其他类似的例子。

然后，需要整个 C# 熟练劳动力将他们的技能更新到 F#，同时保留 C# 技能以维护应用程序，这又是昂贵的。

最后，C# 是一门出色的语言，具有许多出色的特性，一些 F# 甚至没有像 co/contra 变体泛型和针对 DLR 的动态编程的开箱即用支持（F# 只是有一个未实现的运算符） .

因此，通过不期望 F# 取代 C#，F# 可以以新的方式发展，而不是把所有的时间都花在已经很好覆盖的领域追赶上。

【讨论】：

我认为最后一部分是一个非常好的观点。这是一篇写得很好的帖子。赞一个！
“C# 5.0 的异步功能将比 F# 更适合 GUI 编程”。你能详细说明一下吗？当你在做的时候，你能解释一下在没有尾调用消除的情况下这将如何在 C# 中工作吗？我在 F# 中的异步代码似乎总是依赖尾调用，如果没有它们，那将是一个真正的 PITA...
嗨@Jon - 我继续删除了关于 C# 5.0 的异步功能比 F# 更适合 GUI 编程的评论：更多地研究它，我相信这是我的错误印象由于 Anders 在他的 PDC 演示文稿中给予的强调，与典型的 F# async 介绍性示例相比（我没有任何实践经验，但 F# async 通过进一步阅读看起来至少有能力）。
感谢大家的客气话和慷慨的支持。顺便说一句，我想表达的是，我个人发现 F# 在许多领域（选项类型、不变性、尾调用优化、嵌套函数、现在的异步、代码引用、模式匹配、活动模式）比 C# 更高效和更令人满意、序列表达式、自定义计算表达式、Hindley-Milner 类型推断、结构类型、结构比较、一等元组……），并且希望看到该语言得到广泛采用。

【解决方案5】：

好吧，冒着明显的风险，F# 首先是一种函数式编程语言，而 F# 中的 OOP 编程可能会让人头疼。因此，如果您正在处理最能用 OOP 表达的问题，我想使用 C# 确实更有意义。

相互递归的类型和接口的显式实现是我想到的第一个例子，为什么 F# 中的 OOP 会很麻烦。

一个（经常被引用的）“最能用 OOP 表达的问题”的例子是创建一个 UI 库。你有很多小部件，它们封装了它们自己的状态，你想要求它们做一些事情，比如多态地“画你自己”（这甚至是一个词吗？）

【讨论】：

“所以，如果你正在处理一个最适合用 OOP 表达的问题”你能扩展一下这个陈述吗？
@kunjan 好吧，例如看所谓的"expression problem"。 F# 和 C# 都无法解决它。如果您的类型层次结构实现了一组定义明确的函数，并且您希望在创建新子类型时比创建适用于所有类型的新函数时更灵活，那么 C# 将成为比 F# 更好的工具。
另一方面，一旦您尝试在 F# 中使用隐式构造函数语法，在 C# 中编写构造函数并将构造函数的参数分配给字段是一件非常痛苦的事情...
@Tomas 我确实喜欢 F# 方式（非）编写构造函数。我只是想指出，虽然其他语言（如 scala）正在推动它们的 OOP 和功能方面的界限，但今天的 F# 恕我直言，这是一种旨在编写功能代码并与主要交互的语言面向 OOP 的框架（按此顺序）。用 F# 编写纯 OOP 代码几乎就像用 C# 编写纯函数式代码一样，可能但不是这两种语言的亮点；所以我的意思是，如果你要编写 OOP，C# 可能是比 F# 更好的选择。
@Tomas 顺便说一句，我的大部分 F# 都是从你和 Matthew Podwysocki 那里学来的（间接地......阅读你写的东西）所以我完全知道我在讨论谁在这里。

【解决方案6】：

这是一个棘手的问题，因为它不是很合格。您是在谈论一般语言，还是在谈论该语言以及当前的 IDE 支持？或者你在谈论使用 F# 给定可用的库？

通用语言 - 我不认为在某些领域使用 F# 是绝对的废话。这对于完全托管的操作系统（例如 Singularity）的系统编程非常有用，我认为功能程序更容易正式验证（这对操作系统来说可能很重要）。对于低级嵌入式系统，您可以使用元编程和面向语言的工具（例如，在硬件中对信号流进行建模等）
当前 IDE 的语言 - 当前的 F# IDE 有一些限制 - 它不适用于 WinForms 设计器（但它适用于 Blend 和 WPF）。
受过开发人员教育的语言 - 雇用 F# 程序员比雇用 C# 程序员更难。如果您正在创建一些没有任何复杂核心的应用程序（例如，通常的“数据库接口”），那么用 C# 开发它会更便宜（如果您可以聘请优秀的 F# 开发人员，他们可能会更快地完成它并且花费更少错误，但它可能不值得付出代价）。
语言给定的库可用 - 如果您想限制自己使用 F#，只使用与它配合良好的库，那么域会缩小一点。例如，LINQ to SQL 和 ASP.NET MVC 可以与 F# 一起使用，但并不完美。但是，对于许多项目来说，开发自己的库是有意义的，然后 F# 就成为了很好的语言。

【讨论】：

网络上是否有文献讨论在 F# 中使用 LINQ to SQL 的缺点？翻译不完美是一个遗憾。你知道有什么改善这方面的努力吗？
FWIW，我最近与几位数据库专家交谈（这不是我的职权范围），他们都说 LINQ to SQL 很糟糕，无论如何都不应该使用。
另外，我想回应 Tomas 在这里所说的关于 F# 和 WPF 的内容。多年来，我一直在用 F# 开发商业 WPF 应用程序，发现它确实运行良好。我最近在伦敦遇到了一个由十几个人组成的团队，他们使用大量 F# 开发更复杂的 LOB WPF GUI，并且非常喜欢它。出于某种原因，很多人说 F# 和 GUI 不能混合，但他们错了。
@Jon - FWIW，过去一个月左右我一直在使用 LINQ to SQL，这真的很开心。在过去，我曾大量使用原始 ADO、原始 ADO.NET、原始 JDBC、Grails / Hibernate、iBatis 和自定义 ORM；任何一天，我都会选择 LINQ to SQL。它非常优雅，在设计器界面上拖放表并针对生成的对象映射编写静态检查的 C# LINQ 查询，这比使用原始 SQL 或 Hibernate 等怪物更简单。这是一个真正的生产力提升。我想知道那些数据库大师会建议什么替代方案
@StephenSwensen 1. 我喜欢取消引用-谢谢！ 2. 重新使用 LINQ to SQL cmets - 很多 L2S 投诉都是关于它的 - 查询处理和优化是 V1 工作，没有涵盖许多非常常见的情况 - 如果 expr 遍历，您比任何人都知道impl 是不完整的，你会被淹没（V0.9 impl 将是不完整的！）。它没有被开发，只是比 EF 更简单并不能使它变得可行。我没有将 EF 与 FS 一起使用，也没有做过很多 EF，但在不止一种情况下，我从来没有像使用 L2S 那样被简单地打过。

【解决方案7】：

Microsoft 的许多 UI 技术（例如 WPF）都对数据绑定提供了出色的支持。有效的数据绑定使用双向绑定在用户与 UI 交互时更新底层对象。这意味着有效的数据绑定需要可变对象。

F#，强调不可变类型，与这种类型的数据绑定模型的匹配度非常差。虽然可以在 F# 中创建可变类型，但这样做会消除该语言的许多优点。使用可变性更自然的语言（例如 C#）更有意义。

【讨论】：

确实，编写 UI 是不变性的主要表现之一。
-1：鉴于没有任何具体的例子，我只是不买这个。我在 F# 中使用 WPF 开发商业 GUI 应用程序时没有遇到任何此类问题，您关于可变数据结构的陈述的一个明显反例是 F# 具有可变数组文字的语法 ([|1;2;3|]) 而 C# 没有！跨度>
没有理由不能用可变的方式实现 INotifyPropertyChanged，或者传递已转换的状态对象。
我认为这属于缺乏好的 F# 库。 F# 在概念级别强调不变性，但您可以将不变性用作一种实现技术。我可以想象一个功能完善的声明性库，用于指定以功能/不可变方式使用的双向数据绑定，但在幕后完成所有令人讨厌的可变 WPF 内容（想象一下 Event.map 和 Event.merge 或 Rx以某种巧妙的方式扩展的框架以编写双向计算）。

【解决方案8】：

如果您愿意放弃特定于 C# 的工具，并支付任何适用的采用成本，那么 F# 在任何特定领域都至少不及 C#。

【讨论】：

你可以对打孔卡说同样的话，但没有人再使用它们了。为什么会这样？
@oɔɯǝɹ 这听起来比“F# 在所有方面都比 C# 更好，WYSIWYG 更适合娘娘腔”

【解决方案9】：

在 Visual Studio（ASP.NET、WebForms、WPF 等）和第三方工具完全支持 f# 之前，f# 将始终是二等公民。

让我们面对现实吧，与可靠的库（.NET，c# 和 f# 都可用 - 在这里都没有优势）、IDE（智能感知、语法着色、等），（据我所知，仅对 f# 提供部分支持...例如不支持 Razor）和第三方工具（例如 resharper）。

因此，考虑到这一点，我认为在所有这些工具都适用于 f# 之前，我认为没有人可以推荐完全替换 c#。一个很好的折衷方案是在类库中使用 f#，在前端继续使用 c#。

【讨论】：

相关问题：