Base on programming languages: The principle of preserving functionality
I continue to lay out excerpts from the introductory course of our company on industrial programming.
It tells how configs are harmful and why writing a lot of code is bad. Other parts can be found here .
')
Many programming languages ​​combine both a descriptive (declarative) approach for data structures and an imperative one for describing operations on data.
An example is C / C ++, in which header files (* .h) describe data structures, functions, and methods in a declarative way, and program files (* .c / *. Pp / *. Cpp) in imperative language describe actions data. Another example is PHP, which is divided into the HTML part (all * ML languages ​​are declarative), which describes the data structure for visualization, and the PHP part, which describes actions to fill the structure with data.
It is important to remember that, in general, any functional on data conversion can be reduced to a program on a Turing machine. It does not matter in what language and in which paradigm this functional was written. Thus, by analogy with the law of conservation of matter of Lomonosov-Luvoyes, one can introduce the law of conservation of functional.
The sum of the program functionality is determined only by the difference of the source and data flow, the number of conversions within the program does not affect the sum of the functional.
In fact, this law is one of the transpositions of the third law of thermodynamics as the entropy increases. It can be reformulated as follows:
As the amount of functionality increases, the amount of code increases.
This law is one of the fundamental for understanding the theory of programming. It sets the understanding that more code does not mean more functionality. But a greater amount of functionality is never free - you have to pay for the increase in functionality with the description of transition rules, for example, with lines of code.
An important consequence of this law is the Config Programming Theorem. The fact is that the config file is usually taken out of the program, based on the assumption that when you change the config file you do not have to go into the program and change its code.
At the same time, it is often forgotten that any config file in its essence is not only a source of information, but also a declarative description of the data structure in which this information is stored. In fact, any config file is a program in declarative PL.
Accordingly, adding a config file, the programmer at least brings into the program
a) new data source
b) writes the interpreter config file
That is, the programmer adds a new functionality to the program (because it adds another external data source, which means that it is necessary to support data transformations from this source in the program), and he describes part of this functionality in another program that makes the parent program different YaP (actually, the config language).
According to the law on the amount of functionality, the programmer will never be able to create a config in this way so that he completely takes care of programming the functionality from the user - part of the functionality will always be written in the config language.
The more the program requires configs, the more the user of these configs has to program them. If the configs also have a different filling format (property-files, XML, GUI forms, etc), then the user, moreover, will have to learn exactly as many new PLs as these configs. This, accordingly, will not add happiness to the user.
Trying to make the program more functional, flexible to different situations, bringing settings to the outside of the system, the programmer simply increases the entropy of the maternal program, creating new declarative programs and forcing the user to learn how to program in these declarative programs.
Not realizing any functionality, but giving the opportunity to include it in the configs, the programmer transfers the responsibility to program this functionality from himself to the user of the program.
One of the consequences of the configs programming theorem is the problem of a “flexible and customizable framework”. The fact is that the essence of any framework is to provide an API. The API is, in fact, also a declarative language that describes the rules for using this framework. The more the API is disclosed, the more available for this API parameters, the richer the language is and the more difficult it is to learn, and therefore use.
The most logical and understandable framework is a framework that provides a minimal API with maximum functionality behind it.
What is a logical and understandable framework? If using the framework you can do the same thing in several different ways, this means that the framework’s declarative API language is redundant. A simple framework is a framework whose API redundancy is minimal.
Each source of information, and therefore each type of information requires a code that converts this type of information to its internal native (native) view. For example, the config dictates the structure of the presentation of information, the API dictates the rules of the call. The converse is also true that each API, each config generates a new source of information, which also needs to be transformed by the caller to its native form.
Thus, the more language-language pairs are used in the program, the more data structures are used, the more transformations the program contains. At the same time, the number of transformations is greater than if the information entered the program using data structures at the base for the PL program.
In fact, the use of one additional config or additional programming language adds two times more code to the program than adding one more data source or one more data structure described in the mother language of the program.
The more different languages ​​used in the project (including different configs formats and different APIs), the more code appears in the program, while maintaining the same functionality.
Actually, the Babylonian language mixing theorem follows from this:
Adding a framework, config, or PL to facilitate data parsing leads to more complex data parsing.
We are directly confronted with the guys working with the functionality of the new basket - there is a cool mix of descriptive and executive paradigms, represented in several types of configs and using several types of API.
Part Two: The principle of maintaining functionality
It tells how configs are harmful and why writing a lot of code is bad. Other parts can be found here .
')
Many programming languages ​​combine both a descriptive (declarative) approach for data structures and an imperative one for describing operations on data.
An example is C / C ++, in which header files (* .h) describe data structures, functions, and methods in a declarative way, and program files (* .c / *. Pp / *. Cpp) in imperative language describe actions data. Another example is PHP, which is divided into the HTML part (all * ML languages ​​are declarative), which describes the data structure for visualization, and the PHP part, which describes actions to fill the structure with data.
It is important to remember that, in general, any functional on data conversion can be reduced to a program on a Turing machine. It does not matter in what language and in which paradigm this functional was written. Thus, by analogy with the law of conservation of matter of Lomonosov-Luvoyes, one can introduce the law of conservation of functional.
The sum of the program functionality is determined only by the difference of the source and data flow, the number of conversions within the program does not affect the sum of the functional.
In fact, this law is one of the transpositions of the third law of thermodynamics as the entropy increases. It can be reformulated as follows:
As the amount of functionality increases, the amount of code increases.
This law is one of the fundamental for understanding the theory of programming. It sets the understanding that more code does not mean more functionality. But a greater amount of functionality is never free - you have to pay for the increase in functionality with the description of transition rules, for example, with lines of code.
Config Programming Theorem
An important consequence of this law is the Config Programming Theorem. The fact is that the config file is usually taken out of the program, based on the assumption that when you change the config file you do not have to go into the program and change its code.
At the same time, it is often forgotten that any config file in its essence is not only a source of information, but also a declarative description of the data structure in which this information is stored. In fact, any config file is a program in declarative PL.
Accordingly, adding a config file, the programmer at least brings into the program
a) new data source
b) writes the interpreter config file
That is, the programmer adds a new functionality to the program (because it adds another external data source, which means that it is necessary to support data transformations from this source in the program), and he describes part of this functionality in another program that makes the parent program different YaP (actually, the config language).
According to the law on the amount of functionality, the programmer will never be able to create a config in this way so that he completely takes care of programming the functionality from the user - part of the functionality will always be written in the config language.
The more the program requires configs, the more the user of these configs has to program them. If the configs also have a different filling format (property-files, XML, GUI forms, etc), then the user, moreover, will have to learn exactly as many new PLs as these configs. This, accordingly, will not add happiness to the user.
Trying to make the program more functional, flexible to different situations, bringing settings to the outside of the system, the programmer simply increases the entropy of the maternal program, creating new declarative programs and forcing the user to learn how to program in these declarative programs.
Not realizing any functionality, but giving the opportunity to include it in the configs, the programmer transfers the responsibility to program this functionality from himself to the user of the program.
Simple framework theorem
One of the consequences of the configs programming theorem is the problem of a “flexible and customizable framework”. The fact is that the essence of any framework is to provide an API. The API is, in fact, also a declarative language that describes the rules for using this framework. The more the API is disclosed, the more available for this API parameters, the richer the language is and the more difficult it is to learn, and therefore use.
The most logical and understandable framework is a framework that provides a minimal API with maximum functionality behind it.
What is a logical and understandable framework? If using the framework you can do the same thing in several different ways, this means that the framework’s declarative API language is redundant. A simple framework is a framework whose API redundancy is minimal.
Babylonian language mixing theorem
Each source of information, and therefore each type of information requires a code that converts this type of information to its internal native (native) view. For example, the config dictates the structure of the presentation of information, the API dictates the rules of the call. The converse is also true that each API, each config generates a new source of information, which also needs to be transformed by the caller to its native form.
Thus, the more language-language pairs are used in the program, the more data structures are used, the more transformations the program contains. At the same time, the number of transformations is greater than if the information entered the program using data structures at the base for the PL program.
In fact, the use of one additional config or additional programming language adds two times more code to the program than adding one more data source or one more data structure described in the mother language of the program.
The more different languages ​​used in the project (including different configs formats and different APIs), the more code appears in the program, while maintaining the same functionality.
Actually, the Babylonian language mixing theorem follows from this:
Adding a framework, config, or PL to facilitate data parsing leads to more complex data parsing.
We are directly confronted with the guys working with the functionality of the new basket - there is a cool mix of descriptive and executive paradigms, represented in several types of configs and using several types of API.
Source: https://habr.com/ru/post/147618/
All Articles