Context programming language with multiple interfaces

Currently, we are talking about the possibility of the program working in different contexts, with different interfaces.

Several infrastructures have been described, independently of each other, and developed in different ways, but at the same time are related to each other.

The most commonly cited example of justifying such a search is the case of program testing. If it has a graphical interface, it is difficult to implement a script to automate testing and handle all possible uses. But if the program has a dual interface system, you can use such scripts with a command line interface suitable for them.

You can also see an application in the field of robotics that would significantly speed up machine learning. The software that makes the robot work would have a hardware interface on one side and a virtual version of the robot on the screen on the other. Then the instructor could develop the behavior of the robot on the computer, with the same program that makes the real machine act.

Pure architecture for software

"Pure Architecture." The program translates the work of the action with objects representing the business, but it does not depend on frameworks, user interface, databases. Each of them is interchangeable, one interface is different, one database manager is different.
The program can be tested using a test interface.

This architecture is represented by concentric circles with a program that is completely dependent on the activity for which computer processing is being performed.
The second circle is a set of use cases. They are issued by other programs that use the central program, but do not affect its design.
The third circle is a set of adapters for interfaces. They receive data and format it for processing by the nearest circle, the second. It works backwards.
The fourth and outermost of the circles includes frameworks, databases, and a user interface.

This architecture can satisfy our need for a unique program with several contexts, but it is quite general, it remains to be determined how to implement it and it is not related to the programming language, but only to application programs.

Hexagonal architecture

Or "Hexagonal Architecture." She also has concentric figures, but here they are hexagons. The central hexagon is an application. It is included in the second, which is a set of adapters. As in the previous case, they prepare data for transfer in both directions between the application and external tools. These are frameworks, databases, user interface.
She also plans to have a special interface for test batch scripts, they are associated with the application with a specific adapter, while the user interface also has its own adapter.
The concept of a hexagon has a connection with the implementation of the infrastructure. Each face corresponds to a port. The port has a protocol to communicate with the agent type. Adapters have a port for communication with the database, a port for the interface. The central program has ports for communication with each adapter.
The hexagonal figure is actually symbolic. The number of faces depends on the number of ports, there are not necessarily 8 of them, this is a fundamental figure.

Having laid the port principle, we are close to implementation. A port can be a method of an object, and an object has methods for each port.

So the problem of robotics is solved using one port dedicated to a specific robot, another - a virtual robot. The latter is associated with a framework that programmatically adds the laws of physics (gravity, collision) to the movements of the robot.

With hexagonal architecture, it remains to use classical programming languages. But with PCI architecture, things can change.

PCI, context data interaction

DCI, or Data Context Interaction, wants to rewrite the orientation of programs to an object to replace objects with roles that are more adaptable and general. Because objects are suitable for representing structures, but not systems in action. They are static, while you want to virtually imagine a moving world .

PCI can be seen as an addition to Model View Control, it is actually the same person, Trygve Reenskaug is considered the inventor of both models.

Data is all the elements that describe the system. This data is represented by objects that actually return the mental representation that the programmer or expert has. But they are used in different areas, the same data put ideas, and therefore different objects. Therefore, you must migrate everything contextual and usage-dependent on the object in the instance.
Roles are created for this. The same object has several roles corresponding to different usage types. The role has usage-specific methods. But it is generic, applied to abstract variables.

And the action, the dynamics of the system? The action is represented by roles .
According to the developer of the TIN, if the concept of roles was not accepted in programming (unlike the MVC model), then this is because languages ​ ​ are focused on classes, not objects. (Ref: Trygver). Classes describe conceptual models and their properties, but do not capture their interactions and the resulting complex system. They could be carried out by exchanging messages, which will be determined by the contribution to a particular goal and the contribution appropriate to the context .

Even if roles can be imagined with current languages, this is something that should be added to the new language initially, such as independent construction. The author tried to achieve this using BabyUML .

It is based on UML, a model that defines itself like this: program = data structures + algorithms + communication.

Data is represented by objects, but the programmer also describes the relationship between these objects. Finally, algorithms are the processing of data obtained as a result of requests.

One interesting aspect of the Renscauga system is in this sentence:

A universe of objects that exist in space and time and where objects appear and disappear as needed.

This is well suited for robotics, since the robot is in the developing world, and not in the universe, which starts again every time you turn on the robot, as happens with computer programs.

Remember that the relationship between objects that makes a system so must be formalized independently of objects. For example, you can describe an action as an exchange of messages between objects, each of which is sent from information on which it depends. This can be implemented by object methods, but ideally, and this is the principle of roles, it would be implemented separately as a method of roles. An object can be superimposed on a role to participate in a task or achieve a goal.

In conclusion, it should be noted that languages ​ ​ with a very high level of the future, especially if they want to be adapted to robotics, as will be the case with Scriptol II, will need to move to a representation model different from the representation model of classes and objects, which is more dynamic and able to represent knowledge about a specific world of interaction.
Preserving this ever-renewing representation of a dynamic and evolving world will require enormous memory.

Denis Suro on January 4, 2014.