When do you choose functional programming over object oriented?
When you anticipate a different kind of software evolution:
Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
When evolution goes the wrong way, you have problems:
Adding a new operation to an object-oriented program may require editing many class definitions to add a new method.
Adding a new kind of thing to a functional program may require editing many function definitions to add a new case.
This problem has been well known for many years; in 1998, Phil Wadler dubbed it the "expression problem". Although some researchers think that the expression problem can be addressed with such language features as mixins, a widely accepted solution has yet to hit the mainstream.
What are the typical problem definitions where functional programming is a better choice?
Functional languages excel at manipulating symbolic data in tree form. A favorite example is compilers, where source and intermediate languages change seldom (mostly the same things), but compiler writers are always adding new translations and code improvements or optimizations (new operations on things). Compilation and translation more generally are "killer apps" for functional languages.
You don't necessarily have to choose between the two paradigms. You can write software with an OO architecture using many functional concepts. FP and OOP are orthogonal in nature.
Take for example C#. You could say it's mostly OOP, but there are many FP concepts and constructs. If you consider Linq, the most important constructs that permit Linq to exist are functional in nature: lambda expressions.
Another example, F#. You could say it's mostly FP, but there are many OOP concepts and constructs available. You can define classes, abstract classes, interfaces, deal with inheritance. You can even use mutability when it makes your code clearer or when it dramatically increases performance.
Many modern languages are multi-paradigm.
Recommended readings
As I'm in the same boat (OOP background, learning FP), I'd suggest you some readings I've really appreciated:
Real-World Functional Programming, by Tomas Petricek. A great book that deals mainly with FP concepts, trying to explain what they are, when they should be used. There are many examples in both F# and C#. Also, Petricek's blog is a great source of information.
a crude means of sharing implementation between classes (implementation inheritance)
Functional Programming, in Haskell or even in Scala, can allow substitution through more general mechanism of type classes. Mutable internal state is either discouraged or forbidden. Encapsulation of internal representation can also be achieved. See Haskell vs OOP for a good comparison.
Norman's assertion that "Adding a new kind of thing to a functional program may require editing many function definitions to add a new case." depends on how well the functional code has employed type classes. If Pattern Matching on a particular Abstract Data Type is spread throughout a codebase, you will indeed suffer from this problem, but it is perhaps a poor design to start with.
EDITED Removed reference to implicit conversions when discussing type classes. In Scala, type classes are encoded with implicit parameters, not conversions, although implicit conversions are another means to acheiving substitution of compatible types.
在多范式语言中，如果可变状态的存在必须是实现细节，那么您可能希望对某些事物进行功能建模，因此 FP 是问题域的一个很好的模型。例如，请参阅 Python 中的列表推导式或 D 编程语言中的 std.range 。这些受到函数式编程的启发。
If you're in a heavily concurrent environment, then pure functional programming is useful. The lack of mutable state makes concurrency almost trivial. See Erlang.
In a multiparadigm language, you may want to model some things functionally if the existence of mutable state is must an implementation detail, and thus FP is a good model for the problem domain. For example, see list comprehensions in Python or std.range in the D programming language. These are inspired by functional programming.
发布评论
评论（4）
当您预期不同类型的软件发展时：
当您对事物有一组固定的操作时，并且随着代码的发展，面向对象的语言就很好，你主要添加新东西。这可以通过添加实现现有方法的新类来完成，并且现有类保持不变。
当您拥有一组固定的事物时，函数式语言就很好，并且随着代码的发展，您主要是在现有事物上添加新的操作。这可以通过添加使用现有数据类型进行计算的新函数来实现，并且现有函数保持不变。
当进化方向错误时，就会遇到问题：
向面向对象程序添加新操作可能需要编辑许多类定义才能添加新方法。
向功能程序添加新类型可能需要编辑许多函数定义以添加新案例。
这个问题多年来一直是众所周知的； 1998 年，Phil Wadler 将其称为“表达问题” 。尽管一些研究人员认为表达问题可以通过 mixin 等语言特性来解决，但广泛接受的解决方案尚未成为主流。
函数式语言擅长以树形式操作符号数据。最喜欢的例子是编译器，其中源语言和中间语言很少改变（大部分是相同的事物），但编译器编写者总是添加新的翻译和代码改进或优化（对事物的新操作）。一般来说，编译和翻译是函数式语言的“杀手级应用程序”。
When you anticipate a different kind of software evolution:
Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
When evolution goes the wrong way, you have problems:
Adding a new operation to an object-oriented program may require editing many class definitions to add a new method.
Adding a new kind of thing to a functional program may require editing many function definitions to add a new case.
This problem has been well known for many years; in 1998, Phil Wadler dubbed it the "expression problem". Although some researchers think that the expression problem can be addressed with such language features as mixins, a widely accepted solution has yet to hit the mainstream.
Functional languages excel at manipulating symbolic data in tree form. A favorite example is compilers, where source and intermediate languages change seldom (mostly the same things), but compiler writers are always adding new translations and code improvements or optimizations (new operations on things). Compilation and translation more generally are "killer apps" for functional languages.
您不一定必须在两种范式之间进行选择。您可以使用许多功能概念来编写具有 OO 架构的软件。 FP 和 OOP 本质上是正交的。
以 C# 为例。你可以说它主要是 OOP，但也有很多 FP 概念和构造。如果您考虑 Linq，那么允许 Linq 存在的最重要的构造本质上是函数式的：lambda 表达式。
另一个例子，F#。您可以说它主要是 FP，但也有许多可用的 OOP 概念和构造。您可以定义类、抽象类、接口、处理继承。当可变性使代码更清晰或显着提高性能时，您甚至可以使用可变性。
许多现代语言都是多范式的。
推荐读物
由于我处于同一条船上（OOP 背景，学习 FP），我建议您阅读一些我非常欣赏的读物：
日常 .NET 开发的函数式编程，作者：Jeremy Miller。一篇很棒的文章（尽管格式很差），展示了 C# 上 FP 的许多技术和实际的、真实的示例。
现实世界函数式编程，作者：Tomas Petricek。一本很棒的书，主要讨论 FP 概念，试图解释它们是什么以及何时使用它们。 F# 和 C# 中都有很多示例。此外，Petricek 的博客 也是一个很好的信息来源。
You don't necessarily have to choose between the two paradigms. You can write software with an OO architecture using many functional concepts. FP and OOP are orthogonal in nature.
Take for example C#. You could say it's mostly OOP, but there are many FP concepts and constructs. If you consider Linq, the most important constructs that permit Linq to exist are functional in nature: lambda expressions.
Another example, F#. You could say it's mostly FP, but there are many OOP concepts and constructs available. You can define classes, abstract classes, interfaces, deal with inheritance. You can even use mutability when it makes your code clearer or when it dramatically increases performance.
Many modern languages are multi-paradigm.
Recommended readings
As I'm in the same boat (OOP background, learning FP), I'd suggest you some readings I've really appreciated:
Functional Programming for Everyday .NET Development, by Jeremy Miller. A great article (although poorly formatted) showing many techniques and practical, real-world examples of FP on C#.
Real-World Functional Programming, by Tomas Petricek. A great book that deals mainly with FP concepts, trying to explain what they are, when they should be used. There are many examples in both F# and C#. Also, Petricek's blog is a great source of information.
面向对象编程提供：
函数式编程，在 Haskell 甚至 Scala 中，可以允许通过更通用的类型类机制进行替换。不鼓励或禁止可变的内部状态。还可以实现内部表示的封装。请参阅 Haskell 与 OOP 进行详细比较。
诺曼的断言是“向函数式程序添加一种新的事物可能需要编辑许多函数定义来添加新的情况”。取决于函数代码使用类型类的程度。如果特定抽象数据类型上的模式匹配遍布整个代码库，您确实会遇到这个问题，但这可能是一个糟糕的设计。
已编辑在讨论类型类时删除了对隐式转换的引用。在 Scala 中，类型类使用隐式参数而不是转换进行编码，尽管隐式转换是实现兼容类型替换的另一种方法。
Object Oriented Programming offers:
Functional Programming, in Haskell or even in Scala, can allow substitution through more general mechanism of type classes. Mutable internal state is either discouraged or forbidden. Encapsulation of internal representation can also be achieved. See Haskell vs OOP for a good comparison.
Norman's assertion that "Adding a new kind of thing to a functional program may require editing many function definitions to add a new case." depends on how well the functional code has employed type classes. If Pattern Matching on a particular Abstract Data Type is spread throughout a codebase, you will indeed suffer from this problem, but it is perhaps a poor design to start with.
EDITED Removed reference to implicit conversions when discussing type classes. In Scala, type classes are encoded with implicit parameters, not conversions, although implicit conversions are another means to acheiving substitution of compatible types.
如果您处于高度并发的环境中，那么纯函数式编程很有用。缺乏可变状态使得并发变得几乎微不足道。请参阅 Erlang。
在多范式语言中，如果可变状态的存在必须是实现细节，那么您可能希望对某些事物进行功能建模，因此 FP 是问题域的一个很好的模型。例如，请参阅 Python 中的列表推导式或 D 编程语言中的 std.range 。这些受到函数式编程的启发。
If you're in a heavily concurrent environment, then pure functional programming is useful. The lack of mutable state makes concurrency almost trivial. See Erlang.
In a multiparadigm language, you may want to model some things functionally if the existence of mutable state is must an implementation detail, and thus FP is a good model for the problem domain. For example, see list comprehensions in Python or std.range in the D programming language. These are inspired by functional programming.