Breaking the "learning wall" of Language Workbenches

[iandrich]

@digital-ember

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

The marketing in this space is a total mess.

[angelo]

There is no proper marketing for the whole domain. People can’t even agree on the meaning of model based, model driven, domain model, domain…

[digital-ember]

There is no proper marketing for the whole domain. People can’t even agree on the meaning of model based, model driven, domain model, domain…

While I also think, in general, that having precise terminology is something to strive for, I don’t consider it a major problem for marketing purposes that people use some of the terms you mentioned interchangably.
One thing to note about the arguably successful marketing of the term “low-code” is that it’s a (catchy) neologism, at least as far as I know. The term wasn’t overloaded with semantics right from the start (like “model” and “domain” certainly are). I personally think it is a very bad term, by the way, since it actually means “little-code”, and I associate “low” with “low-level” in the context of the term “code”, which is obviously the opposite of what they mean.
I had some conversations with @jdenhaan in the past about the meaning of “low-code” and its definition on their website or their recently published manifesto.

One example that shows how little I understand about marketing is that they make it very clear in both their definiton and their manifesto that low-code means working with a visual development approach. At the same time, Johan has convincingly explained to me that this doesn’t mean they dismiss other notations, like text or tables. Yet, the way they market it is “visual development”, and this seems to be working for them.

[angelo]

I see your point, but I disagree in part. Low-code is indeed relatively succesful in marketing, the other terms are not.
What I tried to express is that because Model Driven, Model Based and even Domain are terms the technical people disagree on, they are not suitable for marketing purposes. They don’t appeal to customers anyway, so maybe they shouldn’t be used for marketing purposes - especially if you take into account that the customer in this case is teh business that benefits from saving time and money in development, and not the development community. This is why the term low-code is relatively succesful: it implies less coders, so less development cost and a higher ROI on whatever the product is.

Low-code vs little-code is debatable indeed, but once again - the customer is not interested in the amount of code, but in the cost of creating it. Low-code then translates into low-cost and it works again. Try that with model or domain, I bet it won’t work

[digital-ember]

I actually think we are 100% on the same page, thanks for clarifying.

[nolisanjose]

Hi, everyone. I’m new to this community. I’ve been a fan of MPS and its promise/potential for years even though I only had the chance to really study and try to understand it more this year (because of the pandemic).

A few notes regarding the topics in this thread:

1. I personally like the sample project that @digital-ember mentioned (the “code-your-model”) in his post, even though I only saw the screenshots/GIFs, for a few reasons:

• (i) It makes the idea of a DSL really accessible to a non-technical user, given it’s “document-centric” look. = That to me is the ideal way to make a DSL less scary and acceptable to a broader set of users. If we go back to the idea of a DSL, we constantly refer to a “domain” and we seem to have this unstated agreement that the users should be business users (whether the business users are themselves technical or not is immaterial; ie. you might want a DSL for DevOps (which is quite technical) but it doesn’t mean I’ll give you an IDE for a technical person).

Yet, when I see some of the code samples of DSLs posted as part of the questions in the MPS community website, one thing you’ll notice is that the creator is somehow unconsciously targeting other developers, which for me is not the way to do it.

I believe if we can make the UI of our DSLs less technical and simpler, we will find a bigger audience.

• (ii) It drives home the point that the user should not be programming = the user is just “typing”, even simply “externalizing a thought”, and the IDE is there to support this “flow”. That, I think, is even more difficult than providing an IDE that’s a copycat of a 4GL IDE.

This leads to my other point, which is…

2. I don’t know if it’s an agreed convention but I am seriously questioning the purpose of the “.” (dot) in DSLs (that is, the way the dot is used in normal programming languages) especially if the user is a day-to-day business users. That person has no use for it, from my perspective. If you show me a DSL and the dot is a major component of it, it already failed.

3. I agree that the use of the phrases “projectional” or “projectional editor” or “language workbench” is off-putting, even though we think it is technically correct. The marketing department should come up with a better alternative.

