这些范式并不一定是相互排斥的。如果你看python，它支持函数和类，但同时，所有东西都是对象，包括函数。你可以在一段代码中混合和匹配函数式/oop/过程式风格。

我的意思是，在函数式语言中(至少在Haskell中，这是我唯一学习过的语言)没有语句!函数中只允许有一个表达式!!但是，函数是一等公民，你可以把它们作为参数传递，还有其他一些能力。他们可以用很少的代码做强大的事情。

而在像C这样的过程式语言中，传递函数的唯一方法是使用函数指针，仅靠这一点并不能完成许多功能强大的任务。

在python中，函数是一级公民，但它可以包含任意数量的语句。所以你可以有一个包含过程代码的函数，但你可以像函数式语言一样传递它。

OOP也是如此。像Java这样的语言不允许在类之外编写过程/函数。传递函数的唯一方法是将它包装在实现该函数的对象中，然后传递该对象。

在Python中，你没有这个限制。

它们都有各自的优点——它们只是解决相同问题的不同方法。

在纯过程式风格中，数据往往与操作它的函数高度解耦。

在面向对象的风格中，数据往往带有一组函数。

在函数式风格中，数据和函数往往彼此有更多的共同点(如在Lisp和Scheme中)，同时在函数的实际使用方面提供更大的灵活性。算法也倾向于根据递归和组合来定义，而不是循环和迭代。

当然，语言本身只影响首选哪种风格。即使在像Haskell这样的纯函数式语言中，您也可以使用过程式风格(尽管这是非常不鼓励的)，即使在像C这样的过程式语言中，您也可以使用面向对象的风格进行编程(例如在GTK+和EFL api中)。

To be clear, the "advantage" of each paradigm is simply in the modeling of your algorithms and data structures. If, for example, your algorithm involves lists and trees, a functional algorithm may be the most sensible. Or, if, for example, your data is highly structured, it may make more sense to compose it as objects if that is the native paradigm of your language - or, it could just as easily be written as a functional abstraction of monads, which is the native paradigm of languages like Haskell or ML.

您使用的选择只是对您的项目和您的语言支持的抽象更有意义。

这些范式并不一定是相互排斥的。如果你看python，它支持函数和类，但同时，所有东西都是对象，包括函数。你可以在一段代码中混合和匹配函数式/oop/过程式风格。

我的意思是，在函数式语言中(至少在Haskell中，这是我唯一学习过的语言)没有语句!函数中只允许有一个表达式!!但是，函数是一等公民，你可以把它们作为参数传递，还有其他一些能力。他们可以用很少的代码做强大的事情。

而在像C这样的过程式语言中，传递函数的唯一方法是使用函数指针，仅靠这一点并不能完成许多功能强大的任务。

在python中，函数是一级公民，但它可以包含任意数量的语句。所以你可以有一个包含过程代码的函数，但你可以像函数式语言一样传递它。

OOP也是如此。像Java这样的语言不允许在类之外编写过程/函数。传递函数的唯一方法是将它包装在实现该函数的对象中，然后传递该对象。

在Python中，你没有这个限制。

对于GUI，我想说面向对象范式非常适合。窗口是一个对象，文本框是对象，ok按钮也是对象。另一方面，像字符串处理这样的东西可以用更少的开销完成，因此用简单的过程范式更直接。

我也不认为这是语言的问题。你可以用几乎任何流行的语言编写函数式的、过程式的或面向对象的，尽管在某些语言中可能需要额外的努力。

我认为它们通常不是“相对”的，但你可以把它们结合起来。我还认为，你经常提到的词语只是流行语。很少有人真正知道“面向对象”是什么意思，即使他们是它最狂热的传播者。

我的一个朋友正在用NVIDIA CUDA写一个图形应用程序。应用程序很好地适应了面向对象的范式，并且可以将问题整齐地分解为模块。然而，要使用CUDA，你需要使用C语言，C语言不支持继承。因此，你需要聪明。

a)你设计了一个聪明的系统，在一定程度上模仿继承。是可以做到的!

i)你可以使用钩子系统，它期望父函数P的每个子函数C对函数f有一定的覆盖。你可以让子函数注册他们的覆盖，这些覆盖将被存储并在需要时调用。

ii)你可以使用结构内存对齐特性将子元素转换为父元素。

这可能很简单，但要想出经得起考验的、可靠的解决方案并不容易。您将花费大量时间设计系统，并且无法保证您不会在项目中途遇到问题。实现多重继承甚至更难，甚至几乎不可能。

b) You can use consistent naming policy and use divide and conquer approach to create a program. It won't have any inheritance but because your functions are small, easy-to-understand and consistently formatted you don't need it. The amount of code you need to write goes up, it's very hard to stay focused and not succumb to easy solutions (hacks). However, this ninja way of coding is the C way of coding. Staying in balance between low-level freedom and writing good code. Good way to achieve this is to write prototypes using a functional language. For example, Haskell is extremely good for prototyping algorithms.

我倾向于使用方法b。我使用方法a编写了一个可能的解决方案，说实话，使用该代码感觉非常不自然。