Interview with Jan Köhnlein on TypeFox, DSLs and Xtext

Jan Köhnlein is a leading expert in DSL design and an Xtext committer. After obtaining his PhD from the Technical University of Hamburg he worked for companies very well known in the modeling field: Gentleware and Itemis. Recently he founded TypeFox together with Sven Efftinge and Moritz Eysholdt.

I thought it was a good moment to ask him a few questions about his new venture. Of course it is also a great possibility to ask him about his views on DSLs and the future of Xtext

About TypeFox

TypeFox

Can you introduce TypeFox and tells us more about what services you offer?

TypeFox is a software company focussed on development tools for software engineers and domain experts. As the leading company behind the open-source frameworks Xtext and Xtend, we have great expertise in language engineering, domain-specific languages (DSLs) and tool construction. TypeFox offers all kinds of services around these topics, such as professional support, projects, consulting and training. Our office is based in Kiel, (Germany) at the coast of the Baltic Sea.

How were the very first months at the new company?

TypeFox was founded in January 2016 by Sven Efftinge, Moritz Eysholdt and me. It has been and still is an exciting experience. None of us had led an enterprise before, so there were a lot of new things to learn in addition to getting the company going financially. But we managed to gather a team of very skilled programmers and thanks to the good visibility of the Xtext project we did not have problems to find customers. All in all we had a very successful start. So successful that we plan to grow further.

On DSLs

Are your typical customers already aware of the potentialities of DSLs or do you have to do a lot of evangelization?

Most of our customers choose us because they need Xtext experts, so they are already convinced of the DSL approach. But we do evangelize at conferences, and community gatherings and by writing articles for magazines or online portals.

In your experience what kind of customers are more willing to embrace DSLs? Does it depend on the size of the company or the domain?

As all kinds of abstraction techniques, the DSL approach needs a certain problem size to pay off. Even though Xtext is pretty lightweight for a language engineering framework, you would not create an entity DSL for just a handful of entities. But for a few hundreds you would. So yes, the problem size matters.

Company size does not matter that much. Bigger companies are more likely to have many domain experts, who are not necessarily software engineers, like mathematicians in an insurance company. Those experts can be more directly involved in the software development when they can capture their knowledge in DSLs.

DSLs seem to me more widespread in Europe than in the US: is that true for you? In which countries do you see them more used?

From my former experience, the development in the USA has been more focussed on getting things shipped, while in Europe and especially in Germany we have spent a lot of time on the architecture. Both approaches have pros and cons, but the latter mentality is for sure more susceptible to the DSL approach. Currently we have about as many customers in Europe as we have in the US, so they seem to be converging.

Have you seen any change in the number of DSLs adopters in the last years? Do you think they are going to become more common in the near future?

The basic idea of DSLs is pretty old, and there have always been phases of hype and decline. I see that DSLs have become mainstream in certain areas like enterprise application development, and some industries, like automotive in Germany, even cannot do without them anymore.

What are in your opinion the main issues to adopt DSLs?

Technically, DSLs raise the tool stack. It is not always clear whether this overhead is worthwhile, and many developers are skeptical about that for good reasons. And of course not every programmer is a good language designer.

The other issue is that there is scaffolding: Many developers ask why they should write a code generator for getters and setters, XML mappings or Maven poms if their IDE or web framework generates them on demand. It is not always easy to convince them that it is more sustainable to capture the model in a DSL and write a code generator that can be run repeatedly and can be fine-tuned to the specific needs of the actual project.

Do you work more on DSLs intended for developers or for domain experts? Are they very different?

We currently develop a bit more technical DSLs than business DSLs. This may also be due to the fact that Xtext had been available for Eclipse only, whose look and feel often  scares non-developers off. Since 2.9 you can also generate a web editor for your DSL, and this is where many business DSLs live.

From a language point of view, the main difference is syntax, where developers accept a program like text notation, while many business experts prefer forms, tables, diagrams and prose.

On Xtext

450px-Xtext_logo

