Translatyon sync: en, ru, uk

Author: tshemsedinov

README.md

@@ -2,7 +2,13 @@
 
 ## Multi-paradigm approach in the Software Engineering
 
-[Index EN](content/en/Index.md) | [Оглавление RU](content/ru/Index.md) | [Зміст UK](content/uk/Index.md) | [Obsah CZ](content/cz/Index.md)
+| Language | Index | PDF |
+| --- | --- | --- |
+| English (EN) | [Index](content/en/Index.md) | [Download](release/Metaprogramming-en.pdf) |
+| German (DE) | [Inhalt](content/de/Index.md) | [Download](release/Metaprogramming-de.pdf) |
+| Russian (RU) | [Оглавление](content/ru/Index.md) | [Download](release/Metaprogramming-ru.pdf) |
+| Czech (CZ) | [Obsah](content/cz/Index.md) | [Download](release/Metaprogramming-cz.pdf) |
+| Ukrainian (UK) | [Зміст](content/uk/Index.md) | [Download](release/Metaprogramming-uk.pdf) |
 
 Generated books are located in _/release_ folder
 

content/en/1-6-Engineer.md

@@ -1,3 +1,5 @@
-## 1.6. Software engineer speciality overview
+## 1.6. Software Engineer Profession Overview
 
-No translation
+Around programming, as around any sphere of human activity, people have managed to build an enormous number of prejudices and misconceptions. The primary source of problems is terminology, as various paradigms, languages, and ecosystems impose their own terminology, which is not only contradictory between each other, but also illogical even within individual communities. Moreover, many self-taught programmers and loners invent unique, incomparable terminology and concepts that duplicate each other. Aggressive marketers also destructively influence the IT industry as a whole, on the formation of worldview and terminology. By twisting obvious things, confusing and complicating concepts, they ensure an inexhaustible avalanche of problems on which the entire software business is sustained. By luring users and programmers to their technologies, industry giants often create very tempting and plausible concepts that ultimately lead to incompatibility, standards wars, and obvious dependence on software platform vendors. Groups that capture people's attention parasitize on their attention and budgets for decades. Driven by pride and vanity, some developers themselves spread questionable, and sometimes deliberately dead-end ideas. After all, making software well is completely unprofitable for the manufacturer. The situation is significantly better in the field of free software and open source, but decentralized enthusiasts are too fragmented to effectively counter the powerful propaganda of industry giants.
+
+As soon as any technology or ecosystem develops sufficiently to create good solutions on it, it inevitably becomes obsolete or the manufacturer stops supporting it, or it becomes overly complex. In my memory, more than five such technological ecosystems have already changed.

content/en/1-7-Paradigms.md

@@ -1,3 +1,11 @@
-## 1.7. Programming paradigms overview
+## 1.7. Programming Paradigms Overview
 
