⬆️ ⬇️

Scientific programming: part 1

Science in programming - reality or reality? How many languages ​​are there in it and why do holivars go about the advantages of some languages ​​over others? If interested - please under the cat.



A long time ago, “sacred wars” are going on in which various approaches in writing programs and in programming itself are criticized and criticized, Object-Oriented Programming is criticized ( once , twice , three ).



Yegor Bugaenko criticizes the PLO with practical examples ( one , two , videos ), using the ideas of David West and, as I understood, recently went in the direction of theory. The effectiveness of these disputes tends to zero. Why? Because all these disputes are already being conducted on the basis of realizations of some thoughts, practices and opinions of individual people, and not on the basis of theoretical works. The scientific method and approach with its theories, hypotheses, axioms, experiments, evidence and facts recently in these disputes and "wars" is not the word at all!



In mathematics, as in any other science, any theorems and theories require proof. As an example: the Pythagorean theorem . First comes theory and practice. In programming, this approach has not been followed for several decades. Everything is replaced by dogmas and opinions of individuals, which are sometimes called "evangelists" or "prophets." With their verbiage, they promote to the masses only the ideas they need, without worrying about theory or evidence (See conferences and IT presentations). Where is science, and where is religion? And do not we slide into obscurantism and faith in words written for a long time and without requiring proof? Heard about the supporters of a flat Earth? Nothing like in terms of approaches to persuasion and uporosti?

')

And in such a curiosity of the last 30-40 years, programmers, blinded by religious convictions from preachers of the PLO or FP, built abstractions on top of other abstractions, new languages ​​on top of other languages, new frameworks and libraries on top of old ones. And why was all this necessary? For the sake of simplification and productivity of their work on writing programs. Only this path led to a dead end. Because instead of simplification, they have become more complicated and are no longer learning algorithms, but APIs and documentation for another fashionable framework, and maybe several. Now, bugs were searched not only in their code, but also in someone else's. Debugging code has to be done through tons of proxies, architecture patterns and design patterns, helpers, frameworks, and libraries. And, as studies show, there is no gain in the speed of writing code from the use of OOP.



A bit of history. How did it all start? At first there was procedural programming, then structural, and imperative programming followed him on the scene. Some people thought of introducing the concept of an object — object-oriented programming was born. And at that moment there was a sharp turn that turned the whole industry into the state in which we are now.



The introduction of the object should have been theoretically justified. But that did not happen. Instead, each language introduced the concept of an object in its own way. And each language developer interpreted the OOP postulates to their own taste and color. Highly focused fundamentalists have come up with Functional Programming based on mathematics, lists, and higher-order functions . It sounds serious and even a little bit scientifically based, because mathematics is a necessary and useful thing, just what do lists and functions have to do with the real world?



What tasks are solved by a pure FP without the use of states, and whether this is the optimal, convenient and correct way on the part of a person — such is the question to be asked of the “prophets” of FP. And it is asked ( one , two ).



Developers of functional languages ​​began to apply some paradigms from the PLO in order to move out of the field of applied problems in mathematics into the realm of real world problems. In response, some OOP languages ​​implemented paradigms from FP. And "mixed up a bunch of horses, people" (c)



As a result, the implementation of pure paradigms of the PLO and FP in the current languages ​​as in the song - “I blinded him from what was and what I loved”! And it turns out that without theoretical works and a scientific base, all these languages ​​are only the fruit of the fantasies and desires of their developers. And there are more than a hundred such languages! And so should not be! Ideally, there should be only 2 low-level languages ​​and 3-4 high-level languages ​​built on their basis.



I can assume that when they introduced the concept of an object, they took as a basis what they saw around them - humans and animals. And this was the main mistake that will grow to a huge size later! Thus, inheritance may have appeared (the ancestor-descendant and the connection between them is explained by inheritance, but what about other objects in the world? And what does the definition of the word "inheritance" mean in the real world? Blood and DNA? Nitrogenous bases?). How do other terms, namely abstraction, encapsulation and polymorphism, refer specifically to OOP? But to provide evidence of such a connection somehow did not bother. After all, you can write anything and it sounds logical, only the problem is that the arguments presented to the PLO have no relation. After all, a logical mistake was made in the PLO - (incomplete induction ) a transition was made from one particular case to the whole common set. To show this, let me give an example - if it is possible to take only living beings with an inheritance as a basis, then why, following the same logic, do not take a planet or a whole galaxy as a basis? After all, a planet or a galaxy is also the heiress of other objects from space and has a state and some kind of behavior. Or all mountains should be presented as objects without inheritance and practically without behavior.



