Breaking the "learning wall" of Language Workbenches

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.

4 Likes

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).

2 Likes

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.

2 Likes

Indeed. This is a question that puzzles me, too.

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:

2 Likes

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

3 Likes

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.

3 Likes

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

2 Likes

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.

1 Like

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.

1 Like

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):

  1. It’s hard to assimilate the idea of a non-textual editor.
  2. 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 :wink:
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?

2 Likes

Hi everyone!
My book on Xtext (https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition) is actually mentioned in the very first page of Xtext documentation (https://www.eclipse.org/Xtext/documentation/index.html)

2 Likes

Good! It wasn’t there when I learned Xtext many years ago, I envy people learning Xtext now :smiley:

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… :slight_smile:

6 Likes

I like this idea of generic tooling and infrastructure. In way @voelter is proposing one piece of this puzzle with his active repository idea

1 Like

You are not alone:
//1
https://pchiusano.github.io/2014-09-30/punchcard-era.html
//
Unison’s core idea is that code is immutable and identified by its content

1 Like

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).

2 Likes

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 :slight_smile:

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.