Base on programming languages: The principle of maintaining functionality
I continue to lay out excerpts from the introductory course of our company on industrial programming.
It tells how the 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 approach for describing data operations.
An example is C / C ++, in which header files (* .h) declaratively describe data structures, functions and methods, and program files (* .c / *. Pp / *. Cpp) in an imperative language describe actions on 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, designed to describe actions to fill the structure with data.
It is important to remember that, in general, any data conversion functionality can be reduced to a program on a Turing machine. It does not matter in which language and in which paradigm this functionality was written. Thus, by analogy with the law of conservation of matter of Lomonosov-Louvoisier, one can introduce the law of conservation of functional.
The amount of the program’s functionality is determined only by the difference between the source and data flow, the number of transformations within the program does not affect the amount of functionality.
In fact, this law is one of the arrangements of the third law of thermodynamics on the measure of increasing entropy. It can be reformulated as follows:
With an increase in the amount of functionality, the amount of code increases.
This law is one of the fundamental for understanding the theory of programming. It makes it clear that more code does not mean more functionality. But a greater amount of functionality is never free - you need to pay for the increase in functionality with a description of the 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 will not have to go into the program and change its code.
It is often forgotten that any config file is inherently 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 on a declarative language.
Accordingly, adding a config file, the programmer at least contributes to the program
a) a new data source
b) writes a config file interpreter
That is, the programmer adds new functionality to the program (because it adds another external data source, which means that the program needs to support data conversions from this source), and he describes part of this functionality on a different parent language than the parent program YaP (actually, the language of the config).
According to the law on the amount of functionality, the programmer will never be able to create a config in such a way that he completely removes the user’s concern about programming the functional — part of the functional will always be written in the config language.
The more the program requires configs, the more users of these configs have to program on them. If the configs, at the same time, also have a different filling format (property-files, XML, GUI forms, etc), then the user, moreover, will have to study 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 various situations, making settings outside the system, the programmer simply increases the entropy of the mother program, creating new declarative language tools and forcing the user to learn to program in these declarative language codes.
Without implementing any functionality, but making it possible to enable it in configs, the programmer transfers the obligation to program this functionality from himself to the user of the program.
One of the consequences of the config programming theorem is the problem of a “flexible and customizable framework." The fact is that the essence of any framework is the provision of an API. The API is, in fact, also a declarative language that describes the rules for using this framework. The more API is disclosed, the more parameters are available for this API, the more rich this language is and the more difficult it is to learn, and therefore use it.
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 declarative API language of this framework 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) representation. 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 converted 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 programs contain transformations. In this case, the number of transformations is greater than if the information entered the program using data structures on the basis of the PL program.
In fact, using one additional config or an additional programming language adds twice as much code to the program as adding another data source or another data structure described in the program’s mother language.
The more different languages are used in the project (including different formats of configs and different APIs), the more code appears in the program, while maintaining the same functionality.
Actually, this implies the Babylonian language mixing theorem:
Adding a framework, config, or PL to facilitate data parsing complicates data parsing.
We were faced with this directly by the guys working with the functionality of the new basket - there is a great mix of descriptive and executive paradigms presented in several types of configs and using several types of APIs.
Part two: The principle of maintaining functionality
It tells how the 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 approach for describing data operations.
An example is C / C ++, in which header files (* .h) declaratively describe data structures, functions and methods, and program files (* .c / *. Pp / *. Cpp) in an imperative language describe actions on 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, designed to describe actions to fill the structure with data.
It is important to remember that, in general, any data conversion functionality can be reduced to a program on a Turing machine. It does not matter in which language and in which paradigm this functionality was written. Thus, by analogy with the law of conservation of matter of Lomonosov-Louvoisier, one can introduce the law of conservation of functional.
The amount of the program’s functionality is determined only by the difference between the source and data flow, the number of transformations within the program does not affect the amount of functionality.
In fact, this law is one of the arrangements of the third law of thermodynamics on the measure of increasing entropy. It can be reformulated as follows:
With an increase in the amount of functionality, the amount of code increases.
This law is one of the fundamental for understanding the theory of programming. It makes it clear that more code does not mean more functionality. But a greater amount of functionality is never free - you need to pay for the increase in functionality with a description of the 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 will not have to go into the program and change its code.
It is often forgotten that any config file is inherently 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 on a declarative language.
Accordingly, adding a config file, the programmer at least contributes to the program
a) a new data source
b) writes a config file interpreter
That is, the programmer adds new functionality to the program (because it adds another external data source, which means that the program needs to support data conversions from this source), and he describes part of this functionality on a different parent language than the parent program YaP (actually, the language of the config).
According to the law on the amount of functionality, the programmer will never be able to create a config in such a way that he completely removes the user’s concern about programming the functional — part of the functional will always be written in the config language.
The more the program requires configs, the more users of these configs have to program on them. If the configs, at the same time, also have a different filling format (property-files, XML, GUI forms, etc), then the user, moreover, will have to study 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 various situations, making settings outside the system, the programmer simply increases the entropy of the mother program, creating new declarative language tools and forcing the user to learn to program in these declarative language codes.
Without implementing any functionality, but making it possible to enable it in configs, the programmer transfers the obligation to program this functionality from himself to the user of the program.
Simple Framework Theorem
One of the consequences of the config programming theorem is the problem of a “flexible and customizable framework." The fact is that the essence of any framework is the provision of an API. The API is, in fact, also a declarative language that describes the rules for using this framework. The more API is disclosed, the more parameters are available for this API, the more rich this language is and the more difficult it is to learn, and therefore use it.
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 declarative API language of this framework 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) representation. 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 converted 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 programs contain transformations. In this case, the number of transformations is greater than if the information entered the program using data structures on the basis of the PL program.
In fact, using one additional config or an additional programming language adds twice as much code to the program as adding another data source or another data structure described in the program’s mother language.
The more different languages are used in the project (including different formats of configs and different APIs), the more code appears in the program, while maintaining the same functionality.
Actually, this implies the Babylonian language mixing theorem:
Adding a framework, config, or PL to facilitate data parsing complicates data parsing.
We were faced with this directly by the guys working with the functionality of the new basket - there is a great mix of descriptive and executive paradigms presented in several types of configs and using several types of APIs.