Stack Overflow Blog 发表的一篇文章呼吁重新审视模型导向编程（Model Oriented Programming）这一概念，将其视为一种能够把系统需求与软件设计分离开来的方向，并随后利用模型本身协助创建和维护系统。作者以自身经历为基础：13年前，他曾开发出一种名为 Mo+ 的语言和开发环境，并表示曾将其用于企业项目，但这一理念并未得到广泛传播。
本文并不是对某种可用语言或新研究项目的宣布，而是呼吁在这一领域开展更多研究与开发，尤其是在人工智能日益重要、软件系统日益复杂的背景下。
作为结构和数据的模型
作者建议通过两个要素定义模型：用于规定规则或模式的结构，以及遵循该结构的数据。结构具有层次性，从根节点开始，分支为节点和属性；必要时，一个属性还可以引用另一个节点。按照这一视角，关系数据库模式可以用层次结构表示，其中包含数据库、表、列和键等节点，即使数据本身分布在行和关系之中。
文章使用一个简化的餐厅场景来说明这一理念，其中包括餐厅、客户、员工、菜单项及其相互关系。文章展示了表示同一场景的多种可能结构，并指出，结构的选择会影响遍历模型的便利程度，以及编写依赖该模型的程序的方式。
模型导向开发的四种形式
- 非正式建模：存在于头脑中、纸面上或图表中的模型，软件工具不会直接使用这些模型。
- 嵌入式建模：存在于代码中的模型，例如 Entity Framework 和 NHibernate 等 ORM 框架，或 Angular 和 React 等用户界面框架中的模型。
- 耦合建模：外部模型，通常使用 UML，并与代码元素及其管理工具保持紧密联系。
- 分离式建模：专注于需求、数据和工作流的模型，而将代码的详细设计留给代码本身，因此模型中的每个元素不必对应某个特定的软件组件。
作者认为，耦合建模和分离式建模，尤其是后者，具有更大的潜力，因为它将需求置于模型中、将设计置于代码中。作者表示，个人经历使他认识到，这种分离让建模和编程过程更加顺畅。
从模型到系统
文章将模型导向编程的使用分为三个领域。在转换型模式中，程序解释模型，并生成源代码、配置文件或文档，以便之后继续开发。在模型建模模式中，语言帮助创建和维护模型的结构及其数据。至于目标模式，则直接使用该语言构建和管理系统环境，这要求语言更加完整。
所提议语言的特性
其中一项主要建议是将模型结构作为语言规则的一部分，从而可以直接处理 Entity、Property 和 Relationship 等节点，而不必创建专门的类和对象来表示它们。作者还建议采用模型上下文，根据程序在数据树中的位置确定上下文，并通过一个栈实现向上访问父节点，或向下访问和搜索子元素。
另一个理念是“模型导向属性”，即与特定节点类型关联、可以在多个实例上求值的独立代码片段。可以组合这些属性来生成代码，例如创建类定义或其属性，也可以将它们用于搜索和筛选操作。在转换型模式中，该属性可能包含一个put操作，用于将结果保存到文件或目标环境中。
作者还建议采用动态规则：解释器在编程会话开始时，将模型节点及其属性加入语言规则。当标准模型不包含足够信息，或模型特定于某个组织或领域时，这一机制会很有用。作者还提出了上下文规则，用于限制程序不同部分中允许执行的操作，从而减少副作用，并分离读写职责。
这一构想为何重要？
这一理念的实际价值在于尝试让模型具备可执行性，而不只是成为与开发流程相分离的设计文档。如果能够将需求、数据和工作流与可复用的生成及维护机制联系起来，就可能减少模型与代码之间的重复。但文章并未提供标准化语言、可用工具或对比结果来证明这一方法优于现有的建模和代码生成框架。
一些重要问题仍然悬而未决：如何管理大型且不断变化的模型？如何测试生成的代码？从可读性、安全性以及与开发工具集成的角度来看，动态规则的边界是什么？因此，与其说本文是一套可立即使用的现成解决方案，不如说它是对语言开发者和研究人员具有价值的研究倡议。