4. @Oscar said “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.”. Here’s my initial revision to that page to further make the technology approachable to most users:

---

"Dialects and languages which are specific to particular subjects help people to communicate specifically and effectively about those subjects. MPS brings the same flexibility into the world of programming languages. Unlike traditional programming languages (whether Javascript, C#, Java, or C++) with strict syntax and semantics, MPS allows a language to be created from scratch, or altered or extended even by its users.

The core problem of extending languages lies mainly in the parsers, which are … (TODO: explain what a parser is in the simplest possible way). Parsers tie code persistent representation with the visual notation and they cannot be combined with other parsers easily, which prevents language modularization. [My note: that previous (original) sentence seems to imply that parsers are visual notations, which it is not; please refine]

To address this limitation, the idea of a non-textual presentation of program code is the most common proposed alternative. A major benefit of this approach is that it eliminates the need for parsing. In MPS however, we proposed another alternative: our solution is to always have code maintained in what is called an Abstract Syntax Tree (AST), a structure which consists of nodes with its set of attributes (properties, children, and references) which fully describes the program code.

The task of the MPS editor then is to visualize the AST in a user-friendly way and provide the means for effective editing of such AST. For example, if you are creating a language that simulates a classical textual languages, the editor should provide the user with the illusion of editing text in a text-like manner. In the same manner, if you are creating a language with graphical notations, the editor should provide the same experience you have of a well-behaved diagramming editor.

When creating a language in MPS, you define the rules for editing the code and how the code is rendered to the user. You can also specify the language type-system and constraints, a set of rules applied on your language. Combined, these allow MPS to check program code on the fly, and makes programming with the new language easy and less error-prone.

MPS also uses a generative approach. This means you can define generators for your language to transform user code into a more conventional, typically general-purpose, language. Currently, MPS is particularly good at, but is not limited to, generating Java code. You can also generate C, XML, FHTML, PDF, LaTeX, JavaScript, and more."

---

Thanks,

Noli

[ftomassetti]

Hi @nolisanjose, first of all welcome in this community and thank you for your contribution to the discussion

I only had the chance to really study and try to understand it more this year (because of the pandemic).

One good thing came out of 2020

@nolisanjose

(i) It makes the idea of a DSL really accessible to a non-technical user, given it’s “document-centric” look. = That to me is the ideal way to make a DSL less scary and acceptable to a broader set of users

Agreed. A DSL should look more like Google Doc than an IDE, and we as a community are starting to understand this, I think

@nolisanjose

whether the business users are themselves technical or not is immaterial

In principle yes, however I think that a DSL that makes a developer 10 times more productive at a certain task, will still be perceived as less valuable of a DSL that makes possible to a business person to do something, because the developer has the alternative to do it in the traditional (and inefficient) way, while a non-developer would have to get someone else to do the implementation, so getting a DSL is paradigm-changing for them

@nolisanjose

(ii) It drives home the point that the user should not be programming = the user is just “typing”, even simply “externalizing a thought”, and the IDE is there to support this “flow”.

I really like this way of putting things

@nolisanjose

I don’t know if it’s an agreed convention but I am seriously questioning the purpose of the “.” (dot) in DSLs (that is, the way the dot is used in normal programming languages) especially if the user is a day-to-day business users. That person has no use for it, from my perspective. If you show me a DSL and the dot is a major component of it, it already failed.

I have mixed feelings about it. I have seen DSLs built with and without dots. In general, I agree that they can be immediately perceived as “stuff for developers” and this is a risk. However, in practice the user will have to learn some form of notation: while we can reuse what he knows, there would be typically the need for some new notation for expressing concepts that he was not formalizing before. For some things the user could be already be using some formalisms (e.g., mathematics), but for others they are probably using natural language, so some concise formalisms is useful. In my experience, when we start with a more verbose and “natural-language-like” notation the users get eventually sick of it as it is less efficient. It is true that the dot could be in certain cases be replaced by a preposition (e.g., “of”), but for editing purposes symbols are shorter and easy to recognized from identifiers. in MPS I can say that a name cannot contain dots so when the user finish typing a name and press the dot I can catch that easily. The same would be true for any other symbol, like the $ or # but it would be more complicate for prepositions used as keywords.