-No translation
+A mathematician views a program as a function that can be decomposed (divided) into simpler functions so that the program-function is their superposition. That is, roughly speaking, a program is a complex formula, a data transformer, where the problem conditions are fed as input, and we get the solution as output. Not every programmer is familiar with this point of view, though it's not perfect, it's useful for rethinking one's activities. The opposite point of view is more common, which is easily obtained from programming practice. It consists of writing programs based on the user's representation, from user interface screen designs and from tools, language, platform, and libraries. As a result, we get not a program-function, but a large system of states in which a combinatorial explosion of transitions occurs and whose behavior is unpredictable even for the author, let alone the user. But we cannot immediately reject this seemingly terrible approach. It has a constructive core, and it lies in the fact that not all programs can be implemented in the functional paradigm as data transformers in a short time. Moreover, human activity consists entirely of steps and changes in the states of objects around us according to the principle of step-by-step manipulation of them, and representing it as functions would be quite unnatural for our thinking.
+
+A paradigm sets a set of ideas and concepts, assumptions and constraints, concepts, principles, postulates, techniques and programming techniques for solving problems on a computer.
+
+In this section, we will consider some of them superficially, and later in the book there will be a special chapter with a more detailed discussion of each paradigm. There are languages that support one paradigm, and there are multi-paradigm languages. We will pay attention to different languages and differences in the implementation of paradigms in them.
+
+For a person, it is natural to represent any action as a set of steps or an algorithm - this is the imperative approach. These steps can be either linear or making a decision to move to another step of the plan, instead of executing actions sequentially. Making a decision for a machine is a comparison operation that leads to algorithm branching, giving options (usually two). Actions can be conditionally divided into internal and external. In internal ones, only the processor and memory participate, the action is executed immediately, without waiting, and has a certain result that is available directly at the next step of the algorithm. External actions are calls to external input/output devices (network, disks, other devices), and they require waiting for a response from the device, which will come in a time usually unknown in advance. We send a control signal to peripheral devices about what they need to do and transfer the necessary data to them. Further, we have two options again: either wait for the result, and this will be called blocking input/output mode, or move to the next step of the algorithm without waiting for the result, and this will be non-blocking input/output. Such a division is caused by a significant difference in the duration of internal and external actions. Most external actions are associated with physical operations on the external environment. For example, data transmission over wireless or wired networks, writing or reading from a physical medium, interaction with sensors, relays or actuators. Such operations often have not a digital, but an analog nature, so additional data conversion is required, waiting for a transient process, waiting for the required sensor reading or signal from the device, etc. Input/output devices often have their own controller in which a separate stream of operations is executed, and interaction between the central processor and input/output devices also requires coordination, which takes time and can end unsuccessfully.
+
+A paradigm offers a generalized model for solving problems, a certain style, patterns, examples of good and bad solutions used for writing program code.

content/en/1-Introduction.md

@@ -1,3 +1,7 @@
 # 1. Introduction
 
-No translation
+Constant rethinking of one's activities, even the simplest ones, should accompany an engineer throughout their life. The habit of writing down one's thoughts in words and refining formulations is very helpful in this regard. This text emerged as my fragmentary notes, written in different years, which I accumulated and critically reviewed dozens of times. Often, I disagreed with myself when re-reading a passage after it had been sitting for some time. Therefore, I refined the text until I agreed with what was written after prolonged periods of material maturation. I set myself the task of writing as concisely as possible and repeatedly rewrote large fragments, finding that they could be expressed more briefly. The structure of the text and table of contents began to emerge after the first year of teaching, but in the tenth year I decided to publish all materials not only as open video lectures, as I had been doing for about five years, but also as text. This allowed everyone from the Metarchy community to participate in shaping the book, quickly find typos and inaccuracies thanks to readers, and for many it's simply more convenient to perceive in book form. The current version can always be found at https://github.com/HowProgrammingWorks/Book, it will be continuously updated. Please send requests for corrections and additions to issues: https://github.com/HowProgrammingWorks/Book/issues in English, new ideas to discussions: https://github.com/HowProgrammingWorks/Book/discussions in any language, and format your additions and corrections as pull-requests to the book repository.
+
+> Programming is the art and engineering of solving problems using computational technology
+
+Engineering, because it is designed to extract benefit from knowledge, and art, because programming at the current stage of development, unfortunately, is not limited to knowledge and is forced to resort to intuition and poorly understood personal experience. The programmer's task is not to find a mathematically correct solution, but to find a generalized solution mechanism capable of leading us to finding an acceptable solution in limited time for as large a class of problems as possible. In other words, to find an abstract class of solutions. Not all programming paradigms assume step-by-step solutions, but the physical implementation of computational technology and the nature of human thinking assume step-by-step processes. The complexity lies in the fact that these actions are far from always reducible to machine operations and involve external interaction with input/output devices and sensors, and through them, with the external world and humans. This circumstance creates great uncertainty, which does not allow mathematically rigorous proof of the correctness of the method for solving all problems and, moreover, strictly derive such a solution from axioms, as is characteristic of exact sciences. However, individual algorithms can and should be derived analytically if they are reducible to pure functions. That is, to functions that at any moment for a certain set of input data unambiguously give the same result. A pure function has no history (memory or state) and does not access external devices (which may have such state), can only access other pure functions. Programming inherited from mathematics the ability to find exact solutions analytically, and the computational machine itself functions strictly within the framework of formal mathematical apparatus. But the process of writing program code cannot always be reduced to formal procedures, we are forced to make decisions under conditions of great uncertainty and construct programs engineering-wise. The programmer is limited by the time of program development, so we reduce uncertainty by introducing constructive constraints that are not strictly derivable from the task and are based on the intuition and experience of a particular specialist. Simply put, in the absence of an optimal algorithm, a programmer can solve a problem in any way that gives acceptable results in reasonable time, and which can be implemented in such time while the problem remains relevant. Under such conditions, we must take into account not only the measure of approximation of the solution to the optimal one, but also the programmer's knowledge, mastery of tools, and other available resources. After all, even access to knowledge of ready-made software solutions is limited by copyright, source code ownership rights and documentation, corresponding license restrictions, not only for software products, but also for books, videos, articles, educational materials, etc. All this significantly complicates and slows down the development of the industry, but over time the availability of knowledge irreversibly grows, they seep into free circulation on the network through popularizers, enthusiasts and the free software movement.

