Scientific Programming: Part 1
Science in programming - true or real? How many languages are there and why do holivars go about the advantages of one language over another? If interested - please, under cat.
Once upon a time there are “holy wars” in which various approaches to writing programs and in programming itself are discussed and criticized, mainly Object-Oriented Programming ( one , two , three ) is criticized .
Egor Bugaenko criticizes the PLO on practical examples ( one , two , video), using the ideas of David West and, as I understand it, 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 the implementation of some thoughts, practices and opinions of individuals, and not on the basis of theoretical works. There has been no scientific method or approach with its theories, hypotheses, axioms, experiments, evidence and facts recently in these disputes and “wars” from the word at all!
In mathematics, as in any other science, any theorems and theories require proof. As an example: Pythagorean Theorem. First comes the theory, and then practice. In programming, this approach has not been followed for several decades. Everything is replaced by the dogmas and opinions of individuals who are sometimes called “evangelists” or “prophets”. They, with their verbiage, promote to the masses only the ideas they need, not caring either about theory or about evidence (See IT conferences and presentations). Where is science here, and where is religion? And are we not sliding into obscurantism and faith in words written long ago and not requiring evidence? Have you heard about the supporters of a flat earth? Does it resemble anything in terms of persuasion and tenacity approaches?
And in such a courage, for the last 30-40 years, programmers blinded by religious beliefs from OOP or FP preachers have built abstractions on top of other abstractions, new languages on top of other languages, new frameworks and libraries on top of the old ones. And why was all this needed? For the sake of simplification and productivity of my work on writing programs. Only this path has led to a dead end. Because instead of simplification, we got more complicated and studied now not algorithms, but API and documentation for the next fashionable framework, and maybe several. Now they began to search for bugs not only in their code, but also in someone else's. Code debugging 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 at all.
A bit of history. How did it all start? At first there was procedural programming, then structural and then imperative programming came onto the scene . Some people thought of introducing the concept of an object - that is how object-oriented programming was born . And at that moment there was a sharp turn, turning the entire 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 taste and color. Particularly stubborn fundamentalists come up with Functional Programmingbased on math, lists, and higher order functions . It sounds serious and even a little scientifically sound, because mathematics is a necessary and useful thing, but what are lists and functions related to the real world?
What tasks does pure AF solve without the use of states, and is there an optimal, convenient, and correct way on the part of man — such a question should be asked to the “prophets" of AF. And they ask him ( one , two ).
Functional language developers have begun to apply some of the OOP paradigms in order to move from the field of applied mathematics to the real world. In response, some OOP languages implemented paradigms from the FP. And "Horses mixed up in a bunch of people" (c)
As a result, the implementation of the pure OOP and FP paradigms in current languages as in the song - “I blinded him from what was, and what was, what I loved”! And it turns out that without theoretical work and a scientific base, all these languages are just a figment of the fantasies and desires of their developers. And there are more than a hundred such languages! And it should not be so! 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 - man and animals. And this was the main mistake that will later grow to a huge size! Thus, inheritance may have appeared (the ancestor-descendant and the relationship between them is explained by inheritance, but what about other objects in the world? And what does the very definition of the word “inheritance” mean in the real world? Blood and DNA? Nitrogen bases?). How do the other terms, namely abstraction, encapsulation and polymorphism, refer specifically to OOP? And somehow they did not bother to provide evidence of such a connection. After all, you can write anything and it sounds logical, only the problem is that the arguments presented here have no relation to OOP. Indeed, a logical mistake was made in OOP - (incomplete induction) a transition was made from one particular case to the entire general set. To show this, I will give an example - if it is possible to take only living beings with inheritance as a basis, then why, following the same logic, not take a planet or an entire galaxy as a basis? After all, a planet or galaxy is also the heiress of other objects from space and has a state and some kind of behavior. Or imagine all mountains as objects without inheritance and practically without behavior.
Why does any object should or can use inheritance from another object, someone bothered to explain and prove? Emphasis on the word "prove"!
After all, if you start to think a lot about it, then there is a vague foreboding: here it was not without deception, manipulation and mistakes! After all, the value of words is evaluated as far as possible to prove them logically and reasonably based on facts and data. Otherwise, you can invent any kind of nonsense up to pink unicorns! Or in another way - how do your words differ from the words of a religious fanatic-extremist who escaped from a mental hospital?
But it was not always so. Here are examples of a scientific approach :
1. book "Electronic digital machines and programming" A.I. Kitova .
2. Boehm-Jacopini theorem .
Not as many as we would like, and perhaps somewhere else there are many more examples of scientific works, but they are very difficult to find. The vast majority use all sorts of “bibles” and articles for argumentation and discussion (in reality, this is even too big a word for this process).
Let's try to apply science to programming and rely only on its achievements, results and methods.
We introduce the basic definitions for the terms: An
object is the smallest indivisible entity, also known to us as a chemical element , which has many properties and many behaviors implemented through methods. An object has 2 types of methods: 1) for obtaining its properties, 2) for changing its state.
Behavior Model - Interface for Interactionwith the object.
A process is a type of interaction over elements (gravity, light, heating, radiation).
Facts:
1. Everything in the surrounding world consists of the smallest indivisible chemical elements and therefore it is necessary to take the chemical element with many models of behavior 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 influence of different processes.
4. Each chemical element has its own state for a certain period of time and can change it under the influence of external processes.
5. Processes are also objects or their set and with the help of their behavior model they can change chemical elements.
Based on the stated facts and data, analyzing the properties and behavior of the elements, their interaction and processes between them, we outline several principles:
1. There are 2 types of objects: elementary (atomic) and reaction (process). Elementary objects can, subject to certain conditions, return new objects from methods that change their state.
2. Reactionary objects know the interfaces of the objects with which they work.
3. All properties of an object should be defined as private and immutable, objects as public and immutable, and methods only public.
4. There is only one type of checked exception - Exception.
5. Elements have no such thing as NULL. Instead, it should be either 0, an empty string, an array with one element, or an empty collection of elements.
6. Elements have no inheritance in any form.
7. Also there are no annotations, type casts, inner 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. There are 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 it is responsible for their storage and change. Changing an elementary object occurs only with the help of a reaction object.
10. To store the state, it is necessary to use data structures, such as arrays, queues, collections, lists, and maps.
11. Objects reacting with each other can return another object or change their state.
12. Data structures are very important. Reaction objects can take many (collection) of different objects as parameters of the method and can return many different objects as a result of the method.
13. Methods use formal logic (withstatements , algebra of logic and logical operations ) and cycles expressed in the form of language syntax for working with data and return the result or change the state of the object (or its set).
14. The body of the method should occupy from 1 to 10 lines of code without gaps.
15. The body of the class should occupy from 5 lines to 2 heights of the monitor screen without gaps. The smaller the body of the class and method, the better.
Hypothesis:
1. If we exclude the possibility of inheritance, static methods and attributes, abstract classes from the PL (Programming Language), then the code in the project will become at least 10-20 percent less.
2. If you exclude all design anti-patterns from the code in the project, then the code will become at least 10-15 percent less.
3. The smaller and simpler the objects, the easier it is to understand, test and modify them.
4. Testing of objects will be faster (see p. 3).
5. Debugging of the method will be faster (see point 3).
6. Writing new classes will be faster (see Section 3).
Thus, taking into account the facts, principles and the hypothesis created (if it is confirmed experimentally), we can derive our Elementary or Atomic programming theory.
If in the 60s and 70s such an approach were adopted as the main standard, then we would not now experience so much negativity and confusion with the existing zoo of languages and approaches.
In the next part, we will experimentally prove our hypothesis and supplement the theory. Ask theory questions in the comments. Take this matter seriously and think.
Once upon a time there are “holy wars” in which various approaches to writing programs and in programming itself are discussed and criticized, mainly Object-Oriented Programming ( one , two , three ) is criticized .
Egor Bugaenko criticizes the PLO on practical examples ( one , two , video), using the ideas of David West and, as I understand it, 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 the implementation of some thoughts, practices and opinions of individuals, and not on the basis of theoretical works. There has been no scientific method or approach with its theories, hypotheses, axioms, experiments, evidence and facts recently in these disputes and “wars” from the word at all!
In mathematics, as in any other science, any theorems and theories require proof. As an example: Pythagorean Theorem. First comes the theory, and then practice. In programming, this approach has not been followed for several decades. Everything is replaced by the dogmas and opinions of individuals who are sometimes called “evangelists” or “prophets”. They, with their verbiage, promote to the masses only the ideas they need, not caring either about theory or about evidence (See IT conferences and presentations). Where is science here, and where is religion? And are we not sliding into obscurantism and faith in words written long ago and not requiring evidence? Have you heard about the supporters of a flat earth? Does it resemble anything in terms of persuasion and tenacity approaches?
And in such a courage, for the last 30-40 years, programmers blinded by religious beliefs from OOP or FP preachers have built abstractions on top of other abstractions, new languages on top of other languages, new frameworks and libraries on top of the old ones. And why was all this needed? For the sake of simplification and productivity of my work on writing programs. Only this path has led to a dead end. Because instead of simplification, we got more complicated and studied now not algorithms, but API and documentation for the next fashionable framework, and maybe several. Now they began to search for bugs not only in their code, but also in someone else's. Code debugging 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 at all.
A bit of history. How did it all start? At first there was procedural programming, then structural and then imperative programming came onto the scene . Some people thought of introducing the concept of an object - that is how object-oriented programming was born . And at that moment there was a sharp turn, turning the entire 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 taste and color. Particularly stubborn fundamentalists come up with Functional Programmingbased on math, lists, and higher order functions . It sounds serious and even a little scientifically sound, because mathematics is a necessary and useful thing, but what are lists and functions related to the real world?
What tasks does pure AF solve without the use of states, and is there an optimal, convenient, and correct way on the part of man — such a question should be asked to the “prophets" of AF. And they ask him ( one , two ).
Functional language developers have begun to apply some of the OOP paradigms in order to move from the field of applied mathematics to the real world. In response, some OOP languages implemented paradigms from the FP. And "Horses mixed up in a bunch of people" (c)
As a result, the implementation of the pure OOP and FP paradigms in current languages as in the song - “I blinded him from what was, and what was, what I loved”! And it turns out that without theoretical work and a scientific base, all these languages are just a figment of the fantasies and desires of their developers. And there are more than a hundred such languages! And it should not be so! 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 - man and animals. And this was the main mistake that will later grow to a huge size! Thus, inheritance may have appeared (the ancestor-descendant and the relationship between them is explained by inheritance, but what about other objects in the world? And what does the very definition of the word “inheritance” mean in the real world? Blood and DNA? Nitrogen bases?). How do the other terms, namely abstraction, encapsulation and polymorphism, refer specifically to OOP? And somehow they did not bother to provide evidence of such a connection. After all, you can write anything and it sounds logical, only the problem is that the arguments presented here have no relation to OOP. Indeed, a logical mistake was made in OOP - (incomplete induction) a transition was made from one particular case to the entire general set. To show this, I will give an example - if it is possible to take only living beings with inheritance as a basis, then why, following the same logic, not take a planet or an entire galaxy as a basis? After all, a planet or galaxy is also the heiress of other objects from space and has a state and some kind of behavior. Or imagine all mountains as objects without inheritance and practically without behavior.
Why does any object should or can use inheritance from another object, someone bothered to explain and prove? Emphasis on the word "prove"!
After all, if you start to think a lot about it, then there is a vague foreboding: here it was not without deception, manipulation and mistakes! After all, the value of words is evaluated as far as possible to prove them logically and reasonably based on facts and data. Otherwise, you can invent any kind of nonsense up to pink unicorns! Or in another way - how do your words differ from the words of a religious fanatic-extremist who escaped from a mental hospital?
But it was not always so. Here are examples of a scientific approach :
1. book "Electronic digital machines and programming" A.I. Kitova .
2. Boehm-Jacopini theorem .
Not as many as we would like, and perhaps somewhere else there are many more examples of scientific works, but they are very difficult to find. The vast majority use all sorts of “bibles” and articles for argumentation and discussion (in reality, this is even too big a word for this process).
Let's try to apply science to programming and rely only on its achievements, results and methods.
We introduce the basic definitions for the terms: An
object is the smallest indivisible entity, also known to us as a chemical element , which has many properties and many behaviors implemented through methods. An object has 2 types of methods: 1) for obtaining its properties, 2) for changing its state.
Behavior Model - Interface for Interactionwith the object.
A process is a type of interaction over elements (gravity, light, heating, radiation).
Facts:
1. Everything in the surrounding world consists of the smallest indivisible chemical elements and therefore it is necessary to take the chemical element with many models of behavior 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 influence of different processes.
4. Each chemical element has its own state for a certain period of time and can change it under the influence of external processes.
5. Processes are also objects or their set and with the help of their behavior model they can change chemical elements.
Based on the stated facts and data, analyzing the properties and behavior of the elements, their interaction and processes between them, we outline several principles:
1. There are 2 types of objects: elementary (atomic) and reaction (process). Elementary objects can, subject to certain conditions, return new objects from methods that change their state.
2. Reactionary objects know the interfaces of the objects with which they work.
3. All properties of an object should be defined as private and immutable, objects as public and immutable, and methods only public.
4. There is only one type of checked exception - Exception.
5. Elements have no such thing as NULL. Instead, it should be either 0, an empty string, an array with one element, or an empty collection of elements.
6. Elements have no inheritance in any form.
7. Also there are no annotations, type casts, inner 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. There are 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 it is responsible for their storage and change. Changing an elementary object occurs only with the help of a reaction object.
10. To store the state, it is necessary to use data structures, such as arrays, queues, collections, lists, and maps.
11. Objects reacting with each other can return another object or change their state.
12. Data structures are very important. Reaction objects can take many (collection) of different objects as parameters of the method and can return many different objects as a result of the method.
13. Methods use formal logic (withstatements , algebra of logic and logical operations ) and cycles expressed in the form of language syntax for working with data and return the result or change the state of the object (or its set).
14. The body of the method should occupy from 1 to 10 lines of code without gaps.
15. The body of the class should occupy from 5 lines to 2 heights of the monitor screen without gaps. The smaller the body of the class and method, the better.
Hypothesis:
1. If we exclude the possibility of inheritance, static methods and attributes, abstract classes from the PL (Programming Language), then the code in the project will become at least 10-20 percent less.
2. If you exclude all design anti-patterns from the code in the project, then the code will become at least 10-15 percent less.
3. The smaller and simpler the objects, the easier it is to understand, test and modify them.
4. Testing of objects will be faster (see p. 3).
5. Debugging of the method will be faster (see point 3).
6. Writing new classes will be faster (see Section 3).
Thus, taking into account the facts, principles and the hypothesis created (if it is confirmed experimentally), we can derive our Elementary or Atomic programming theory.
If in the 60s and 70s such an approach were adopted as the main standard, then we would not now experience so much negativity and confusion with the existing zoo of languages and approaches.
In the next part, we will experimentally prove our hypothesis and supplement the theory. Ask theory questions in the comments. Take this matter seriously and think.