从本质上说,是的!

当一个模式绕过了缺失的特性(高阶函数、流处理……)，最终促进了组合。 一遍又一遍地重写模式实现的需要本身可以被视为一种语言气味。

此外，这个页面(AreDesignPatternsMissingLanguageFeatures)提供了一个“模式/功能”转换表和一些不错的讨论，如果你愿意深入研究的话。

当你试着从“设计模式”(一般)和“FP vs . OOP”的层面来看待这个问题时，你会发现答案最多是模糊的。

但是，在这两个轴上深入研究，并考虑特定的设计模式和特定的语言功能，事情就会变得更清楚。

因此，例如，当使用具有代数数据类型和模式匹配、闭包、第一类函数等的语言时，一些特定的模式(如访问者、策略、命令和观察者)肯定会改变或消失。不过，GoF书中的其他一些模式仍然“存在”。

总的来说，我会说，随着时间的推移，特定的模式正在被新的(或正在流行的)语言特性所淘汰。这是语言设计的自然过程;随着语言变得越来越高级，以前只能在书中使用示例来调用的抽象现在成为特定语言特性或库的应用程序。

(顺便说一句:这是我最近写的一篇博客，上面有更多关于FP和设计模式讨论的链接。)

我认为每个范式都有不同的目的，因此不能以这种方式进行比较。

我还没有听说过GoF设计模式适用于每一种语言。我听说它们适用于所有面向对象语言。如果您使用函数式编程，那么您解决的问题领域就不同于OO语言。

我不会使用函数式语言来编写用户界面，但是像c#或Java这样的面向对象语言会使这项工作更容易。如果我正在编写一种函数式语言，那么我就不会考虑使用OO设计模式。

Norvig的演示暗示了他们对所有GoF模式的分析，他们说23个模式中有16个在函数式语言中有更简单的实现，或者只是语言的一部分。因此，大概至少有7个要么是a)同样复杂，要么是b)没有出现在语言中。不幸的是，我们没有列举它们!

我认为很明显，GoF中的大多数“创造性”或“结构性”模式只是让Java或c++中的原始类型系统做你想做的事情的技巧。但是不管你用什么语言编程，其余的都是值得考虑的。

一个可能是Prototype;虽然它是JavaScript的基本概念，但它必须在其他语言中从头开始实现。

我最喜欢的模式之一是空对象模式:表示一个对象不做任何适当的事情。这可能更容易在函数式语言中建模。然而，真正的成就是视角的转变。

确实如此，因为高级函数式PL(如OCaml，带有类、模块等)在类型多功能性和表达能力方面肯定会取代OOP命令式语言。抽象不会泄露，你可以在程序中直接表达你的大部分想法。因此，是的，它确实取代了设计模式，无论如何，与功能模式相比，大多数设计模式都简单得可笑。

正如其他人所说，函数式编程有特定的模式。我认为摆脱设计模式的问题与其说是转换到功能的问题，不如说是语言特性的问题。

看看Scala是如何废除“单例模式”的:只需声明一个对象而不是一个类。 另一个特性，模式匹配，有助于避免笨重的访问者模式。对比如下: Scala的模式匹配=类固醇访问者模式

Scala和f#一样，是OO-functional的融合。我不了解f#，但它可能有这些特性。

闭包是在函数式语言中出现的，但不需要被限制在函数式语言中。它们有助于使用委托模式。

还有一个观察结果。这段代码实现了一个模式:它是如此经典，如此基本，以至于我们通常不认为它是一个“模式”，但它确实是:

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

像Java和c#这样的命令式语言已经采用了本质上是一个函数结构来处理这个问题:“foreach”。