Mirages of the future

    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 must remember him, he wrote a lot about Pascal), to design 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 condition it is, but I decided to try to resume the discussion by publishing part of our correspondence.

    Ruslan on his blogin a post No. 30 he talked about Turchin’s theory of metasystems. It seems to me that it can serve as an excellent tool in the design of both the 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 leap in the complexity level of a certain system. It is possible then to consider the evolution of computers, OS, and programming languages ​​in terms of the presence of such meta-transitions.
    For clarity, we draw an analogy of computer systems with live ones, all the more so since many 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 unicellular organisms. Their capabilities are limited by performing elementary computational operations and manipulating memory cells, i.e. “Unicellular” take “amino acids” from the environment, etc.

    With the increasing complexity of such “unicellular”, the first meta-transition arises. Programs begin to write in high-level languages, i.e. tools that hide many elementary operations under the shell of language structures. This is the emergence of "multicellular organisms." The hardware begins to disengage from operating systems. Those. The “nutrient medium” for programs is also becoming more complicated, these are not direct CPU commands or operations with memory cells, but requests to the OS to allocate memory or perform trigonometric calculations. So, the first meta-transition is the emergence of imperative languages ​​and OSs that hide 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 such as memory areas.

    Why do 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, a program operates not so much with memory areas and computational operations as with system states and actions for changing it. And in logical languages, calculations are also “hidden” from us. Those. in my opinion, functional languages ​​should have been replaced by imperative as a result of a meta-transition, and they, in turn, would be replaced by logical ones. But a meta-transition is possible only when the whole system is ready for it, and the hardware capabilities and organization of the OS are not ready for this.
    As in any complex system, in programming different levels of control will be distinguished leading to different meta-transitions. If functional and logical methods can be considered as a meta-transition in the organization of the program process, then the emergence of structural 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, maybe you can take the object approach as another meta-transition, because he added a new mechanism for increasing the complexity of subsystems - inheritance. But here the issue is complicated by the fact that although inheritance allows you to increase the multi-level system, organize more subsystems, it does not add a new level of control for emerging subsystems. Those.,
    Rather, inheritance, and polymorphism, can claim the role of a meta-transition. It allows you to simplify program management, as allows you to reduce the number of designs that dispatch calls to specific methods. Moreover, if we take into account the internal construction of polymorphism, dynamic polymorphism in the SmallTalk style is most suitable for this. It is appropriate here to mention an interesting option proposed by Dr. Professor A.I. Legalov from the Siberian Federal University (I saw this idea from him). He proposed building polymorphism not from an object, but from a method. That is, in its version, the construction of "Method. Essence ()" is obtained.
    Why does such an approach seem more promising to me? The number of possible entities can be unlimited. Our imagination of creating 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 inheritance and do not pass type 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 let's digress for a while from our program organisms and return to the OS environment. Having organized the primary broth of amino acids from the memory cells and processor resources into a kind of vegetation in the form of API sets, the operating systems stayed at this level for a long time. The only significant meta-transition can only be called the emergence of a UNIX-like unification of the representation of all resources as files and the reduction of many operating system actions to read-write operations. It is the presence of such a meta-transition in computer resource management that served as the incentive for the popularity of the UNIX model. And it is precisely the lack of qualitative differences in organization and management that does not allow us to talk about the advantages of Linux over Windows - these are the systems of the same type.

    However, the development of the 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 bring the organization level of programming languages ​​and OS organization into line that led to the emergence of projects such as Apple's OpenDoc architecture or BeOS system. In fact, the success of the Java and .NET platforms is due precisely to the presence of a qualitative leap in the organization by representing all the resources of the environment in the form of a set of high-level objects. Those. we can say that the fauna of the objects has appeared in the API flora. It turned out an interesting picture, “organisms programs” (complex organisms created in OO languages, that is, consisting of complex subsystems of the “brain”, “stomach”, “limbs”, etc. ) try to survive and function among other organisms of other OS programs and resources. The animal world in all its splendor and diversity.

    Let's make one more “parallel” look. If meta-transitions were carried out in controlling the complexity of programming languages ​​and OS devices, then in the fight against 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 the version control system did not go beyond the narrow circle of professionals. And Microsoft’s attempts to create a database-based storage system are just glimpses of the meta-transition in managing the number of information units.

    And so, what do we do?
    Here are the meta-transitions we highlighted:
    • Languages ​​(computer operation control): imperative functional logical.
    • Languages ​​(program complexity management): structural programming is modular-object.
    • OS: sets of API sets of objects.

    And now, I allow myself the audacity to formulate such a theorem:
    The success of a new system is possible only if it has a new meta-transition in comparison with the old system!

    But due to what qualities such a transition will be made, it requires additional and lengthy reflection ...

    Returning once again to Turchin's theory, we recall that the meta-transition is characterized by a simplification of control in a more complicated system. To some extent, this echoes the ideas of Stafford Beare about the organization of a cybernetic system in which each previous level serves to isolate from the general data stream only key parameters in order to reduce the information load to the next level. That is, the main incentive for development is the fight against complexity! And the meta-transition is a successful solution in this fight. Therefore, to determine development goals, it is necessary to identify the levels of complexity that need to be simplified to obtain a new quality of the developed system.

    Based on these considerations, I will dare to formulate the following theses.

    OS complexity (kernel):

    1. Abstraction from the hardware platform to simplify the transfer to different equipment.
    2. Effective distribution and use of available resources (memory, processor time, etc.). Perhaps in the context of the dynamic change of these resources.
    3. Organization of the implementation and interaction of processes. Parallel operation on one processor or parallelization on several. Interaction of parallel operating equipment. Distribution of processes among network nodes.
    4. Organization of shared libraries.
    5. Version control of used libraries. Perhaps sharing libraries of different versions.
    6. Dynamic reboot of working modules.
    7. Handling software and hardware errors.
    8. Providing the minimum required set of application interfaces that fit into a single use paradigm (as for example done in OS Plan 9).

    The complexity of the programming language:

    1. Organization of computing. This includes expressions, control flow control, concurrent execution, exception handling, etc. Those. exclusively "counting" aspects of work. This also includes typing as a means of making it easier to get more platform-optimized code.
    2. Reuse of the code, 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, templates, namespaces, etc. As well as typing, as a tool for ensuring the consistency of interfaces. Those. all mechanisms that allow, instead of repeatedly repeating the same instructions in different places of the program, to put them in one place and write down once.
    3. Reuse of the code, from the point of view of implementation (i.e., run-time mechanisms for invoking such code). Here, calling procedures, sending messages, and on the other hand, transferring data to such a code (i.e., transferring the actual parameters to a procedure or transferring data to another process, possibly working on another node). And also - polymorphism, as a mechanism for applying a single algorithm to different data.
    4. A 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 working with data.

    OS complexity (user interface):

    1. A model for organizing data storage. It was one of the first tasks of the OS. First of all, these are file systems in the future moving to some kind of DBMS.
    2. It is completely unsolved in modern operating systems, but in my opinion the extremely urgent problem of multi-versioning of user data and tracking the history and the relationship of their changes. For example, integration into the OS of systems such as the "Life Line".
    3. The mechanisms of user interaction with the OS. From the command line to graphical interfaces. If we consider this aspect in the framework of the paradigm “Model - view - controller”, then all “out-streams” are “view”, and all “in-streams” are “controller”. Ideally, the OS should itself adapt the program to the used “view-controller” bundle, i.e. the same program can work in a text terminal, on a full-sized PC monitor or on a smartphone’s display.

    Ugh, like this, as a first approximation ... It may very well be that I missed something, but here it is difficult to do without looking from the side.
    Maybe the questions raised are interesting to someone and he wants to continue the discussion?

    Also popular now: