These countless paradigms, concepts, tools and frameworks
My worldview, as a programmer, was formed at the time of console applications and textual user interfaces, they were replaced by graphical window GUIs, and now I am seeing the third round of technologies associated with the global network. Each time, of course, it was necessary to change not only the favorite programming language, but also the whole technological stack, with practices, blanks and fairly extensive libraries, which are now proudly called frameworks. It was necessary to cut live, mercilessly and decisively.
Recently, a web browser has become almost synonymous with the user interface, and no one has any doubts that the traditional window applications installed in a personal computer have already faded into history. Although a small percentage of software will remain behind them, it also remained behind the console applications forever.
Watching the emergence of the third, in my memory, generation of technologies and specialists, I can note that both the “bikes” and the “rakes” are repeated. That is why I could not write this article. Having a great temptation, go down to the very specifics and disassemble the cogs of several modern languages ​​and technologies, their bundles and features of docking, but leave it for other articles and concentrate on the principles that remain unchanged in all incarnations of information systems. I will explain each of the principles with a few examples already tied to the web.
1. No need to invent tricks where it can be done simply.
')
1.1. For example, feel free to abandon OOP where good old procedural programming is faster and more efficient. Expanding classes and objects in memory makes sense in such tasks when the application instance will live at least some long time. And when the script is launched in order to give up the resource in a split second, the branched conceptual classes are completely useless. In the end, the issuance of resources by the web server is something akin to stdout, the output is not changed. Although, in server tasks like daemons, batch and pending processing, crawlers, calculations, etc., OOP is of course necessary.
1.2. Who said that objects are necessary for inheritance and redefinition? A hierarchical file structure or hierarchical database queries are suitable.
1.3. If you are worried that the code does not look cool, but even quite simple, but the task is all done exactly, then you should reconsider your ideas about programming. It is not necessary to apply all known patterns and concepts in one project.
1.4. Public insanity on template engines is not quite clear to me, because most of the scripting web languages ​​are template engines themselves. The most striking example is PHP: it substitutes variables, there are loops and branching, and most importantly, all this does not require additional template parsing. When introducing accelerators, templates will be precompiled into byte-code just like all other parts of the program.
1.5. Now, many are guided by the principle of “download from the Internet and fasten”, but even if there is little time, then at least look at the downloaded code, perhaps it will suggest how to do the same thing more simply. After all, there is no guarantee that the author of the downloaded code had more experience, talent and time than you. And of course, if you are serious about the system you are writing, you should know, understand and feel every line of code in it.
2. Select and fix the toolkit for a long time, if you want diversity in functionality.
This is an empirical principle that, nevertheless, always works. Perhaps, some academicians will derive it from the fundamental laws of the universe, but for the time being no one bothers us to use it on an intuitive level. I think that most of you will be able to cite a lot of examples when clearer and more rigid languages ​​and technologies become a platform for more diverse software. On a smaller scale, we can simply enter corporate standards, internal specifications, formats, and protocols.
3. Inappropriate and inadequate use of tools is more common than bad tools.
Each language and technology has a range of tasks for which it fits perfectly, and for other tasks it probably has its own adequate means of solution.
4. It is impossible and unnecessary to separate data, logic and representation on a single layer of abstraction.
This is surprising, but even before the invention of MVC, and even more so, before its mass implementation, programmers understood that in each module there are always three parts: logic, data and display (or code, memory structures and interface). But recently I have been observing the abuse of this principle, saying “they said to divide, we will divide”. And it is not always possible to divide. Even if you select the presentation layer (display), then there will always be a place for all three parts: the display logic, display data and display patterns. Therefore, you can divide forever, and Snake Gorynych, will still be about three heads. The same situation with the selection of the model and controller, again, it will be possible to select all three components. Persistent struggle with this fact leads many to the generation of an incredible amount of code, classes, constructions and lotions. I'm not saying that MVC does not work, I just don’t need to use it so fanatically, everywhere and vigorously. Remember, combating a problem can only aggravate it, is it not better to accept and even use this fact. In the end, a proper understanding of the issue gave rise to such classes of systems as a DBMS, application server, and GUI. Notice, in the wording, I wrote precisely “on one layer of abstraction”. Let me explain: the DBMS operates with data and logic and the display at the level of relational abstraction (or other information models), the application server operates at the level of domain abstraction (or at the level of metaprogramming), the user interface operates with a completely different aspect of the same task. That is, it is not the data, the logic and the presentation that need to be divided (they should be selected rather than divided), but abstractions or aspects of the task.
5. There is no perfect code, you need to be content with some degree of universality.
For me, as an idealist and perfectionist, it was the most difficult thing to realize. I would, then the program code would be improved to the mind-blowing, to the extent that the program would not solve all imaginable and unimaginable tasks and would simply be called a “program”. Bringing to the point of absurdity can be completed only for an infinite time, and code optimization should direct its length to zero. Such a program is simply obliged to solve all the problems of programming once and for all. But in practice, something completely different is needed, namely, to solve an applied problem, which does not really require an ideal code. Of course, the code should please with its beauty, but do not get carried away.
6. Any extremism is bad.
If you help someone who is mistaken, to bring the error to the point of absurdity, then he himself will refuse him in favor of reasonable. Simple is more reliable than complex, good is more advantageous than bad, and quality is ultimately cheaper than low-quality. Only pride and fears do not allow to see simple ways, no extra efforts are needed to achieve goals, it’s better to give up mistakes and the desired will coincide with reality.
7. The development of the system leads to its limitations.
Any system, including information, for development requires decision-making, but each decision leads not only to the emergence of a functional, but also to the creation of constraints. Therefore, when introducing assumptions and (assumptions) when making decisions, always think about the limitations to which this leads and whether you are ready for them.
It's all. I hope someone will go ahead.
Recently, a web browser has become almost synonymous with the user interface, and no one has any doubts that the traditional window applications installed in a personal computer have already faded into history. Although a small percentage of software will remain behind them, it also remained behind the console applications forever.
Watching the emergence of the third, in my memory, generation of technologies and specialists, I can note that both the “bikes” and the “rakes” are repeated. That is why I could not write this article. Having a great temptation, go down to the very specifics and disassemble the cogs of several modern languages ​​and technologies, their bundles and features of docking, but leave it for other articles and concentrate on the principles that remain unchanged in all incarnations of information systems. I will explain each of the principles with a few examples already tied to the web.
1. No need to invent tricks where it can be done simply.
')
1.1. For example, feel free to abandon OOP where good old procedural programming is faster and more efficient. Expanding classes and objects in memory makes sense in such tasks when the application instance will live at least some long time. And when the script is launched in order to give up the resource in a split second, the branched conceptual classes are completely useless. In the end, the issuance of resources by the web server is something akin to stdout, the output is not changed. Although, in server tasks like daemons, batch and pending processing, crawlers, calculations, etc., OOP is of course necessary.
1.2. Who said that objects are necessary for inheritance and redefinition? A hierarchical file structure or hierarchical database queries are suitable.
1.3. If you are worried that the code does not look cool, but even quite simple, but the task is all done exactly, then you should reconsider your ideas about programming. It is not necessary to apply all known patterns and concepts in one project.
1.4. Public insanity on template engines is not quite clear to me, because most of the scripting web languages ​​are template engines themselves. The most striking example is PHP: it substitutes variables, there are loops and branching, and most importantly, all this does not require additional template parsing. When introducing accelerators, templates will be precompiled into byte-code just like all other parts of the program.
1.5. Now, many are guided by the principle of “download from the Internet and fasten”, but even if there is little time, then at least look at the downloaded code, perhaps it will suggest how to do the same thing more simply. After all, there is no guarantee that the author of the downloaded code had more experience, talent and time than you. And of course, if you are serious about the system you are writing, you should know, understand and feel every line of code in it.
2. Select and fix the toolkit for a long time, if you want diversity in functionality.
This is an empirical principle that, nevertheless, always works. Perhaps, some academicians will derive it from the fundamental laws of the universe, but for the time being no one bothers us to use it on an intuitive level. I think that most of you will be able to cite a lot of examples when clearer and more rigid languages ​​and technologies become a platform for more diverse software. On a smaller scale, we can simply enter corporate standards, internal specifications, formats, and protocols.
3. Inappropriate and inadequate use of tools is more common than bad tools.
Each language and technology has a range of tasks for which it fits perfectly, and for other tasks it probably has its own adequate means of solution.
4. It is impossible and unnecessary to separate data, logic and representation on a single layer of abstraction.
This is surprising, but even before the invention of MVC, and even more so, before its mass implementation, programmers understood that in each module there are always three parts: logic, data and display (or code, memory structures and interface). But recently I have been observing the abuse of this principle, saying “they said to divide, we will divide”. And it is not always possible to divide. Even if you select the presentation layer (display), then there will always be a place for all three parts: the display logic, display data and display patterns. Therefore, you can divide forever, and Snake Gorynych, will still be about three heads. The same situation with the selection of the model and controller, again, it will be possible to select all three components. Persistent struggle with this fact leads many to the generation of an incredible amount of code, classes, constructions and lotions. I'm not saying that MVC does not work, I just don’t need to use it so fanatically, everywhere and vigorously. Remember, combating a problem can only aggravate it, is it not better to accept and even use this fact. In the end, a proper understanding of the issue gave rise to such classes of systems as a DBMS, application server, and GUI. Notice, in the wording, I wrote precisely “on one layer of abstraction”. Let me explain: the DBMS operates with data and logic and the display at the level of relational abstraction (or other information models), the application server operates at the level of domain abstraction (or at the level of metaprogramming), the user interface operates with a completely different aspect of the same task. That is, it is not the data, the logic and the presentation that need to be divided (they should be selected rather than divided), but abstractions or aspects of the task.
5. There is no perfect code, you need to be content with some degree of universality.
For me, as an idealist and perfectionist, it was the most difficult thing to realize. I would, then the program code would be improved to the mind-blowing, to the extent that the program would not solve all imaginable and unimaginable tasks and would simply be called a “program”. Bringing to the point of absurdity can be completed only for an infinite time, and code optimization should direct its length to zero. Such a program is simply obliged to solve all the problems of programming once and for all. But in practice, something completely different is needed, namely, to solve an applied problem, which does not really require an ideal code. Of course, the code should please with its beauty, but do not get carried away.
6. Any extremism is bad.
If you help someone who is mistaken, to bring the error to the point of absurdity, then he himself will refuse him in favor of reasonable. Simple is more reliable than complex, good is more advantageous than bad, and quality is ultimately cheaper than low-quality. Only pride and fears do not allow to see simple ways, no extra efforts are needed to achieve goals, it’s better to give up mistakes and the desired will coincide with reality.
7. The development of the system leads to its limitations.
Any system, including information, for development requires decision-making, but each decision leads not only to the emergence of a functional, but also to the creation of constraints. Therefore, when introducing assumptions and (assumptions) when making decisions, always think about the limitations to which this leads and whether you are ready for them.
It's all. I hope someone will go ahead.
Source: https://habr.com/ru/post/117365/
All Articles