An article published on the Stack Overflow Blog calls for reconsidering the concept of Model Oriented Programming as an approach that can separate system requirements from its software design, then use the model itself to help create and maintain the system. The author draws on an earlier experience in which, 13 years ago, he developed a language and development environment called Mo+, saying that he used them in enterprise projects without the idea becoming widely adopted.
The article is not an announcement of an available language or a new research project. Rather, it is a thesis calling for more research and development in this field, particularly in a context where artificial intelligence is becoming increasingly important and software systems are becoming more complex.
The Model as Structure and Data
The author proposes defining a model through two elements: a structure that specifies the rules or schema, and data that conforms to that structure. The structure is hierarchical, beginning with a root node and branching into nodes and properties, with the option for a property to refer to another node when needed. From this perspective, a relational database schema can be represented hierarchically through nodes such as the database, table, column, and key, even if the data itself is distributed across rows and relationships.
The article uses a simplified restaurant scenario to explain the idea, involving restaurants, customers, employees, menu items, and the relationships among them. It presents more than one possible structure for representing the same scenario, explaining that the choice of structure affects how easily the model can be traversed and how programs that depend on it are written.
Four Forms of Model-Oriented Development
- Informal modeling: Models in the mind, on paper, or in diagrams that are not used directly by software tools.
- Embedded modeling: A model inside the code, as in ORM frameworks such as Entity Framework and NHibernate or user-interface frameworks such as Angular and React.
- Coupled modeling: An external model, usually using UML, that is strongly linked to code elements and the tools used to manage them.
- Separate modeling: A model focused on requirements, data, and workflow, while leaving the detailed design to the code, so that each model element is not linked to a specific software component.
The author believes that the greatest potential lies in coupled and separate modeling, particularly the latter, because it places requirements in the model and design in the code. He says that his personal experience made the modeling and programming process more fluid.
From the Model to the System
The article divides the use of model-oriented programming into three areas. In the transitional mode, the program interprets the model and produces source code, configuration files, or documentation that can be developed further. In the model-modeling mode, the language helps create and maintain the model’s structure and data. In the target mode, the language is used directly to build and manage the system environment, which requires a more complete language.
Proposed Language Features
One of the main proposals is to make the model’s structure part of the language’s grammar, so that nodes such as Entity, Property, and Relationship can be handled directly instead of creating special classes and objects to represent them. The author also proposes a model context based on the program’s location within the data tree, with a stack that allows movement up to parent nodes or down to child elements and searching among them.
Another idea appears in “model-oriented properties,” which are independent pieces of code associated with a particular node type and capable of being evaluated against multiple instances. These properties can be composed to produce code, such as creating a class definition or its properties, or used in search and filtering operations. In the transitional mode, a property may include a put operation to save the output to a file or target environment.
The author also proposes dynamic rules in which the interpreter adds model nodes and properties to the language grammar when a programming session begins. This is useful when the standard model does not contain enough information, or when the model is specific to a particular organization or field. He also proposes contextual rules that limit the operations permitted within different parts of the program, in order to reduce side effects and separate reading and writing responsibilities.
Why Does This Proposal Matter?
The practical value of the idea lies in attempting to make the model executable rather than merely a design document separate from the development lifecycle. If requirements, data, and workflow can be connected to reusable generation and maintenance mechanisms, duplication between the model and the code may be reduced. However, the article does not provide a standard language, available tools, or comparative results proving that this approach is superior to current modeling and code-generation frameworks.
Important questions remain open: How should large and changing models be managed? How should generated code be tested? And what are the limits of dynamic rules in terms of readability, security, and integration with development tools? For this reason, the article appears more like a valuable research invitation for language developers and researchers than a ready-to-use solution for immediate adoption.