最近，我听到了很多关于函数式编程语言（例如 F#）的好消息。此外[和不相关]，我还注意到 MVC 开始获得大量曝光——也许是自从 Silverlight/WPF 引入以来。
我从来没有在没有先做研究的情况下加入潮流——事实上，我花了一点时间才飞跃到 .NET。有人刚刚在我之前的一个关于早期采用新技术的问题中发表了评论，这让我停下来思考。
我一直在努力寻找时间来学习 WPF，但现在我开始怀疑这是否是要走的路。诸如 F# 之类的语言和 MVC 编程模型会继续存在还是只是下一个时尚？还是人们真的认为这些是 C#/VB 和 OOP 的潜在替代品？
我的大部分开发都是在内部应用程序上进行的，要么以丰富的 Web 应用程序的形式部署在 Intranet 上，要么以 Winforms 实用程序应用程序的形式分发到各个机器上。到目前为止，我选择的技术非常标准——T-SQL/PL*SQL、C#/VB、JavaScript/AJAX、CSS。
我想我正在努力确定的是，在不久的将来，在我的工具箱中使用这些技术的哪种组合最有效率/最有用？
两者都不是时尚，也不会很快消失，但实际上我只希望看到大多数 .NET 开发人员经常使用这两者中的一个......
F# 和 ASP.NET MVC 之间有很大的不同；F# 是一种函数式语言 - 这在一些场景中具有许多优势，但对于大多数业务线编程而言，通用语言（如 C#）通常更有用。然而，从了解编程的函数式风格（尤其是不可变性）中可以获得很多东西。我查看了 F#，希望它能改进我的 C#，即使我从未用 F# 编写过任何生产代码。幸运的是，由于委托和 lambda，C# 可以以函数方式使用，即使它不是正式的 FP。
然而，ASP.NET MVC 是一个非常不同的野兽。MVC（更一般地说）是一种已知、已建立且受信任的模式，它：
或者换一种说法：对很多人来说，它让 ASP.NET 终于变得有意义了；我完全期望在来年大量使用 ASP.NET MVC。
我觉得把函数式编程和 MVC 混在一个问题上很奇怪。我发现他们没有任何关系，除了他们都超过 30 岁并且在他们的社区中非常成熟。因为我对函数式编程有所了解，所以我会谈谈。
函数式编程已经有将近 50 年的历史了，而且还会继续存在，尽管它是否会成为主流尚不清楚。显而易见的是，函数式语言已经充当了孵化器，然后为最终进入主流语言的特性提供了试验场。一些例子：
从长远来看，在您的工具箱中拥有功能技术将使您成为更好的程序员。或者正如 Eric Raymond 所说，学习 Lisp。（Lisp 和 Haskell 都充满了强大的新想法，它们会让你的头脑以不同的、无与伦比的但有用的方式爆炸。F# 更多的是结合了函数式语言中经过验证的最佳想法，并与 .NET 框架相结合。在2009 年初，它似乎最有可能成为主流。）
这些天我在 SO 上看到了很多这样的事情。（见这里、这里和这里的几个例子。）
根据 Wikipedia的说法，Lisp 是当今仍在使用的第二古老的编程语言（被 Fortran 击败）。函数式编程并不比晶体管、鼠标、计算机显示器、硬盘驱动器，或者实际上是个人计算机的概念更流行，在 Lisp 于 1958 年成立时，这些都没有出现。编程在典型的商业环境中可能不是特别有用，但它的流行程度的起伏不会使它成为一种时尚，也不会使它成为一种玩具。对计算科学有敏锐理解的程序员明白，函数式编程与其说是一项发明，不如说是一种发现——对计算基本性质的深刻洞察。
更重要的是，如果编程是您的日常工作（而不是真正的激情），那么 F# 是在浪费您的时间吗？它可能是，从某种意义上说，它不太可能变得流行到足以保证包括在你的简历中。还值得注意的是，如果您确实花时间学习 F#，但您的同事都无法理解您的工作，那么选择它作为开发工具可能弊大于利。这仍然不会使它成为“时尚”。:)
至于 MVC，它已经存在了很长时间——可能已经有十多年了，但我一直没有跟踪。它不是灵丹妙药，也不难把握；这只是另一种发展模式。值得关注的是，MVC 不是标准，甚至不是非常明确的技术。有许多不同的方式来解释 MVC，我什至敢说，有不止一种正确的方式来做。
MVC 恰好对 Web 开发特别有用，因为 Web 应用程序往往具有非常混乱的前端代码（支持所有这些不同的浏览器是一件非常痛苦的事情），而您最不想要的就是让您的业务逻辑陷入前端- 不必要地结束。与 F# 不同，即使编程严格来说只是您的日常工作，学习 MVC 也不是浪费时间，因为如果您发现自己正在开发 Web 应用程序，那么遵守 MVC（即使只是松散地遵守）可以节省您的时间来自职业的尴尬。
至于 MVC，它是在 1979 年推出的。我记得在 1988/89 年的时间框架内，我在 Aldus Persuasion for Windows（Powerpoint 的一次竞争对手）的职业生涯中第一次实现了它。MVC 框架在 RIA 应用程序中风靡一时，例如基于 Adobe Flex 的 Web 编程（Cairngorm、Mate、PureMVC 等）。
在我的公司，我们的第一个 Flex 应用程序不是作为 MVC 完成的，但是我们对模型有多个视图。一定是一团糟。我们重构为 MVC，开发人员的生活变得更好了。
据我所知，只有那些试图通过各种 Web 框架在服务器端实现 MVC 的人，才是抱怨 MVC 的人。分布式计算的谬误会告诉他们，在表示渲染层被网络连接的鸿沟隔开的情况下执行 MVC 是一个坏主意。分布式 MVC 和分布式对象一样糟糕。
使用 RIA Web 应用程序，例如基于 Flex 的应用程序，MVC 完全在客户端完成 - 就像它在 79 年在 Smalltalk 图形工作站中引入的一样。然后，RIA 客户端仅使用异步服务调用和/或消息传递与服务器端进行通信。
对于一个除了抛出一个单一的 CRUD 表单什么都不做的应用程序，那么是的，MVC 可能是矫枉过正。但是对于具有相当复杂性的富 GUI 应用程序，MVC 仍然是一种非常明智的采用模式。
函数式语言在开发代码中的实际使用完全取决于您编码的领域。如其他答案所述，对于经典的“业务线”应用程序，如果您已经了解 C#，那么您不太可能很快切换到 F#。
然而：
一点也不。
函数式编程语言已经存在了几十年。
作为“MVC”的编程模型实际上是一种设计模式，并且现在有很多框架使用它。
可能这里唯一的新事物是您的观点。在它们来到 MS 世界之前，您不知道它们的存在或它们被广泛使用。
我的第一份工作是在 2000 年使用Apple comp 的WebObjects Framework。使用它进行开发非常容易。
函数式编程作为一种范式具有许多优点：它提供了许多与面向对象设计在小型团队中工作时相同的优点（数据封装、多态性、代码可移植性......）数据的不变性和无状态的性质。穿线更容易。
我不会谈论 MVC 在 Web 应用程序中的可行性……对于我们这些开发框架的人来说，这些框架已经勾勒出清晰的模式——这只是给同一只猫换皮的另一种方式。我从来没有为 ASP.NET 的整体情况苦恼过，因此认为 MVC 以某种方式使其更简单通常是用词不当。它可能对一种方法有用，但并非对所有方法都有用 - 因此落入工具箱中的另一个工具。
我们需要的真的是另一种工具吗？
我确信 C# 和 VB 将永远存在……但也会有很多人走在新技术的边缘。他们将能够用更少的代码做更多的事情，而你将能够用你已经拥有的代码做更多的事情。所以不要担心这将是一场公平的战斗。
即使......学习更多的东西会让你更好地编程，所以......这取决于你！
我要说的是，关于学习更多语言如何很好地了解每种语言的能力，然后使用所有这些信息来编写更好的代码，有很多模糊不清的地方。但如果你花同样的时间支配一门语言，你会没事的。
从我对函数式语言的（非常）基本知识来看——它们可能在我们未来的开发人员中占有很高的地位。许多聪明人评论说，由于处理器没有变得越来越快，因此需要使用更多的内核。因此并行编程将变得更加主流。函数式语言适用于并行任务，因为它们不维护状态（有效地消除了与并行编程/线程相关的大多数常见问题，例如锁等）。
有关此特定点的更多信息，我想引导您阅读这篇讨论可变/不可变数据并比较 c# 和 f# 代码片段的文章。