What's wrong with OOP and OP, and what's wrong with programming

So it was got on habr that for each holivarny article "Pro" there is always article "Contra".
I also decided not to leave the post “What's wrong with the PLO and OP” alone.



It does not make sense to contradict directly what has been written, because “taste” is described there, and, as you know, it tastes and color ... everyone loves his own YP.
There is no problem with OOP and OP. The purity of functions is just a tool, as well as “everything is an object”.
There is only one criticism of the law - bright holes are clearly visible in the struggle for millimeters, and in any degenerate methods the flaws are clearly manifested.
Another thing is that any non-degenerate methods also have disadvantages, only there are more of them, but they are not so easily visible.
Fans of C ++ gnobit full OOP, Java gnobit C ++ for incomplete OOP, Haskell gnobit other FP for dirty functions, the other FP gnomes for Haskell for excessively pure functions.
Everything has its flip side.
Then why all got to objects and functions, but not arrays and pointers ?!

This article can be called a synthesis of my article "The development of user-defined data types in programming . "
To understand why objects and functions are so guilty, let's take a look at the languages ​​above.
')

Example 1

We have both PHP and a business card site. Almost certainly, not only frameworks are almost absent there, but also generally intelligible structure.
If this site develops slowly, we will have functions, arrays, then objects will appear, right down to highly object-oriented frameworks.
As we can see, the growing complexity of the site makes it necessary to introduce complexity into the program. The most paradoxical is that complexity is introduced to reduce complexity (while moving to a higher level of abstraction). Properly written site using objects will lose, if everything is rewritten under a procedural approach.

Example 2

Assembler You can even write an operating system on it, as the KolibriOS guys do, for example, but let's be frank, use it where you can't do without it.
For something simple, they mainly use C, much less often Pascal, BASIC. And you can write an OS on C (for example, the same Linux), but now it is much less often used for large projects. And this is despite the fact that C is the lingua franca of many programming languages.
The growing complexity of the algorithms does not allow intensive use of the capabilities of the language, it is necessary to use extensively !

Now for complex projects, Java, C ++, C #, ... are used - highly object languages.
Functional programming can be considered as an alternative approach to solving complexity - Lisp and Lisp-like languages ​​are comparable in power to C, OCaml is comparable to C ++ and even higher (modules as functions have approximately the same power as objects), Haskell - higher Java (more on this below).

The bottom line is that each methods / functions / objects / ... solve only their own ranges of complexity.
And to consider 2+2 as (2).(+)((2)) - says that the object is a rather complicated entity, and light things are simply not programmed on it. Languages ​​like Ruby help syntactic sugar lower this complexity threshold.

Objects

It’s stated in this article as much as that “the PLO and the FI are ineffective if we go to the extreme in their use”.

But I think this is not their main "fault."
Intensive solutions with the help of objects have been exhausted (for large projects), and this is precisely the main complaint about objects: extensive solutions do not give that beauty, simplicity and efficiency. And nagging begins. For example, such: "Functions are a fundamental concept, while objects only contain them."

I propose to look at this annoyance from another point of view: if we consider a function as an object, then we can see that it is also a tool for scaling complexity.
Of course, scaling is understood as fractal scaling - if we have a problem - we solve small problems, and on a scale above we solve larger problems with the same methods, and even larger ones - with larger problems using the same methods.
Objects are a tool for scaling our tasks. In my article I mentioned, I called objects user data, which make it possible to save tools for working with him in him.
This is what made the objects gain such great popularity - they are easy to scale up.

Example 3

Planet Earth. May we program upwards. We have buildings, buildings and people. On the scale up will be townships, cities and human flows. Another level up you need to look at areas, areas, cities and migration. Even higher will be countries and peoples. Continents and foreign policy will be even higher. Earth and humanity will be even higher.

However, let us dwell on the lack of fractal scaling. As you know, a system is a collection of elements, while it has properties that a sum of elements does not possess. It is this small, but the most essential increment that gradually dissolves during fractal scaling - one has to fight for each rise in the level, for one has to break the fractality. In particular, it is therefore proposed not to produce too large a hierarchy of objects.

Type Classes

Is there something that scales more easily than objects? As I indicated in another article - there is.
These are type-classes (they are also type-classes) in Haskell, a similar mechanism that Scala introduced (although the mechanism is rather complicated there), and the object analog is roles in Perl.
As you can see, these are not the most popular languages.
If you look, it is clear that now the type-classes have overtaken objects in power and are on an intensive path. They have not yet rested against the ceiling.

Conclusion

The complexity of the programs is increasing. With OOP and OP everything is all right. Do not order only with the rapid scaling of complexity, because complexity grows faster than intensive possibilities allow.