@nolisanjose

I agree that the use of the phrases “projectional” or “projectional editor” or “language workbench” is off-putting, even though we think it is technically correct. The marketing department should come up with a better alternative.

I guess we are all the marketing department A few weeks ago we had a meeting in the community to discuss how to market these concepts and this is a challenge. Personally at Strumenta (my small company) we are hiring a person to help on that but I think any marketing expert would need inputs from us to find the right way to promote these concepts

[nolisanjose]

Hi, @ftomassetti. Thank you for your reply. But I have not yet thanked you for accepting me to the community, so, “Thank you!”.

@nolisanjose

whether the business users are themselves technical or not is immaterial

I might be a bit vague in this statement of mine, and your response actually forced me to think better of my original idea. My revised opinion now was, in summary: the DSL should fit the targeted user (as it should be); meaning:

• if the targeted user is a “regular” business user (aka office worker, for example), the DSL should look (if not “behave”) like a document (as you said, “more like Google Doc than an IDE”);
• however, if the targeted user is a technical person (a developer, or an IT Manager, or a DevOps person), then perhaps the DSL (and it’s environment) can be more technical than the one for the “regular” business user.

Again, it’s a question of fit.

@ftomassetti

In my experience, when we start with a more verbose and “natural-language-like” notation the users get eventually sick of it as it is less efficient.

I agree.

Although what is strange though is that even the choice of a symbol, concise though it may be, can also have an opposite effect.

I suddenly remember a personal experience. This injudicious use of symbols (from my perspective only; other users will definitely disagree) was in fact one of the factors that prevented me from enjoying F# (which is not really a DSL per se but a language with its own large set of unique symbols: F# symbols). And that was because of the “forward pipe operator”, which is “|>” if I remember correctly. I never got the hang of typing those 2 characters together (unlike the “->” in C#, the closest combination I can think of). It never felt natural to me. Eventually I stopped using the language partly because of it. My lesson for my study of F# was: try to make sure the experience of typing is smooth as possible, especially for the most common use cases.

(My own unscientific analysis of my preference for “->” compared with “|>” is because the dash symbol (-) is more familiar to me than the pipe (|), so I never have to look longer for the dash compared with the pipe ).

[ftomassetti]

@nolisanjose

Hi, @ftomassetti. Thank you for your reply. But I have not yet thanked you for accepting me to the community, so, “Thank you!”.

It is a pleasure to have you here!

@nolisanjose

Again, it’s a question of fit.

Yes, I agree

@nolisanjose

My lesson for my study of F# was: try to make sure the experience of typing is smooth as possible, especially for the most common use cases.

I agree. Sometimes I wonder if we should spend more time studying UX because those little things have a strong effect

[nolisanjose]

@ftomassetti

I agree. Sometimes I wonder if we should spend more time studying UX because those little things have a strong effect

I believe UI/UX is an integral component of a good DSL. If you consider that the client is expecting a custom environment from the very start, then it goes without saying this is something that’s non-negotiable. The UX is part of your solution.

[Oscar]

Thank you very much for your comments @nolisanjose!

@nolisanjose

3. I agree that the use of the phrases “projectional” or “projectional editor” or “language workbench” is off-putting, even though we think it is technically correct. The marketing department should come up with a better alternative.

I agree with the idea that we should be careful with the technical terms. A few years ago we redesigned our landing page to target all types of audiences (technical and non-technical). We removed terms like “Language workbench” and the acronym “DSL”, to make it more clear. We even have an animated video to explain the product in a superficial way and, recently, created a new section of case studies.
For the other sections of the website, it can become a little bit more technical, but that it’s based on the assumption that the technical people need to learn the technical details of the product and the non-technical viewers are interested in the general terms (the content of the landing page).

@nolisanjose

