In early 2008, with the filing of the State Duma deputies, a discussion arose on the Internet about the need to create a national OS. An initiative group emerged under the leadership of Ruslan Bogatyrev (all delphists should remember him, he wrote a lot about Pascal), for designing the Russian OS Rosa. I exchanged several letters with Ruslan, where I tried to express some of my thoughts. Unfortunately, the project stalled, as Ruslan explained due to internal organizational contradictions, and today I don’t know what his condition is, but I decided to try to resume the discussion by publishing a part of our correspondence.
Ruslan in his
blog in post number 30 talked about the theory of metasystems Turchin. It seems to me that it can serve as an excellent tool in the design and OS and programming languages. As I understand it, one of its key points is the concept of a metasystem transition that occurs during a qualitative jump in the complexity level of a certain system. It is then possible to consider the evolution of computers, OS and programming languages ​​in terms of the presence of such meta-transitions.
For clarity, we will draw the analogy of computer systems with living ones, especially since many people use this analogy, and the creation of programs is more similar to animal breeding than designing a car. Then the available hardware resources of the computer will represent, say, the primary bio-broth, in which the life of programs originates. The first programs in machine codes and assembler will act as the first single-celled organisms. Their capabilities are limited to the product of elementary computational operations and the manipulation of memory cells, i.e. "Unicellular" take from the environment "amino acids", etc.
With the increasing complexity of such "single-celled" the first meta-transition occurs. Programs start writing in high-level languages, i.e. tools that hide many elementary operations under the shell of language constructs. This is the emergence of "multicellular organisms". The equipment begins to abstract away from the operating systems. Those. The “nutrient medium” for programs is also complicated; these are no longer direct CPU commands or operations with memory cells, but requests to the OS for allocating memory or producing trigonometric calculations. So, the first meta-transition is the emergence of imperative languages ​​and operating systems that hide the small details of the hardware device, but still require an accurate and detailed description of the actions performed. Those. even though languages ​​have become more complicated, they still require operating with “small” entities like memory areas.
Why I highlight only imperative languages. In my opinion, the emergence of functional and logical programming is a new meta-transition in the language level. In functional languages, the program operates not so much with memory areas and computational operations as with system states and actions to change it. And in logical languages, “hiding” and computing are hidden from us. Those. In my opinion, as a result of the meta-transition, the functional languages ​​should have changed the imperative ones, and in turn they would have been replaced by logical ones. But a meta-transition is possible only when the entire system is ready for it, and the hardware capabilities and organization of the OS are not ready for this.
As in any complex system, different levels of control are distinguished in programming, leading to different meta-transitions. If functional and logical methods can be viewed as a meta-transition in the organization of the process of the program, then the emergence of structured programming was a meta-transition in the organization of subsystems and their interaction. Modular and object programming is the next transition in the organization of subsystems. Moreover, from this point of view, they are almost equivalent. Although it may be possible to take the object approach as another meta-transition, since He added a new mechanism for increasing the complexity of subsystems - inheritance. But here the question is complicated by the fact that although inheritance allows you to increase the multi-level system, to organize more subsystems, it does not add a new level of control to the emerging subsystems. That is, roughly speaking, at the program level, the “Entity. Method ()” construction does not change, and we don’t have any difference what is hidden under this entity - a module, parent object or descendant.
Rather, not inheritance, but polymorphism, can claim the role of a meta-transition. It allows you to simplify the management of the program, because allows you to reduce the number of structures that perform dispatching calls to specific methods. Moreover, if we take into account the internal construction of polymorphism, the most suitable for this is exactly the dynamic polymorphism in the SmallTalk style. It is appropriate to mention here an interesting variant proposed by Dr. Professor A.I. Legalov from the Siberian Federal University (I saw this idea from him). He proposed to build polymorphism not on the object, but on the method. That is, in its variant, the “Method. Essence ()” structure was obtained.
Why does this approach seem more promising to me? The number of possible entities can be unlimitedly large. Our imagination to create various software objects is limited only by our ability to keep such a system under control. And the introduction of new entities into the system, if they do not fit into the inheritance and do not undergo a typical control, will require the addition of new control structures. The number of reasonable actions on objects is much smaller and having developed a certain control scheme, it can be applied to all entities existing and newly created.
')
Now we digress for a while from our organism-programs and return to the environment of the OS. Having organized the primary broth of amino acids from memory cells and processor resources into a kind of vegetation in the form of API sets, the operating systems lingered at this level for a long time. The only significant meta-transition can only be called the emergence of UNIX-like unification of the representation of all resources as files and the reduction of many operating system actions to read-write operations. It was the presence of such a meta-transition in the management of computer resources that stimulated the popularity of the UNIX model. And it is precisely the absence of qualitative differences in organization and management that does not allow us to speak about the advantages of Linux over Windows, these are systems of the same type.
However, the development of an object model in programming languages ​​should have led to a new meta-transition in the OS representing its services as a set of objects. It is the need for such a transition to align the level of organization of programming languages ​​and organization of the OS, led to the emergence of projects such as Apple's OpenDoc architecture or the BeOS system. In fact, the success of the Java and .NET platforms is due precisely to the presence of a qualitative leap in an organization representing all the resources of the environment as a set of high-level objects. Those. we can say that the fauna of objects appeared in the API flora. An interesting picture came out, “programs-organisms” (complex organisms created in OO-languages, ie, consisting of complex subsystems of the “brain”, “stomach”, “limbs”, etc.) try to survive and function among other organisms. other OS programs and resources. Fauna in all its glory and diversity.
Let's make one more "parallel" view. If in the management of the complexity of programming languages ​​and the OS device meta-transitions were carried out, then in the struggle with the quantitative side, i.e. with the number of documents, programs, source versions, etc., there was only one general meta-transition the invention of a hierarchical file system. Unfortunately, programs like version control systems have not gone beyond a narrow circle of professionals. And Microsoft’s attempts to create a database-based storage system are glimpses of the meta-transition in managing the number of information units.
And so, what do we do?
Here we have identified meta transitions:
- Languages ​​(computer operation control): imperative functional logical.
- Languages ​​(program complexity management): structured module-object programming.
- OS: API sets of objects.
And now, let me insolence to formulate such a theorem:
The success of the new system is possible only if there is a new meta-transition in it compared to the old system!But at the expense of what qualities such a transition will be made, it requires additional and lengthy reflection ...
Returning again to the theory of Turchin, we recall that the meta-transition is characterized by a simplification of control in a complicated system. To some extent, this echoes Stafford Beer’s ideas about the organization of a cybernetic system in which each previous level serves to extract only key parameters from the total data flow in order to reduce the information load to the next level. That is, the main stimulus of development is the struggle with complexity! A meta-transition is a successful decision in this struggle. So, to define development goals, it is necessary to single out the levels of complexity that need to be simplified in order to obtain a new quality of the system being developed.
Based on these considerations, let me dare to formulate the following theses.
OS complexity (core):- Abstraction from the hardware platform to simplify the transfer to different equipment.
- Efficient allocation and use of available resources (memory, processor time, etc.). Perhaps in the conditions of dynamic change of these resources.
- Organization of the implementation and interaction processes. Parallel work on one processor or parallelization on several. The interaction of parallel operating equipment. Distribution of processes on network nodes.
- The organization of shared libraries.
- Version control of used libraries. Perhaps sharing libraries of different versions.
- Dynamic reloading of working modules.
- Processing software and hardware errors.
- Providing the minimum required set of application interfaces that fits into a single use paradigm (as for example made in OS Plan 9).
The complexity of the programming language:- Organization of calculations. These include expressions, flow control, parallel execution, exception handling, etc. Those. exclusively “counting” aspects of work. This also includes typing, as a means to make it easier to get more code optimized for the platform.
- Code reuse from the point of view of definition (i.e., how such a code is drawn up in the program). These are functions and procedures, modules and objects, inheritance, patterns, namespaces, etc. As well as typing, as a tool for ensuring interface consistency. Those. all the mechanisms that allow, instead of repeated repetition of the same instructions in different places of the program, put them in one place and write them down once.
- Code reuse, from the point of view of implementation (i.e. run-time mechanisms for calling such a code). Here, a procedure call, a message transfer and, on the other hand, data transfer to such a code (that is, transfer of actual parameters to a procedure or transfer of data to another process, possibly running on another node). And also - polymorphism, as a mechanism for applying a single algorithm to different data.
- Description of the types and data structures used. On the one hand, it is the "structuring" of memory. And on the other - the implementation of effective access mechanisms, ideally - uniform, i.e. ensuring polymorphism of work with data.
OS complexity (user interface):- Model storage organization. It was one of the first tasks solved by the OS. First of all, these are file systems in the perspective of moving to a kind of DBMS.
- Not solved at all in modern OSs, but in my opinion a very topical problem of multi-versioning of user data and tracking the history and interrelation of their changes. For example, integration into the OS systems of the type "life line".
- Mechanisms of user interaction with the OS. From command line to graphical interfaces. If we consider this aspect within the framework of the “Model - View - Controller” paradigm, then all “out-streams” are “view”, and all “in-streams” are “controller”. Ideally, the OS should adapt the program itself for the “view - controller” combination used, i.e. the same program can work in a text terminal, on a full-size PC monitor or on a smartphone display.
Uh, so here in the first approximation ... It may even be that I missed something, but here it is difficult to do without a glance from the outside.
Maybe someone raised the questions are interesting and he wants to continue the discussion?