据我所知（我承认不多），目前流行的编程范式是面向对象（Java、C#、Ruby）与函数式（F#）。作为最熟悉第一范式的人，我有几个问题：
显然，没有“最好”的语言，但我想知道是否值得投入时间和精力来学习新的范式。提前致谢！
“或者换句话说，所有问题都可以归结为一把锤子的钉子吗？” 是的。时期。您可能遇到的任何编程语言都将与其他所有编程语言一样完整。实际上，编程语言的“完整性”有一个正式的定义。
“人们曾经需要学习新的范式吗？” 总是。
跟随“范式转变”的起起落落实际上有一个技巧。在我职业生涯的最后 30 年中，我看到编程已经从一个相对简单的命令式/过程模型发展为许多更丰富的模型，包括在过程和数据之间实现更好的平衡。
我注意到以下...
部分驱动力是人工智能社区。这些“新模型”中有许多是作为 AI 知识表示方案开始的。他们在那里获得了牵引力，然后他们逐渐进入了更主流的应用程序。
实体关系模型最初是用于知识表示，而不是业务交易。类似地，对象模型用于知识表示。然后模拟人发现了它。现在我们其他人拥有它。
这是我的结论。
软件是知识表示。
您对范式或模型或方法或风格的选择基于对以下问题的回答：
“我怎样才能最好地代表这个问题？”
如果问题有对象和关系，OO。如果问题有算法和转换、映射、过滤器和归约，函数式。如果问题是动态的、变化的和灵活的，动态的。如果问题是静态的并且会迅速扩大，静态。
值得学习替代范式（OO、功能、程序、动态等），因为它将帮助您以不同的方式思考问题。
例如，考虑以线性方式（我曾经做过的第一种方式）解决树遍历与使用递归的区别。或者 Google 结合 Map 和 Reduce 来帮助他们索引互联网。
应用于旧问题的新思维方式可以帮助解决一些最棘手的问题。
范式独立于语言。您可以在 C 中以 OO 风格进行开发（看看 GTK）。当我用 Java 编程时，我主要使用函数式风格。
尽可能多地了解范式是值得的。有些问题在一种范式中是微不足道的，而在另一种范式中则需要精心设计。
作为一个（简单的）示例，在此页面上比较 Java 和 Ocaml 中的快速排序实现，或者更好的是 Haskell：http ://www.rosettacode.org/rosettacode/w/index.php?title=Quicksort
（这并不意味着功能更好。OO更好地解决了一些问题）。
所有问题都可以归结为一把锤子的钉子吗？
是的。你可以用一把锤子解决问题。它只是将那扇门锯成两半需要更长的时间。
人们是否曾经需要学习新的范式？对于我过去的两份工作，我的工作场所需要 Java 和 C#。是否有专门使用非面向对象语言的工作场所？
开发人员必须每 15-20 年左右进行一次。
肯定有整个行业的小公司都拥有使用过程 VBA 编写的基于 Access 的系统。（我认为我为他们中的大多数人工作过）。经典的 ASP 开发人员必须学习 ASP.NET。Perl 开发人员正在学习 Python。批处理驱动开发让位于事件驱动开发。
我认为你会在所有方面找到答案。我工作得越多，我就越发现了解其他一些人是“有帮助的”。作为 C#/VB/SQL Server 开发人员，我发现了解 F# 和其他一些语言对我更有帮助，以便获得广泛的接触，真正找出合适的工具......
动态的东西把我吓坏了，但是 Ruby on Rails 是迄今为止我见过的最好的 web 开发系统。不过，我对将它用于一个非常大、需要大量维护的项目感到不舒服，因为它太容易改变现有、已编译、已完成代码的含义。对于一个人的编码风格来说，也太容易将其变成一种新的语言。
动态/脚本对于系统管理员和任何运行 Linux 系统的人来说也很重要。用 BASH 或 Ruby 编写一个快速的脚本比尝试在 Java 或 C++ 中实现相同的功能更胜一筹。
OO 使理解大量代码变得更加容易。如果您有一个大型团队或多个大型团队并且需要快速提供概述，那么 OO 可以更轻松地描述和隔离给定的功能。我应该说正确编码 OO！
我理解函数式对于多线程编程很有好处，因为一切都趋于不可变。
在考虑 OOP 的情况下开发设计和架构技能是出色的语言无关职业最理想的技能组合。
在 Oops 中编写代码的好处是对其他团队成员和整个组织都有好处。因为代码对所有人来说都是可以理解的，如果开发人员辞职了，公司不需要太担心。在另一种情况下，如果您遵循功能样式，其他人将很难理解您所做的事情。
正如大多数其他人所说，您通常可以使用任何语言来解决任何问题，并且您通常可以以一种范式的风格编写另一种范式。
如果您花时间学习按预期使用不同的范式，那么您确实会学习有关知识表示和解决问题的不同知识，这对您将来使用的任何范式都有帮助。
虽然范例和领域之间存在一定的一致性，但通常最好根据您的软件需要在其中运行的环境的细节来选择一种语言。