开发者发文呼吁研究面向模型的编程语言

2026年10月9日 论面向模型的编程语言

十三年前，据我所知，我开发了第一个也是目前唯一一个功能完备的面向模型的编程语言和IDE。我利用这项技术（Mo+）在我自己以及工作单位的企业项目中取得了巨大成效，但未能将这些理念推广给更广泛的受众。六年前，我离开了软件工程职业生涯，转而挥舞斧头，在挪威、英国以及未来斯堪的纳维亚的其他地方建造维京船和盎格鲁-撒克逊船。即便如此，我仍然不时思考面向模型的编程及其潜力。

本文的目的不是介绍我所开发的技术，而是激发对面向模型语言的研究、开发和使用。除此之外，我非常希望能为大学或企业正在进行的任何研究做出贡献。如果你知道任何地方正在进行面向模型的编程语言的研究和开发，请告诉我！

我坚信面向模型的编程语言家族具有巨大的未来潜力，甚至——也许尤其是——在当前AI的世界中。我希望本文能激发人们对此类潜力的深入探索。

下面，我将概述一些我认为对充分利用面向模型的编程语言至关重要的原则和特性。除非另有说明，这些原则和特性并非纯理论，而是实际上已在企业系统中使用了多年。这里有许多概念需要讨论。如果前面的部分变得有些枯燥乏味，至少请跳到语言特性部分。

当然，模型有很多种，描述模型的方式也有很多。从核心上讲，模型的目的是简洁地表示比它更大或更复杂的其他事物。对于面向模型的编程，我们需要模型的电子化定义，可以使用以下定义：

模型——模型可以用结构和数据来描述。结构定义了模型的规则或“模式”，并且始终是层次化的。一个特定的模型由符合模型结构的数据填充。

模型结构可以简单地用节点和属性来定义：

你可能还不相信我所说的模型结构总是可以是具有单一根节点的层次结构。让我们以下面Northwind数据库的一部分图表为例：

你可能会说“这不是层次化的！！”但是，我们在这里看到的是什么？在我们的语境中，这不是模型结构，而是模型数据！你可以说Northwind数据库模式是用数据填充标准关系数据库结构的一个例子。数据库表中的数据行是运行时数据，不是我在这里讨论的内容。模式才是模型数据的一个例子。

你可以在关系数据库IDE中看到层次结构，因为模式可以以树形视图显示：

因此，关系数据库的模型结构包括数据库、表、列和键等节点，它们整齐地构成层次结构。你可能会说“等等，层次结构被打破了，因为外键引用了表！”这可以通过以下方式非常简单地进行处理：

有了上述规则，我们可以拥有非常复杂的模型结构，并且它们能整齐地构成层次结构。我还要补充一点，在良好的模型结构定义中，节点应定义在它们能够独立存在的最高层级上。

在本文的剩余部分，我们将使用一个非常简化的餐厅场景，我们将以各种方式对其进行建模，并解释如何用面向模型的编程语言针对该场景进行编程。

简化的餐厅场景描述如下：

以下是一个实体关系模型（采用伪Shlaer-Mellor格式），展示了这个场景：

再次强调，在我们的场景中，这个模型代表的是数据，而不是结构。那么现在让我们进入一些模型结构的内容！

考虑以下实体关系图，它可以表示一个支持上述模型数据的结构：

该结构有一个Model根节点，以及Entity和Relationship等子节点。实线表示模型结构的层次关系，虚线表示交替关联（注意，对于这些关联，我需要添加一些引用属性来“形式化”它们）。在填充此结构时，Entity的实例包括Restaurant、Customer、Staff等，Restaurant Entity属性的实例包括Id、Name和Location等。

这是表示我们数据的唯一或最佳结构吗？当然不是，有很多可能性。考虑以下替代的实体关系模型结构：

这个结构将Entity、Relationship和Property放在同一层级。如果关系和属性可以独立于实体而存在，这可能是合理的。

最后考虑这个替代的实体关系模型结构：

在这个结构中，关系和属性需要一个实体才能存在，并且关系是源实体的子节点。我提出替代结构的原因是，这对面向模型的编程语言有一定影响，在层次结构中遍历稍微更方便一些。这将在后面更详细地解释。

我强烈认为，从结构和数据的角度定义模型是一个极其重要的基础原则，它开启了一个面向模型的编程语言家族。随着我们下面的深入探讨，我将解释更多。

在我们继续之前，这里还有几个定义：

建模——建模可以简单地定义为用数据填充模型结构的过程。

面向模型的编程（MOP）——MOP可以简单地定义为利用模型来创建和维护系统（就本文而言，即软件系统）的过程。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）