I think that most newcomers to Xtext find the learning curve very steep, probably because of EMF. The quality of the documentation on the official website is very high, especially compared to other Eclipse projects but is there anything else you think the community could do to help people to adopt Xtext?

Thanks for the compliment, but documentation is always something that can be improved. Since Xtext is hosted on Github, it should be very easy for community members to submit pull requests for corrections. And luckily there is the book by Lorenzo Bettini, which is an excellent addition to the official docs. If you have an interesting project based on Xtext, an entry in the community section on the Xtext homepage is also just a PR away. Other than that, we have a very vivid forum where you get answers to your questions very quickly which is also driven by the work of the community.

You and your team are contributors to Xtext and you have an amazing experience with it. Can you tell us a bit about what is going on with Xtext and what interesting things are coming in the future?

We definitely plan to invest more in web support. One part of that is to integrate Xtext with Eclipse Che. Sven is going to talk about that at EclipseCon France 2016. In addition we are going to polish the new features added in 2.9, such as IDEA, Gradle and Maven support, as well as the new generator architecture.

One big feature Xtext got recently is the possibility to generate editors for IntelliJ and for the web. How mature is this feature? Is it helping to attract new Xtext users?

IDEA support is ready to be adopted by the users. Unfortunately, we did not get too much feedback so far. We hope that we are going to get more in the future.

Web support is working fine as well. But as there are a plethora of web application architectures, it will be interesting to use it in more projects and find out where we have to make it more generic or specific.

Xtext is about textual notations but models can support other visualizations (using GEF or other tools). What are your thoughts on combining graphical notations with Xtext? I remember reading a first post from you in 2009 and you kept writing on the subject (a more modern approach is presented here). Is it something you do often? Is it effective?

As Xtext is based on EMF like most graphical frameworks from the Eclipse world, the integration seems to be quite straight forward. But the problems emerge from a different understanding of transactions and object identity. The result will be strange glitches and bugs in the integrated tool.

This is why I advocate graphical views on top of Xtext, that only read the model. With FXDiagram you can do that pretty easily, and get a very modern diagram editor on top.
My colleagues Miro Spönemann and Christian Schneider have both worked on the KIELER project before, so you will probably see more contributions from TypeFox to the graphics community in the future.

By the way, we have a customer project where we integrate a textual DSL editor into a table, which was not easy implement for exactly the same reasons mentioned above, but works great now.

Final thoughts

Xtext is probably the most mature and complete system to create textual DSLs, however there are other “Language Workbenches” available. I am thinking of Jetbrains MPS, Rascal, Acceleo and others. What do you think of these alternatives? Any competitor I am missing? Any feature you think Xtext should get or cases in which an alternative tool is the right solution?

Ranting on competitors is not my style, but it is hard to find an alternative to Xtext that is as powerful, extensible and mature, does not lock you into a closed world of specific development tools, is open-source and backed by companies that provide professional support.

Is there anything else we forgot to discuss?

I just want to say thank you to our team, to all committers and supporters of the Xtext projects and to the community. You made Xtext what is is today.

Finally, what is the best way for customers interested in Xtext consulting to get in contact with TypeFox?

Write us an email to contact@typefox.io, or bump into us at conferences, like EclipseCon, JAX and others.

Apart from that, we are hiring. So if you know any good software developers who want to join our team, spread the word!

If you are interested in joining TypeFox visit http://www.typefox.io/career

Download the guide with 68 resources on Creating Programming Languages

68resources

Receive the guide to your inbox to read it on all your devices when you have time

Powered by ConvertKit
5 replies

Trackbacks & Pingbacks

  1. […] year we have seen a new company joining the Language Engineering community: TypeFox. I interviewed one of the founders some months ago. They are focusing on Xtext, with many contributors to the project joining their […]

  2. […] moving force behind Xtext, Xtend, and FXDiagram. This is a very extensive follow-up interview to this one. Thanks again to […]

  3. […] moving force behind Xtext, Xtend, and FXDiagram. This is a very extensive follow-up interview to this one. Thanks again to […]

Comments are closed.