Why object-oriented programming sucks
When I first heard about object-oriented programming, I was immediately skeptical about it. Honestly, I don't even know why. It just seemed somehow wrong to me. But the PLO very quickly became popular (why - I will explain below) and criticism of it turned into a sort of “abuse in the church.” And object-orientation has become an indispensable part of any reputable programming language.
With the increasing popularity of Erlang, they often began to ask the question “Is Erlang object-oriented?”. The correct answer would be "Yes, no, no!" But we could not say so in full voice, so we had to get out. We came up with some rather non-trivial answers that would represent Erlang of type-object-oriented language (for those who most of all draw their hands with this question), but also not object-oriented for those who are actually in the subject.
Here I would like to recall the thesis presentation by the Director of the French IBM at the 7th IEEE Conference on Logic Programming. He spoke about the fact that IBM has added quite a lot of object-oriented extensions to Prolog. When asked about the reasons for this, he answered:
I remember thinking “How nice! Simply, no remorse, no introspection, no rushing about whether to do it right. ”
')
My PERSONAL objections on the subject of OOP are claims to its main provisions. I will highlight some of these provisions and the essence of my claims.
Objects bind functions and data structures together in indivisible entities. I think this is a fundamental mistake, because functions and data structures are concepts belonging to completely different categories. Why is this so?
Because functions perform actions. They have input and output values. Input and output values ​​are data structures that are modified by functions. In many languages, functions are sequences of imperatives: “do this, then do it.” To understand the essence of a function, it is necessary to understand the order in which these imperatives are fulfilled (in lazy functional and logical languages, order may not matter).
Data structures simply exist. They do nothing. They are exclusively declarative. “Understanding” the data structure is much simpler than “understanding” a function.
Functions are represented by black boxes that transform inputs into outputs. If I understand the input and output, then I can understand the function (although this does not mean that I could write this function).
Functions are usually “understood” as parts of a computing system that transfer data from a data structure of type T1 to a data structure of type T2.
Since the functions and data structures are completely different types of animals, the decision to keep them in one “cage” is fundamentally wrong.
Consider "time." In an object-oriented programming language, “time” must be an object. But in the non-object-oriented language, “time” is an instance of a data type. For example, in Erlang there are many different types of "time", each of which can be strictly and unambiguously defined. For example, using the following type definitions:
Note that these definitions do not belong to any particular object. They are generally used without any restrictions, so such data structures representing "time" can be used by any function.
In addition, they have no related methods.
In object-oriented programming languages, data type definitions belong to objects. Therefore, I cannot find all the data type definitions in one place. In Erlang or in C, I can define all my data types in a single included file or data dictionary. I can't do this in object-oriented programming languages ​​— data type definitions are everywhere.
I will give an example. Suppose I want to define a globally visible data type.
As practice and lisp-programmers have shown, it is better to have few commonly used data types and many small functions working with this data than many data types and few functions working with them.
In this case, a commonly used type can be a linked list, an array, a hash table, or a more complex entity, such as time, date, or file name.
In an object-oriented programming language, I have to choose some base class in which I define a commonly used data structure. All other classes that would like to use this data structure must inherit this class. Suppose now I want to create an object of the type “time” to which this structure belongs, and in which an object of type “time” to which ... well, you understand.
The state is the cornerstone of all problems. In particular, functions with side effects must be avoided.
At a time when the state in programming languages ​​is undesirable, in the real world the state dominates. I am interested in the state of my bank account, so when I deposit or withdraw money from it, I expect that the account state will be updated correctly.
What can programming languages ​​offer to work with this state from the real world?
The global system state is stored in all functions and derives from all functions. Mechanisms like monads (for functional languages) and DC grammars (for logical languages) are used. These mechanisms hide the state from the programmer, allowing him to program without taking the state into account, but at the same time allowing him to access the state if the need arises.
The “hide state from programmer” approach, chosen for object-oriented programming languages, is the worst possible approach. Instead of revealing the state and minimizing its effect on the code, it is hidden as if it is irrelevant.
Personally, I do not see evidence of the first and second reasons. The reasons are what is behind the technology. If the programming language technology is so bad that a new industry is being created to solve the problems of creating this new industry - then this is a gold mine for people who want to make money, not work.
This is what really drives object-oriented programming.
From the translator.
Original: Joe Armstrong, taken from here .
The text sensationalized in certain archaeological and programmer circles was written by Joe Armstrong, the author of Erlang. The date of writing the text could not be reliably established, but, judging by indirect data, it was at the beginning of the 90s.
With the increasing popularity of Erlang, they often began to ask the question “Is Erlang object-oriented?”. The correct answer would be "Yes, no, no!" But we could not say so in full voice, so we had to get out. We came up with some rather non-trivial answers that would represent Erlang of type-object-oriented language (for those who most of all draw their hands with this question), but also not object-oriented for those who are actually in the subject.
Here I would like to recall the thesis presentation by the Director of the French IBM at the 7th IEEE Conference on Logic Programming. He spoke about the fact that IBM has added quite a lot of object-oriented extensions to Prolog. When asked about the reasons for this, he answered:
“- Our customers wanted an object-oriented Prolog, so we did an object-oriented Prolog”
I remember thinking “How nice! Simply, no remorse, no introspection, no rushing about whether to do it right. ”
Why object-oriented programming sucks
')
My PERSONAL objections on the subject of OOP are claims to its main provisions. I will highlight some of these provisions and the essence of my claims.
Objection number 1. Data structures and functions should not be tied to each other.
Objects bind functions and data structures together in indivisible entities. I think this is a fundamental mistake, because functions and data structures are concepts belonging to completely different categories. Why is this so?
Because functions perform actions. They have input and output values. Input and output values ​​are data structures that are modified by functions. In many languages, functions are sequences of imperatives: “do this, then do it.” To understand the essence of a function, it is necessary to understand the order in which these imperatives are fulfilled (in lazy functional and logical languages, order may not matter).
Data structures simply exist. They do nothing. They are exclusively declarative. “Understanding” the data structure is much simpler than “understanding” a function.
Functions are represented by black boxes that transform inputs into outputs. If I understand the input and output, then I can understand the function (although this does not mean that I could write this function).
Functions are usually “understood” as parts of a computing system that transfer data from a data structure of type T1 to a data structure of type T2.
Since the functions and data structures are completely different types of animals, the decision to keep them in one “cage” is fundamentally wrong.
Objection number 2. Everything must be an object
Consider "time." In an object-oriented programming language, “time” must be an object. But in the non-object-oriented language, “time” is an instance of a data type. For example, in Erlang there are many different types of "time", each of which can be strictly and unambiguously defined. For example, using the following type definitions:
-deftype day() = 1..31 -deftype month() = 1..12. -deftype year() = int(). -deftype hour() = 1..24. -deftype minute() = 1..60. -deftype second() = 1..60. -deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}. -deftype hms() = {hms, hour(), min(), sec()}. ... Note that these definitions do not belong to any particular object. They are generally used without any restrictions, so such data structures representing "time" can be used by any function.
In addition, they have no related methods.
Objection number 3 In object-oriented languages, type definitions are ubiquitous.
In object-oriented programming languages, data type definitions belong to objects. Therefore, I cannot find all the data type definitions in one place. In Erlang or in C, I can define all my data types in a single included file or data dictionary. I can't do this in object-oriented programming languages ​​— data type definitions are everywhere.
I will give an example. Suppose I want to define a globally visible data type.
As practice and lisp-programmers have shown, it is better to have few commonly used data types and many small functions working with this data than many data types and few functions working with them.
In this case, a commonly used type can be a linked list, an array, a hash table, or a more complex entity, such as time, date, or file name.
In an object-oriented programming language, I have to choose some base class in which I define a commonly used data structure. All other classes that would like to use this data structure must inherit this class. Suppose now I want to create an object of the type “time” to which this structure belongs, and in which an object of type “time” to which ... well, you understand.
Objection number 4 Objects have a hidden state.
The state is the cornerstone of all problems. In particular, functions with side effects must be avoided.
At a time when the state in programming languages ​​is undesirable, in the real world the state dominates. I am interested in the state of my bank account, so when I deposit or withdraw money from it, I expect that the account state will be updated correctly.
What can programming languages ​​offer to work with this state from the real world?
- Object-oriented programming languages ​​will say "- We must hide the state from the programmer." States are hidden, they can only be accessed with special functions;
- Regular programming languages ​​(C, Pascal) will say that the visibility of state variables should be governed by the rules of the scopes of the language;
- Declarative languages ​​will say that there is no state.
The global system state is stored in all functions and derives from all functions. Mechanisms like monads (for functional languages) and DC grammars (for logical languages) are used. These mechanisms hide the state from the programmer, allowing him to program without taking the state into account, but at the same time allowing him to access the state if the need arises.
The “hide state from programmer” approach, chosen for object-oriented programming languages, is the worst possible approach. Instead of revealing the state and minimizing its effect on the code, it is hidden as if it is irrelevant.
Why is OOP so popular?
- Reason 1 - everyone thinks it is easy to learn;
- Reason 2 - everyone thinks that with its help it is possible to increase the degree of code reuse;
- Reason 3 - HYIP around OOP;
- Reason 4 - it creates a new programming industry.
Personally, I do not see evidence of the first and second reasons. The reasons are what is behind the technology. If the programming language technology is so bad that a new industry is being created to solve the problems of creating this new industry - then this is a gold mine for people who want to make money, not work.
This is what really drives object-oriented programming.
From the translator.
Original: Joe Armstrong, taken from here .
The text sensationalized in certain archaeological and programmer circles was written by Joe Armstrong, the author of Erlang. The date of writing the text could not be reliably established, but, judging by indirect data, it was at the beginning of the 90s.
Source: https://habr.com/ru/post/147890/
All Articles