The future of MPS is in focusing on being a language workbench for two kinds of languages.

Because MPS was originally intended as a “secret weapon” for JetBrains to build its IDEs with, it creates tools that run on the IDEA platform. Thanks to that it can also be partially written in itself and use its own power, a quality that I will later refer to as bootstrapping.

However, the end users today want to work in a collaborative, Web-based platform. Tooling based on MPS, and thus on the IDEA platform, is quickly growing inadequate.

The future of MPS lies in acknowledging that the end users of MPS-based tools are a different group of people than language developers, with different requirements. This means that we need two language workbenches in one.

MPS should continue supporting MPS-based languages that improve the life and productivity of language developers (let’s call them developer languages). The role of languages developers is to work on a different set of languages, those that run on a cloud-based platform (let’s call them cloud languages).

This platform has yet to be developed. Markus Völter has some time ago outlined his vision of it.

Out of the current MPS language aspects, almost all are unfortunately not easily portable to a different platform because their definition languages use opaque fragments of Java code that may be tied to the existing runtime. This applies to behavior, constraints, editor, typesystem and other aspects, with the single exception of structure.

Therefore, in the short term, a separate set of meta-languages will have to be created to describe the cloud languages. In the long term we could benefit if there is only one set of meta-languages, but we may also suffer if it increases conceptual complexity due to the metacircularity involved.

As mentioned above, MPS should remain the tool of choice for developing both developer and cloud languages, for two reasons:

  1. The cloud languages and tools are not going to be powerful enough to support language development, either initially or ever, because that is not their intended focus.

  2. As a developer, I cannot (yet) imagine developing languages in a simplified Web-based IDE in Google Docs collaborative style. I appreciate the full-featuredness of a desktop IDE. I also appreciate version control with its branches, commits, rebases and merge conflicts. And I appreciate continuous integration with tests.

Speaking of continuous integration, it should still be possible to run a local version of the cloud application and get rapid feedback. This is a benefit of the bootstrapping quality of MPS that must be preserved. We must not wait for 30 (or even 5) minutes until the full application is built and deployed to a server before we see the effect of a simple change. At least 90 % if not more changes must be applied (in a development environment) in under a second.

There are plenty of examples of Web frameworks and tools supporting hot reloading. Flutter offers it for desktop applications, and JRebel for Java, so this goal should be within reach.

Another important feature of MPS that must be preserved is language composition and extensibility. However, this is enabled not so much by bootstrapping as by the projectional, parserless nature of language definitions and the platform that provides runtime extension capabilities via dynamically adding or removing extensions. The cloud-based platform should ideally use the same overall design principles.

I want to spend some time over the next few months investigating and prototyping such a cloud-based platform, to see how far I can get. Fortunately, some of the problems are already being solved, with Modelix focusing on model persistence and ProjectIt on projectional editing (and that’s not including the dozens of distributed database solutions and Web development frameworks). What is missing is the Active Repository as outlined by Markus in the article linked above, and this is the part that I intend to focus on.

Thanks to Markus Völter for reviewing an early draft of this email.