F＃在“使用绝对没有意义”的地方？

Don Syme在他的SPLASH演讲中表示，F＃不是为了替代C＃，即使它具有一般的function。他继续说，有些地方F＃在使用上没有意义，但没有扩大论文。

在哪些地方使用F＃比C＃更合适？

我的意思是，将C＃代替语言和C＃一样成熟和丰富的代码将非常昂贵 。因此，例如，目前，如果使用Visual Studio WinFormsdevise器可以给你一个优点，C＃绝对是WinForms开发的最佳select：F＃没有WinFormsdevise器。

C＃目前也有更好的LINQ-to-SQL支持。我敢肯定，沿着这些路线还有很多其他的例子。

然后，要求整个C＃熟练的员工将自己的技能更新到F＃，同时保持C＃维护应用程序的技能，而且价格昂贵。

最后，C＃是一个非常优秀的语言，有很多很棒的function，有些F＃甚至没有类似于合/对变体的generics，也没有支持对DLR进行dynamic编程（F＃只是一个未实现的运算符）。

所以通过不希望F＃取代C＃，F＃可以以新的方式发展，而不是花时间在已经被覆盖的领域追赶。

这是一个棘手的问题，因为它不是很合格。你是在谈论一般的语言，还是你正在谈论与当前的IDE支持的语言？或者你是否在谈论使用F＃提供的库可用？

一般的语言 – 我不认为有一些地方使用F＃将是绝对的废话。对于完全托pipe的操作系统（例如奇点）的系统编程将是一件好事，我认为function程序将更容易正式validation（这对OS来说可能是一个大问题）。对于低级embedded式系统，您可以使用元编程和面向语言的设施（例如在硬件中对信号stream进行build模等）
使用当前IDE的语言 – 当前的F＃IDE有一些限制 – 它不适用于WinFormsdevise器（但它适用于Blend和WPF）。
开发人员教育的语言 – 雇用F＃程序员比聘用C＃程序员更困难。如果你正在创build一个没有任何复杂内核的应用程序（例如，通常的“数据库接口”），那么用C＃开发它将会更便宜（如果你可以雇佣好的F＃开发者，他们可能会更快，错误，但可能不值得）。
给定库的语言可用 – 如果你想限制自己只使用F＃，只使用适合它的库，那么域会缩小一点。例如，LINQ to SQL和ASP.NET MVC可以和F＃一起使用，但并不完美。但是，对于许多项目来说，开发自己的库是很有意义的，然后F＃就成为了一个很好的语言。

好问题。我想说的是，开发者，pipe理者和顾客都没有语言的原因，许多不幸的技能，能力和态度的原因。

许多微软的UI技术，如WPF，对数据绑定都有很好的支持。有效的数据绑定使用双向绑定在用户与UI交互时更新底层对象。这意味着有效的数据绑定需要可变对象 。

F＃ 强调的是不可变的types ，这种types的数据绑定模型相当差劲。尽pipe可以在F＃中创build可变types，但这样做会从语言中移除很多好处。使用可变性更自然的语言（比如C＃）就更好了。

您可能要考虑将其用于操作系统内核开发或低级embedded式系统:-)

如果你愿意放弃特定于C＃的工具，并且支付适用的任何成本费用，那么F＃就不会像C＃那样具有至less能力。

Web应用程序，其中框架如ASP.NET MVC使自己更好的C＃。 “绝对没有意义”是一个极端，我会说“一般情况下”。

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

那么，冒着明显的风险，F＃首先是一个函数式编程语言，而F＃中的OOP编程可能是一个痛苦的枷锁。所以，如果您正在处理与OOP最佳expression的问题，我想使用C＃会更有意义。

相互recursiontypes和接口的显式实现是F＃中OOP为什么会很麻烦的第一个例子。

一个（经常被引用的）“最好用OOP表示的问题”的例子是创build一个UI库。你有很多小部件，它们封装了自己的状态，你想让它们做一些像“自己画”的多forms的东西（甚至是一个字）？

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

让我们面对它，语言的select通常不会对生产力产生太大的影响，相比于一个坚实的库（NET，可用于C＃和F＃ – 这两者都没有优势），IDE（智能感知，语法着色等），（只有部分支持f＃，据我所知…例如没有Razor支持）和第三方工具（如resharper）。

所以考虑到这一点，我不认为任何人都可以推荐完全替代C＃，直到所有这些工具都适用于F＃。一个很好的折衷办法是在类库中使用f＃并继续在前端使用c＃。