Why are there problems with object-oriented programming and functional programming?

In short, whether it is object-oriented programming or functional programming, if you go to extremes, it is wrong. The extreme of object-oriented programming is that everything is an object (pure object-oriented). The extreme of functional programming is pure functional programming language.

Problems of object-oriented programming

The problem of object-oriented lies in its definition of "object", which tries to incorporate everything into this concept. After this practice is extreme, you have to come up with an idea that everything is an object. But this idea is wrong, because

Some things are not objects. Function is not an object.

You might think that in Python and Scala languages, functions are also objects. In Python, all objects containing methods named __call__ are actually functions. Similarly, in Scala, the function has an object called the apply method. However, after careful consideration, you will find that it confuses the concepts of origin and derivative. The function is the source ancestor, and the object containing the function is actually a derived object. __call__ and apply themselves are the so-called "function objects" to be defined first. Python and Scala actually kidnapped functions, imprisoned them in "objects", and then marked them as "__call__" and "apply" and called them "methods". Of course, if a function is encapsulated as an object, you can use the object just like a function, but this does not mean that you can say that "a function is also an object".

Most object-oriented languages lack the correct mechanism to realize first-class functions. The Java language is an extreme, and it completely forbids passing functions as data. You can encapsulate all the functions into objects and call them "methods", but as I said, this is kidnapping. The lack of first-class functions is the main reason why there are so many "design patterns" in Java. Once you have first-class functions, you will no longer need most of these design patterns.

Problems of functional programming

Similarly, after functional programming goes to extremes and becomes a pure functional programming language, it is also problematic. In order to discuss this problem, we'd better first understand what a purely functional programming language is. For this reason, you may need to read what is a purely functional language by Mr Amr Sabry, my doctoral supervisor. To sum up, purely functional programming languages are wrong because

Some things are not pure. Side effects are real.

The so-called pure function basically ignores the characteristics of the material basis (silicon wafer, crystal, etc.). ). Pure functional programming languages try to re-realize the whole universe through functions-in and out of the whole universe through functions. But there is a difference between physics and simulation. The "side effects" are physical. They really exist in nature and play an indispensable role in realizing the practicability of computers. Simulating them with pure functions is doomed to be inefficient, complicated and even ugly. Do you think it is easy to realize ring data structure or random number generator in C language? But using Haskell language is not the case.

Moreover, purely functional programming languages will bring huge cognitive costs. If you study them deeply, you will find that monads make the program complicated and difficult to write, and the variants of monads are poorly modified. Monads and Java's "design pattern" have the same spiritual essence. Using monad to represent side effects is like writing an interpreter in visitor mode. Have you found that many simple things in other languages, put into Haskell language, have become the subject of studying how to realize them? Do you often see some papers titled "Solving the Solved Problems with a Unitary Method"? Interestingly, Mr Amr Sabry co-authored such a paper. He tried to re-implement Dan Friedman's miniKanren in Haskell language, but he didn't know how to construct these lists. He asked Oleg Kiselyov, who is considered to be the person who knows Haskell type system best in the world. You may not know that Mr Amr Sabry should be the person who knows the pure functional programming language best in the world. After solving the problem with Oleg's help, they wrote this paper together. Ironically, Dan Friedman, the original author of this program, did not encounter any problems when developing it in Scheme language. I re-implemented miniKanren based on Dan's code and added a complex negative operation. To achieve this, I need to use constraint logic programming and other advanced skills. Given that rewriting the basic miniKanren in Haskell language stumped two world-class programmers, I can't imagine how to achieve this by using Haskell's list.

Some people think that the value of single bacteria is that they "delimit" the scope of side effects. But what's the use of this "demarcation" if the list can't really make the program easier to analyze or safer? It just doesn't work. It is as difficult to analyze and understand as side effects. There is nothing to say that a list can make it simple but static analysis can't. All static analysis researchers know this. Static analysis makes use of the essence of monads, but it reduces the burden on programmers to write monads-rather than increasing the burden. Of course, too many side effects will make the program difficult to analyze, but you can also write pure functions in C language, such as:

int f（int x ）{

int y = 0；

int z = 0；

y = 2 * x；

z = y+ 1；

Return to z/3;

}

You can also use assembly language to realize it. Pure function does not exclude pure functional programming languages. You can write pure functions in any language, but it is important that you must and should allow side effects.

Looking back at history, you will find that mathematical idealism is the driving force of purely functional programming languages. Mathematical functions are simple and beautiful, but unfortunately, they are only useful when building primitive and pure models. Otherwise, they will become ugly. Don't be intimidated by slogans such as "Category Theory". I know a lot about category theory. Even category theorists themselves call them "abstract nonsense" because they basically tell you something you already know in a weird way! If you have read Gottlob Frege's article Functions and Concepts, you will be surprised to find that before his paper was published, most mathematicians misunderstood functions, which only happened 100 years ago. In fact, many things in mathematical language are problematic. Especially calculus. Designers of programming languages have no reason to study mathematics blindly.

Don't fall in love with your model blindly.

It is harmful to go to extremes in everything. In extreme cases, both object-oriented programming and functional programming try to integrate the whole world into their unique models, but the operation of the world is completely independent of our brain thinking. If you think you have a hammer, it is obviously wrong to treat everything as a nail. Only by recognizing our real world clearly can we get rid of the shackles of faith.

Don't adapt the world to your model. Adapt your model to the world.