Introduction

In my previous post, I compared Xtext and EMFText. I pointed out a few differences that may help you select one tool over the other. In the next posts I'll go into each of the points in more details. In this first in-depth comparison, I'll be focusing on the differences in the development processes between the two tools.

Two kinds of DSL's

If I take all the DSL's I've defined, I can partition them into two groups based on what was the main focus when discussing the language:

  • Abstract Syntax.
    In some projects, I developed multiple concrete syntaxes. When this is the case, the language is most often designed using the model for the abstract syntax. This leads to a process where we first design the language features using the abstract syntax, then later we'll discuss how we want the changes to the abstract syntax to be reflected in the concrete syntax.
    In short: Abstract syntax first à Concrete syntax derived
  • Concrete Syntax.
    In other project I had no intention of building more than a single concrete syntax. In these projects, the abstract syntax is usually developed after we've made decisions on how to change the concrete syntax.
    In short: Concrete syntax first à Abstract syntax derived
When comparing the Xtext and EMFText, one major difference between the tools is that the natural development process for Xtext is to first develop the concrete syntax and let the abstract syntax be derived. When using EMFText, the natural development process is to first develop the abstract syntax, then define the concrete syntax.

Development process for EMFText




The figure above shows a high level outline of the EMFText development process. The matrix shows two dimensions. The X-axis shows if the technology used is original or if it the tool is derived from some other technology. The Y-axis shows the process for abstract vs. concrete syntax.

The process can be described in text as follows:

  1. Develop your ecore model. For this you can use any tool, none is prescribed, none is supplied. There are many tools available for building EMF models. For more details of how to create an EMF model, check out the EMF site or the following presentation.
  2. Develop the concrete textual syntax using the tools provided by EMFText. The tool provides a language for defining the concrete syntax of a already supplied ecore model (containing the abstract syntax)
  3. Run the EMFText provided generator. This generator relies on ANTLR to build a parser.

Development Process for Xtext




The figure above shows the main processes of Xtext. Notice that process is quite different from that of EMFText. Although Xtext depend on EMF and uses ecore models for abstract syntax, you would typically let Xtext generate the abstract syntax from the Xtext language.

There is also a way to use existing abstract syntaxes with Xtext (although, that requires a bit of configuration). You can read about how here.

Which approach is better?

I'm sure one may construct an argument arguing for or against either approaches. My personal view is that neither approach is superior to the other.

My recommendation would be to evaluate how well the tool fits your experience/goals.

Factors that may influence your decision


How many concrete syntaxes do you need?

If you develop multiple concrete syntaxes, you would typically want to focus your design around the abstract syntax. One may argue that one always should, but it is my experience that unless you have two or more concrete syntaxes, the discussion will be around the concrete syntax.

Both tools supports focusing on abstract syntax first, but this approach would fit more natural with the approach of EMFText.

If you intend to produce one concrete syntax only, you may find the approach of Xtext better. You only need to maintain one file that contains both abstract and concrete syntax definitions.


Do you already know EMF?

You cannot use EMFText unless you also learn EMF. You need to choose an approach that first produces ecore models. If you already know how to create ecore models, the EMFText may be more appealing than Xtext.

Conclusion

Both Xtext and EMFText are tools that help you create a textual syntax for a DSL. One of the main differences between the two tools is the proposed development process. Xtext provides one language from which it derives both the concrete and the abstract syntax. EMFText relies on EMF based tools to create an ecore model that they then 'annotate' with definition of a concrete textual syntax.

If your language requires multiple concrete syntaxes and you already are familiar with EMF, then the EMFText may be the best fit. If you are defining the single concrete syntax, Xtext may be a better choice because you can derive the abstract syntax directly from Xtext and also no knowledge of EMF is required.

The selection criteria for the two tools are rather fuzzy. You may separate the abstract syntax from the concrete syntax in Xtext also; hence, you can easily support multiple syntaxes in Xtext. Also, when generating code from Xtext, you typically will have to understand EMF and ecore, so the advantage of hiding ecore may be mute.

I would recommend that you understand the differences, evaluate your own (or your organization's) background and make a decision. Whether you select Xtext or EMFText, you gained a fantastic tool.
5

View comments

Today, I want to introduce the word 'dugnad' (pronounced ˈdʉːgnɑd]) to my friends and colleagues.  
Dugnad is a word from Old Norse and it is wrongly translated as 'volunteer work' in the English dictionary. Dugnad has a much richer meaning and tradition in Norway. Dugnad is when a community comes together to fix a problem in their community. 
When I lived in Norway, it was usually used to describe a common effort like cleaning up a common area in your neighborhood or perhaps your sports club comes together to improve the sports facility.
The word, dugnad, is now used in Norway to talk about the shared effort required to fight the coronavirus. 
Source: Wikipedia. Picture of a Dugnad where a group came together to put down a roof 
I can't find a US word for dugnad, so I am hereby submitting it to the dictionary for inclusion (the last word I know we managed to sneak into the English dictionary was quisling, so it is time the Norwegian language contributes a positive word).
I have seen how the communities come together in the US as well. A great example is all the healthcare workers that have volunteered for working with the coronavirus patients in New York (76,000 of them at the latest count). Also, Jayde Powell, who started Angle Shopper (see https://www.cnn.com/2020/03/17/us/coronavirus-student-volunteers-grocery-shop-elderly-iyw-trnd/index.html). 
In fact, the USA is known to come together under a crisis. E.g., think of the effort that the USA put together to fight the Nazis during the second world war. In 1939, the airplane production in the US was 3,000... by the end of the war,  the US produced 300,000 planes.
I pledge to start my own dugnads. The first will be to share the lessons learned working remotely. I am one of the fortunate ones that work remotely and have been for the last 12 years. As of now, the virus has not hit me and my company because all our work is already remote.
I also plan to start free online seminars on various topics that I now teach for various companies and universities.
I'll post the article on how to work remotely here on my blog. I will also start my online seminars as soon as I can figure out which platform is best suited to handle the load (last time I taught a class online, I had 8,000 students and I'm pretty sure my Zoom subscription doesn't handle that :). 
1

View comments

About Me
About Me
Blog Archive
Subscribe
Subscribe
Links
Subscribe
Subscribe
Loading