4. @Oscar said “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.”. Here’s my initial revision to that page to further make the technology approachable to most users:

You suggestions are very well received. After the holidays, I will review your suggestions closely to improve the “How it works?” page.

Happy holidays!

[nolisanjose]

@digital-ember

@Oscar

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

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.

In between the problem (#2, re big picture) and this activity …

@digital-ember

create very small, specific, yet relatable examples

lie the critical questions that need to be answered:

1. What are the real selling points of creating a DSL to those involved (business and technical decision makers) ? (Another way of saying: What are the pros and cons of using a DSL as opposed to a traditional software development solution?)
2. (And the glaring challenge you mentioned above:) “Where do we use it?”

To answer these, some areas to cover probably should include the following (not in any order):

1. Complexity of development (eg. 1 to 10)/Technical Skills Requirements

• What skills are needed for this DSL project?
• Can a regular developer trained on Java/C#/Python use it right away?
• If not, how long is the training process?
• Is the new skill transferable/usable to other types of project?

2. (Effect on/Simplicity of) Business Rules Validation

• How easy or difficult is it to create validation rules for your business processes?
• How about updating the rules?
• How effective/robust are the rules here compared with traditional solutions?

3. (Effect on/Simplicity of) Communication between stakeholders

• Can the artifacts be used to communicate across all critical stakeholders (vendor and client) like Business Analysts/Subject Matter Experts, Management/Steering Committee members, Development Team (PM/SA/Dev/QA)?

• Do we need to create separate documents/solution (thus extra effort, time and money) for each stakeholder or is reuse/sharing possible?

• Are the documents/artifacts continuously evolving and do not become irrelevant through the course of the project?

• What about during the course of the business?

4. Suitability of the business processes for DSL solution

• “Is our business and/or product/service fit for a DSL?”. I believe @ftomassetti has another thread on this. This question is critical to selling the value of DSL. The question of identifying the business processes for Gap/Fit is an important one.

5. (Connected to the last one above) Tiny/Sub-processes for potential DSL = “Instead of the entire business, do you see any quick win after reviewing our operations?” and “Can this quick win be continued/improved upon if successful (evolution of the solution)”

• This will identify small or quick DSL projects that will do a few things to the client:

• (a) introduce them to the idea of a DSL and its values;

• (b) gain the business benefit of the DSL right away without committing long-term (thus expensive) resources.

• (c) prepare them for evaluating (on their own) potential processes which can use a DSL approach.

6. Project Management Implication

• “Do we need to change/update our project management methodology because of this technology?”

Once those things (among others) are addressed, the next set of questions below can be identified.

2. What are the tools (or the “relatable examples” mentioned above, for that matter) that could showcase those answers/solutions above?

• Can one tool address them all?

• What tool is fit for which problem area?

3. What are the features that need to be developed in the DSL Tool in question (MPS/Xtext/Racket, etc) to address the fastest/easiest/simplest development of DSLs?

• Is it this:

@igor.dejanovic

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)

• Is it better and simpler table-type editor?

• Is drag-drop possible?

• What about a puzzle-type a la Scratch approach?

• etc.

Those are some of my ideas on this. Definitely quite raw and will involved some finishing touches. That’s what the community is for.

[Oscar]

Hey @nolisanjose, I am happy to share with you that we made some changes to the MPS “How it works” page inspired by your recommendations: How Does MPS Work? - Concepts | MPS by JetBrains

[nolisanjose]

Thanks for the update. I am humbled if not a bit embarrassed that you took my suggestion seriously.

Anyway, although I cannot really remember the old version completely, from my perspective I think this is definitely easier to read and understand.

One super duper tiny item: “Currently, MPS is particularly good at but is not limited to, generating Java code.” I’m not really sure but it might be good to check with your editor if there should be a comma after “at”: “Currently, MPS is particularly good at, but is not limited to, generating Java code.”. Or “Currently, MPS is particularly good at (but is not limited to) generating Java code.”. Again, I’m just being nitpicky.