content/en/2-9-Tasks.md

@@ -1,3 +1,47 @@
 ## 2.9. Tasks
 
-No translation
+`Task 1.` Let's take an example that we have already considered, but with several errors added to it. Copy this code into a separate file and fix it so that it not only works, but is beautiful and understandable. You can take the code from the book and lectures as a reference.
+
+```js
+const Items = [
+  { CENA: 40 } ,{ CENA : 120 },{
+  CENA: '505',
+  }, { CENA: 350 }];
+
+For (const ITEM of items){
+console.log(`Price: ${item.price}`);
+}
+```
+
+`Task 2.` Now let's make a function that will calculate the sum of the entire purchase. Give the function a clear name and add such rules: we need to check if the price is a number (using `typeof`), we sum only positive prices, and if we find a non-number or negative number, we throw an error using `throw`.
+
+In the course of completing the task, search the internet for documentation on `for..of`, `throw`, `console.log`, functions and arrays. It's best to search in MDN (Mozilla Developer Network).
+
+Make sure the code runs in the command line through node.js or in the browser.
+
+`Task 3.` Take this data structure and supplement it with products and product groups following the example of those that already exist:
+
+```js
+const purchase = {
+  Electronics: [
+    { name: 'Laptop', price: 1500 },
+    { name: 'Keyboard', price: 100 },
+  ],
+  Textile: [{ name: 'Bag', price: 50 }],
+};
+```
+
+Put the code in a file and output the entire structure to the screen by running the code in node.js or the browser.
+
+`Task 4.` Write a `find` function that will go through the structure from the previous task and find a product by its name (checking all product groups). Names can be repeated, but this time we are only interested in the first product whose name matches.
+
+Example of using the `find` function:
+
+```js
+const result = find(purchase, 'Laptop');
+console.log(result);
+```
+
+Should output: `{ name: 'Laptop', price: 1500 }`
+
+`Task 5.` Now let's expand the previous task: we need to modify the `find` function so that it returns an array containing all products with the specified name. If none are found, then an empty array.

content/ru/Index.md

@@ -86,7 +86,7 @@
     10.6. Асинхронная и параллельная совместимость  
     10.7. Подход к передаче сообщений и модель акторов  
     10.8. Асинхронная очередь и асинхронные коллекции  
-    10.8. Lock-free структуры данных
+    10.9. Lock-free структуры данных
 11. Дополнительные парадигмы программирования  
     11.1. Обобщенное программирование  
     11.2. Событийное и реактивное программирование