Hi all,
yesterday, I came across this blog post on domain modeling.
TL;DR -> The author was looking for a modeling tool to get an overview and tame the complexity of a microservice architecture, the services and their interfaces, etc.
After looking into UML, C4, and structurizr for Java, he decided to build his own tool, since none of the ones mentioned really addressed his needs. And, boom!, ony 15 months later he had his first prototype he wanted to share.
Now, I want to make sure that you understand I donât want to mock the author in any way and I think what he has built is really pretty cool (he basically built a framework to define your own meta models and models using internal DSLs in groovy with nice visualization support).
But I couldnât help and wonder why he didnât consider using a language workbench. So I asked him, and he told me that, even though he didnât mention it in his article, he looked into Xtext and MPS, but concluded that the learning curve for both himself and his eventual users would have been to steep.
I donât blame him for this assessment, I donât know how much time he actually had available in the 15 months it took him to implement his own solution, and I can certainly understand that the idea of building your own meta modelling framework might have been just too exciting to even consider an alternative, but what this example shows me is that there is still no âkiller exampleâ out there that could be considered a blueprint for people that start at a very similar point than the author of above article.
So, I sat down yesterday and used MPS to implement a (basic) language based on one of his meta models he shares in his repository.
Of course, I was able to just copy his meta model structure-wise, but I think it might still be a nice area to follow up on and create a tutorial and show step-by-step how easy it is to build a language like that with a language workbench.
Here is my current implementation.
Let me know what you think about this story and this particular use case to build languages for.
Iâll have a look at it some time next week, no time today unfortunately.
Interesting observation about MPS and XText learning curve. I had some trouble getting XText to do what I wanted, for lack of documentation (10 years ago), but I also ran a workshop at the Eindhoven University for post doc students, a few years in a row. That 2 day workshop was sufficient to get them going with defining languages and generators (the âcaseâ covered a generator, a simple Java platform I provided, and three different but related languages).
Naturally, the experience might greatly differ for different people. With âlearning wallâ I was referring to the problem I hear often when people just donât know where to start when it comes to LWBs.
What also needs to be differentiated is:
actual learning curve
perceived learning curve
projected/estimated learning curve (as âhow complexâ a technology is perceived by people researching their options)
what level of âmasteryâ one pursues
I personally find the last bit to be something that isnât really discussed in a meaningful way. Language Workbenches often allow you to quickly prototype language ideas, and in some cases one can even create quite impressive demos rather quickly, and thatâs great. In the end, the whole topic of language engineering is inherently complicated though. Hence, I think it is also important to accept that, in order to really build a shippable product with the help of a language workbench, one has to invest a certain amount of effort into learning the technology. This is true for other technologies of the same level of complexity as well, but for some reason, my personal experience is that many are just not willing to invest the same time and effort they invest into learning a new GPL, for example, into learning a language workbench. The âwhyâ behind that is really the question that is interesting to me.
Thatâs not to say that there is still room for improvement when it comes to LWB documentation and UX.
I have been thinking about ways to enable non-language-engineers to define languages, and some time ago was implementing âfront-endâ language workbench Language Wheel, mainly for teaching purposes. Here is a blog post on it:
It took me at least months to learn how to use Xtext and years for MPS, having a lot of time to dedicate to them. In the meantime the documentation improved but still⌠the resources available are also not necessary easy to find for newbies. On Xtext there is a book from Lorenzo Bettini, on MPS a course from JetBrains itself. I am not sure how many persons looking at these tools know about these resources
Interesting. I actually found the learning curve for Xtext and MPS very different. Xtext is relatively easy to get into and MPS rather hard. Of course, when using more advanced features of Xtext things are getting harder.
For me Xtext was difficult also because it was my first experience with MDD and DSLs. I also had the impression that until you do âstandard thingsâ you do not need to understand a lot about EMF, OSGi and all the rest of the platform but at some point you need to dive into that and you see there is a lot of complexity. With MPS you have instead to face that complexity right away and it is a bit more âalienâ to the typical developer
Both tools and the ecosystems they live in are inherently complex, so I think it really depends on ones previous experience and way of thinking how hard it is to get going.
Xtext is certainly closer to CoCo tools and uses a grammar language similar enough to BNF so that many people have something they can immediately grasp, use, and move ahead from a central point.
MPSâ approach towards language engineering is rather different, and I think having to use projectional editors whilst learning how to build projecitonal editors, M2M transformations, etc., is just rather different from most other tools.
The different aspects of a MPS language (structure, behavior, constraints, typesystem, etc.) also lack a common, overarching UX concept and I think it is therefore harder to many people to build a âmental modelâ where everything belongs in MPS.
I had the discussion in the past where I wanted to build a âsimplified, common editor layerâ for the most important languages used in MPS to define languages, and I even dabbled around with a first prototype, but I didnât get enough feedback on whether or not this is something the community wants/ the workbench needs to actually move forward with the implementation.
Projectional language workbenches appear to have a higher (perceived) âlearning wallâ than more traditional, text-based ones. It might be because weâre steeped in a text-only approach from early on, but also because projectional just involves more âstuffâ that you more-or-less get for free in the text-based approach because youâre grafting a language on top of a pre-existing textual editing framework, i.e.: the text editor provided by your IDE, possibly in combination with LSP or something similar.
Once you know where all the stuff is, projectional seems to be (arguably!) conceptually simpler, in the sense that the âgrafting on top of a text editorâ is a relatively complex business. But getting there takes a rather long time, and indeed: itâs not helped by an apparent lack of cohesive UX and architectural principles. On the other hand: MPS is a lot simpler than the Intentional Domain Workbench.
Robert (@digital-ember), an abstraction on top of MPS that captures, letâs say, 66% of everything there is, would certainly be good to have. Itâs easy to get lost in all the various possibilities that MPS has to solve a problem.
Even though we have been improving the tutorials (also create a free online course), the learning curve has always been one of the weak points of MPS. I see two main challenges for newcomers (language developers):
Itâs hard to assimilate the idea of a non-textual editor.
They donât see the big pictures of the DSLs. I have heard a lot of similar comments praising the technology but saying that they donât know how/where to use it.
We have some on-going work to address the second challenge. If you have more ideas, feel free to contact me.
For me, itâs hard to assimilate the idea of people finding a non-textual editor (in the context of modelling languages) hard
In my experience, that seems to be true for most regular devs, whether they have been steeped in parsing stuff, or not. Maybe the frontend-type devs have an easier time, since theyâre using to visualising data in a nice way, and providing interaction with that, which is a large part of what projectional is.
Iâm setting up a series of trainings on topics that I work on/with the past 10 years, adding a 2 day tutorial on using an LWB might be part of that. I hope itâs ok I borrow some input for that from here?
Completely agree on this. I think that text-only approach based on parsing is a legacy we have been stuck in due to ubiquity and pervasiveness of plain text. The future is in projectional editing but we have to figure out how to get there.
Maybe we should start bottom-up to replicate the success of text-only approach by:
Making a simple, compact, binary storage format for generic graphs
Make standard unix-like tooling to manipulate those graphs (like grep, awk, sedâŚ) with support for piping graphs between the tools.
Start developing generic graph editors so the users could easily open graphs, navigate them and edit them in a generic way (think of it as editing text without all IDE support, coloring and stuff).
Develop generic graph version control
Projectional editing would be just a logical step forward in interpretation of graphs in a domain-specific way. Think of it as what was done with IDE with plain text by providing Intelisense, syntax coloring, navigation etc. for a specific language.
This is just a dream (or maybe a complete nonsense) but maybe one dayâŚ
I will try to think about how to identify and approach these 66%. My main issue certainly is that I feel like itâs not worth it since there are just not enough people interested in it.
I think these are two well identified issues. Iâm curious to learn how you plan to address the second one. My knee jerk reaction would be to create very small, specific, yet relatable examples. I know there are many examples out there and MPS ships with a bunch of examples, but maybe there should be more in the vein of the voice recording example, which is more holisitic and addressing a real use case.
Also, terminology and didactics are important. I think it would be worth a try to market MPS less as a language workbench / language engineering tool / language engineering platform and more like a âproductivity platformâ. Then again, I donât know anything about marketing and its psychology, itâs just a gut feeling to try and be less technical. Maybe it would be good to not even lead with the whole projectional approach, but keep it as a side note, while still advertising the benefits it brings (again, Iâm basically saying âprojectionalâ maybe just an unrelatable term).
To deal with the second point we are creating a new section of Case Studies on the Landing page. These case studies would be short and concise from our current clients (here is an example).
We had similar approaches in the past but it was hard to get the content and permissions, but after some perseverance, we manage to get enough for the first version of the section. Though, we are still looking for more
I agree about the terminology, we are trying to avoid terminology like âlanguage workbenchâ on our pages. For âProjectional Editorâ, we are trying to explain the term. Our How it works page is one of the most visited and in there we try to give a comprehensible introduction to the technology. Let me know if you have any suggestions.