Why should any object have or can use inheritance from another object someone has bothered to explain and prove? Emphasis on the word "prove"!



After all, if you begin to think hard about this, then a vague premonition arises: there has not been without deception, manipulation and mistakes! After all, the value of words is evaluated by the possibility of their logical and convincing proof based on facts and data. Otherwise, you can invent any kind of nonsense up to pink unicorns! Or in a different way - how do your words differ from the words of a religious extremist fanatic who escaped from a mental hospital?



But it was not always so. Here are examples of the scientific approach :



1. The book "Electronic digital machines and programming" A.I. Kitov .



2. Böhm – Jakopini theorem .



Not as much as we would like, and perhaps there are still many examples of scientific works somewhere, but they are very difficult to find. The overwhelming majority use all sorts of “bibles” and articles for argumentation and discussions (in reality, this is even a loud word for this process).



Let's try to apply science to programming and rely only on its achievements, results and methods.



We introduce basic definitions for terms:



An object is the smallest indivisible entity, also known to us as a chemical element , which has many properties and a lot of behavioral models implemented through methods. An object has 2 types of methods: 1) to get its properties, 2) to change its state.



Behavior model is an interface for interacting with an object.



A process is a type of interaction over elements (gravity, light, heating, radiation).



Data:



1. Everything in the surrounding world consists of the smallest indivisible chemical elements and therefore it is necessary to take the chemical element with a multitude of behavior models as the basis of the main object.



2. Chemical elements can be combined into sets.



3. Chemical elements interact with each other ( reaction ), are under the action of different processes.



4. Each chemical element has its own state at a certain time interval and can change it under the influence of external processes.



5. Processes are also objects or their multitude and can change chemical elements using their behavioral model.



Taking the facts and data presented as a basis, analyzing the properties and behavior of the elements, their interaction and processes between them, let us highlight several principles:



1. There are 2 types of objects: elementary (atomic) and reactionary (process). Elementary objects can, under certain conditions, return from the methods that change their state, new objects.



2. Reaction objects know the interfaces of the objects they work with.



3. All properties of an object must be defined as private and immutable, objects as public and immutable, and only public methods.



4. There is only one type of checked exception - Exception.



5. Elements have no such thing as NULL. Instead, it must be either 0, an empty string, an array with one element, or an empty collection of elements.



6. Elements have no inheritance in any way.



7. Also, there are no annotations, type conversions, internal and local classes, anonymous classes and lambdas, Enums, generics with the words super , extends and ? (only T, V, U, R !), static methods and attributes.



8. No abstract classes and methods.



9. Elementary objects cannot return data that can be changed. You can only ask this object to do something with them - since only he is responsible for storing and changing them. The change of the elementary object occurs only with the help of the reactionary object.



10. To store the state, you must use data structures such as arrays, queues, collections, lists, and maps.



11. Objects that react with each other can return another object or change their state.



12. Data structures are very important. Reaction objects can take as a method parameter a set (collection) of different objects and can return many different objects as a result of the work of the method.



13. Methods use formal logic (with statements , algebra of logic and logical operations ) and cycles expressed in the form of language syntax to work with data and return the result or change the state of the object (or its set).



14. The body of the method should take from 1 to 10 lines of code without gaps.



15. The class body should occupy from 5 lines to 2 heights of the monitor screen without gaps. The smaller the class and method body, the better.



Hypothesis:



1. If we exclude the possibility of inheritance, static methods and attributes, abstract classes, then the code in the project will be at least 10-20 percent less.



2. If all design anti-patterns are excluded from the code in the project, the code will be at least 10-15 percent less.



3. The smaller and simpler the objects, the easier it is to understand, test and change them.



4. Testing of objects will be faster (see p.3).



5. Debugging of the method will be faster (see p.3).



6. Writing new classes will be faster (see p.3)



Thus, taking into account the facts, principles and the created hypothesis (if it is confirmed experimentally), we can derive our Elementary or Atomic Programming Theory.



If in the 60s and 70s such an approach was taken as the main standard, then we would not have experienced so much negativity and confusion with the existing zoo of languages ​​and approaches.



In the next part, we will experimentally prove our hypothesis and complement the theory. Ask questions about the theory in the comments. Take it seriously and think.

Source: https://habr.com/ru/post/353408/



All Articles