Who is MPS for?

MPS was originally created for developers by developers. The idea was to give the developers the power to extend their mainstream languages (specifically, Java) with higher-level abstractions. So you would write most of the code in Java but where you need you would build a higher-level abstraction, say a sublanguage for strongly typed SQL queries, or a language for building your GUIs and binding actions to UI elements. You would build languages on top of languages on top of languages, raising the level of abstraction bit by bit, make fewer mistakes and thus write software faster.

This idea didn’t quite work out, though. Developers are used to working with text files, and for building custom languages they have had Lisp since the 60s, Racket since the 90s, and Clojure since the 00s. Not to mention Yacc, Bison, and ANTLR.

Using MPS would have required moving away from text towards an AST stored in XML, meaning you would no longer be able to edit your programs in Notepad or any IDE of your choice, and you would not be able to compare them using basic diff tools to review what changed. The prospect of doing this seemed daunting. Instead, developer tooling on top of text files got improved, so a modern IDE can type check your SQL queries for you to some extent, and specialized GUI builders covered desktop UI needs.

So if not for developers, who is MPS for? I consider MPS a tool for analysts working in complex domains. For people who are known as business analysts if you are in a bank, actuaries if yours is an insurance company, tax specialists in an ERP provider, and generically as subject matter experts if you’re doing domain-driven design.

What do all ideal MPS users have in common?

• They are not writing any production code themselves, only pseudocode or formulae at most.
• They already have a defined vocabulary of domain-specific terms they generally use.
• They produce structured or semi-structured Word documents to describe each requirement. These documents contain tables or calculations. Perhaps they produce Excel sheets directly.
• The documents they produce are not used as inputs to any software but rather as inputs to the software development process itself. The developers read them and implement what’s written.

Together, these factors indicate that the domain could be complex enough to benefit from MPS-based tooling. The more complex the domain, the greater the benefit.