Strumenta 
Why this interview?
Juha-Pekka Tolvanen is one of the veterans of the DSL industry. There are not many persons in the world who has an experience comparable to his. This is why I really wanted to talk to him and ask him about the work he has been doing for the last years and what he has learnt building tens of DSLs for customers in different industries.
Here there are some quotes I found particularly interesting:
The main advantage [of DLSs], what we basically see immediately is the improved speed […] usually the speed is the easiest to detect and some companies measure it too. You can often in a meeting hear a conclusion like, “This afternoon I did something that had earlier taken the whole week to complete.”
We have tried to make the language creation easy so that if customer already know the domain, they can formulate the language, define the meta model as we call it. Of course, while you are creating the language you obviously don’t know all the details, but you have the big picture and once you formulate the language, the tiny issues become formalized at theat time as well.
Many years ago with one of my colleagues, Steven Kelly , we wrote a book on domain-specific languages, and analyzed 20, 30 customer cases. We interviewed them just to find out how they had formulated the languages and how they had found the language concepts. We discovered five different kinds of categories…
Last year we published a paper available for free […] in which we looked at 10 cases. Companies like Panasonic, Porsche, Polar Electro and others, and it was an average of 10 working days. 10 working days for both a language and a generator […] many people are a little bit surprised that it’s not a multiple-year effort.
However, one thing that I think is crucial for domain-specific languages is not just the concrete syntax and abstract syntax, constraints of the language definition, but the overall use process and, let’s say, how to reuse the models
But of course there is plenty of more interesting stuff in the interview. Below you find the video and the full transcript. Enjoy!
Federico: Hi, Juha. Thank you for taking the time for this interview. How are you today?
Juha-Pekka: Good morning. I am fine. It’s spring coming here, so no snow anymore.
Federico: Good to hear that. Here the weather is a bit crazy right now, but you know, climate change, I guess. Okay. Can you start by telling us a little bit about you, what it is that you do?
Juha-Pekka: Sure. I work for a company called MetaCase which builds tools and languages for customers. I started off as a consultant at the company, then became a member of the board and currently I am the managing director.
What we basically do is assist customers in building their languages, usually in the early steps, but in some cases we do the full solution for customers. In many cases, however, customers do everything by themselves with our assistance at certain points in the process. This is something that I have been doing since my university studies and the whole company was basically founded from the university research by 10 people, which is how we basically got started. This is something that I have been doing almost my whole adult life.
Graphical DSLs
Federico: Good, so you have a lot of experience to share and so I’m happy that we can share a little bit of it today. You have a lot of experience building domain-specific languages and so I am wondering what are, in your opinion, the main advantages of DSLs?
Juha-Pekka: The main advantage, what we basically see immediately is the improved speed. There is also the quality aspect, but is not so immediately visible. People realize that we don’t need to maintain multiple files and keep them consistently built – it’s consistent, or there are similar errors everywhere. Those kinds of things immediately come out, but usually the speed is the easiest to detect and some companies measure it too. You can often in a meeting hear a conclusion like, “This afternoon I did something that had earlier taken the whole week to complete.”
Sometimes companies still measure it though. They even make an empirical setup. One company once mentioned that they had invested in collecting data for five years to see how it was doing. Later we contacted them and asked about the data and they said that they stopped collecting it after a year because it was so clear that there was a good development speed.
Federico: Yes, l guess when the speed is 10 times faster instead of 10% faster, it really is obvious.
Juha-Pekka: Indeed.
Federico: Okay. We know that there are different ways to build DSLs and it’s possible to build graphical and textual DSLs or use tables as DSLs. I was wondering what your opinion was about using these different approaches. When is it better to use graphical DSLs and when is it better to use a textual one instead?
Juha-Pekka: Yes. Well, there are multiple kinds of representations, other than textual or graphical ones. Basically, it should always come from the problem domain itself and not from the personal preference or what the tool can do. So if we have, let’s say a metro map, I guess it should be some sort of a graphical diagram. If it is a time table for the metro, however, then most likely matrix kind of columns would be more suitable. Therefore it really needs to come from the domain what people think that the problem domain itself is. What we basically see most are graphical domain-specific languages and often diagrammatic, but in the tooling that we provide the same diagram can also be visualized as a matrix or as a table. So it doesn’t really matter much if it’s a diagram, but quite often problems are such that they tend to be graphical diagrams in our case.
Federico: Okay. So your company produces and sells this language workbench called MetaEdit+ and I was wondering if you are familiar with other language workbenches or if you find other language workbenches interesting in this field?
Juha-Pekka: Yes, indeed. A few years ago, I had the possibility to give keynote at a conference and I collected around 50 different kinds of language workbenches there. Many years ago we used to collect that information partly for research, but also just to follow up on what’s going on. Most of these language workbenches don’t exist anymore and many of them are research environment to study languages and their creation. Tools like QuickSpec are something that has influence to us in terms of how languages are defined. Also, there is PSL/PSA Problem Statement Language/Problem Statement Analyzer, which is, to our knowledge, the first meta tool, a mother of all language work benches if you like to use that word, from the end of the 70s.
Creating DSLs
Federico: Okay, now I’m really curious and will have to go back to study it! We have talked about tools and now I believe it will be interesting to talk about how we create DSLs. You have already mentioned something about it in your introduction but it will be nice to recap. How is the typical DSL created? Who designs the language and how does the language designer learn about the domain for which he is creating a language?
Juha-Pekka: A good question because that’s also what we have been trying to understand. Well, in our case the language engineer does not need to learn the domain because they already know about it because we provide the tooling and customers who already know the domain formalize it into a language. For instance, let’s say the domain is automotive regenerative braking systems: it’s then harder for us to learn that domain than for customer to build the language. At MetaCase, we have tried to make the language creation easy so that if customer already knows the domain, they can formulate the language, define the meta model as we call it. Of course, while you are creating the language you obviously don’t know all the details, but you have the big picture and once you formulate the language, the tiny issues become formalized at theat time as well.
Many years ago with one of my colleagues, Steven Kelly, we wrote a book on domain-specific languages, and we analyzed 20, 30 customer cases. We interviewed them just to find out how they had formulated the languages and how they had found language concepts. We discovered five different kinds of categories where, in these cases, the languages concepts come. Sometimes there was already an established vocabulary that was formalized. Sometimes it was mimicked from the user interface concepts, so all the widgets that you can see basically come to you’re the language concepts. Sometimes the source for the languages concepts came from the expected output, so you have a certain kind of structure that you generate, and you almost take the output structure and put that into the language, which does not necessarily raise the abstraction, but that’s what some people do. You have an XML or config file and you take all the items from the config file into your language.
Then there’s a product line approach when basically all the aspects that can vary in a product family become language concepts. And then the last approach is when language concepts come from the physical structure like if you have a railway system with switches, tracks and signals, or, fish farms with ponds having a physical location. So basically when the look and feel are of importance, … I can provide the link to the article that will provide maybe some details for the listeners or readers.
Find the article here, and more details in the DSM book.
The five approaches to define DSLs as identified by Juha-Pekka Tolvanen and Steven Kelly:
- Apply existing vocabulary and domain concepts
- Define the concepts based on the output that has to be produced
- Define the concepts based on the output that has to be produced
- Product line approach: define concepts to represent the variability
- Define concepts to mimic some physical structure
Federico: Yes, it would be very interesting to understand which mental schemas the language designer starts with to create the language. In the project we implement or follow, we typically build DSLs for our clients so we need to learn the domain. It seems that in your case it is the people with experience with the domain who build the language and I’m curious if they now need to learn language design principles or is it something that they really can acquire easily just by doing it?
Juha-Pekka: Well, obviously, creating languages is something that requires abstraction capabilities and not all people like to do that, but typically architects or framework developers in the companies already think in these terms, so they already have the way of thinking, “Let’s have reusable parts. Let’s not write everything,” mentality and those kinds of people – lead developers, chief architects – they are normally the people who define the language.
Federico: Okay, good. Let’s try to describe what the experience of creating a DSL suite on MetaEdit+ is like, what kind of effort it takes to create a new language and how long it typically takes to do so. I know that different languages can take different times, but just to have a general idea.
Juha-Pekka: We typically ask this information, but quite often the companies who build them internally don’t collect the data and therefore don’t measure everything. Some companies do, however, and last year we published a paper that is available for free – I can provide the link – in which we looked at 10 cases. Companies like Panasonic, Porsche, Polar Electro and others, and the data in these cases show that it was an average of 10 working days.
Article about those cases available here.
Federico: Nice.
Juha-Pekka: 10 working days for both a language and a generator. Obviously if there are multiple generators, like want to generate also tests configurations or documentation as well, that’s an additional effort, but we look at cases where we can easily ask the customer to build one language and one generator. It is surprisingly small. Many people are a little bit surprised that it’s not a multiple-year effort.
Federico: Yes, it’s interesting what you said that sometimes clients do not collect the data and given your experience with clients who can build the languages themselves, I guess that it must sometimes be harder to get the information they are experiencing, especially if things are going smoothly – they don’t run into problems so maybe you don’t hear from them.
Juha-Pekka: Yes. But in a vast majority of the cases, customers build the languages themselves and they always maintain them by themselves in maybe 95% of cases. That way we are only involved if they have any questions on how to do certain things or if they sometimes ask for advice, for instance when given different options, which ones to pick.
Companies usually don’t want to share their language definitions outside. That’s a little bit hard for all the people in marketing domain-specific languages or wanting to show them because companies feel that these are important assets that should not be distributed. At best case, we might be able to show some screenshots of what the DSLs look like and then, with their permission, show a portion of their languages.
Federico: Yes, I believe this is a major problem for marketing because sometimes companies think that it’s such a competitive advantage to have a DSL system, and maybe they don’t want other competitors to know they are using a DSL. So that makes our life difficult.
Juha-Pekka: Unfortunately, that is true, but that is how it goes.
Federico: We should consider building worse DSL so they are happy to share that, but what can you tell us about maintaining these DSLs? You have said that it takes more or less 10 working days to build them. That, of course, depends on the scope of the DSLs and the number of generators, but do you have any idea about the effort of maintaining these DSLs?
Juha-Pekka: That’s something what we haven’t studied as much because usually when customers start using DSLs, they are not actively involved with us anymore.Therefore we cannot know that much in detail, but the effort should not be very large. We have some customers who have close to 400 language users, but there can still be one or two people who maintain the languages, without it necessarily been their full-time work. Usually they are always the same people who also use the language. They might be members of the product development team and in cases where the teams require new capabilities, they extend the language.
Federico: Now I’m curious, how do people learn how to use your tool? Do you provide some training or documentation?
Juha-Pekka: Well, we have a bunch of materials, videos, detailed manuals, a book, articles, but most people do it by downloading the evaluation version. There we have a few tutorials that teach how to do simple languages first. The evaluation version is full of examples with flow driven languages, state machine driven languages, data modeling languages, hardware modeling languages, so many people pick an existing one and then they can change it according to their needs.
Federico: That makes sense.
Juha-Pekka: I should tell one thing that makes maintenance easy in our tooling because it is -a lesson we learned with the hard times, in the very beginning when we built the first tool, called MetaEdit. It was the first graphical meta modeling tool, but it had an unwanted feature: when you changed language definition, you would quite often also lose all the models done. Therefore you needed to maintain them manually or write the programs to translate the models to the new version of the meta-model. This is still the same practice many generative tools like DSL tools or Eclipse Modeling Framework, GMF use.
So in the past usually you lose your work if you changed the metamodel. That is why we changed MetaEdit+ so that its architecture, which we think is unique, at least when we built it, was that whatever the language engineer makes and change the meta-model, the existing work is not lost. It will migrate automatically, so there no effort goes to maintaining existing models. Let’s say you have 300 users and you change the language; you might be afraid of what will happen to the work of 300 people, so we developed a tool which editors wouldn’t break. They can still see the models, and if something needs to be updated, they can see it in a screaming red or whatever the language engineer wants to show things to be migrated. That makes the evolution possible and also the maintenance portion to be very small because the models always update automatically in a non-destructive manner.
Federico: That seems a very important point because it permits the language to evolve. It doesn’t discourage you.
Juha-Pekka: And domain-specific languages always evolve because the domain itself evolves. We have needs of new generations needs and things like that, and we believe that support for evolution is crucial.
Federico: Another thing I wanted to ask about is the typical usage of DSLs with MetaEdit+: do you see users building just one DSL or typically families of DSLs that can interoperate to define different aspects of the same system?
Juha-Pekka: Yes. In our case, it’s a good question. What is a language? People could ask, let’s say from SysML or UML, is it a language or is it a collection of sub-languages like a state machine or a class diagram. In our case, we are bit like this UML way of thinking in the sense that you can have a domain-specific language where one portion of the language focus for example on the hardware physical structures and then other, like state machines, on the behavior of the physical structures so you actually have two connected languages.
Quite often, albeit we don’t have the data and it would be an interesting thing to study, there are two, three sub-languages and the smallest ones are maybe 50 concepts, 50 keywords and in our terminology UML is around 300 concepts in our language definition, so smallest DSLs are one-fifth, one-sixth the size of the UML. The largest are maybe closer to 800 language concepts. They could be twice, two, three times the size of the UML, so there’s a very big difference depending on the domain.
Federico: Okay. It is good to have the possibility to compare it with something known to many UML users.
Juha-Pekka: Yes. They normally tend to be smaller than UML because they don’t need to carry big metamodel with them. They tend to be more focused. But then they tend to have more types of users. Let’s say not just programmers, but there could also be test engineers or safety engineers who also want to use the models, but for something else than for code generation.
Lessons learned
Federico: Yes, very good. After discussing all the advantages, we sometimes wonder why not everyone isn’t using DSLs. In your opinion, what are the main barriers that prevent people from adopting DSLs? Why are they not using DSLs?
Juha-Pekka: I think there are two main reasons. One is that in order to build a DSL, you need to have an expert’s time. And quite often the expert is the already busy person to whom everybody contacts with questions. That’s also the person which bosses or managers who supply resources don’t necessarily want to give as a resource. Normally it requires the managers to see that we need to invest in software development. That’s number one: expert’s time.
Number two is that in software development and system development, more on the software side though, we don’t get repetition frequently enough so that building DSLs makes sense. So if your company is in a project business: builds something for customer A this week and next week something else for customer B, it’s hard then to invest in something that makes you faster. This is in contract if you are in product business. Let’s say if you are building printers or cars or any product really, you know that you are most likely going to build them next year as well, so the mentality of the companies is totally different and it makes sense for them to invest in making the products faster next year and years to come. These are the two things that create the barrier.
Federico: This is also connected with the next question that I wanted to ask: what kind of organization, in your opinion, benefits more from DSLs ? Product-based companies perhaps?
Juha-Pekka: Correct.
Federico: Do you think other characteristics are important for an organization?
Juha-Pekka: We also have customers who are project houses as well, but they have already focused their business so that they can carry out projects with certain technology in a certain way and they don’t want to do other ones. They already have their automation and then they can run the projects faster in the niche market they are working with and thus be competitive. So repetition is a key thing. If you can press the generate button multiple times, the more you can do it, the better it is.
So if you are a company that has for instance three or more products with some variance, like a product line, then this is a perfect approach. Another thing that we often hear is also that companies say that they want the non-programmers to be involved and therefore other stakeholders like test engineers, deployment people, safety engineers need to be involved in the development too. Having a language that raises the abstraction closer to the problem domain is the way to bring everyome into the same table.
Federico: This is also in line with my next question: who are the typical users of DSLs? Are they developers, accountants, who are they?
Juha-Pekka: They are mostly developers, but they are not necessarily all programmers by background. They can be mechatronic engineers, control engineers, test engineers, safety engineers, insurance experts, user interaction specialists etc. So I would say some kind of engineer, but not necessarily people with background in computer science.
Federico: Another question that I have had on my mind for a long time is more related to marketing: how do companies find out about DSLs? Sometimes companies need ways to automatize the development, reduce the repetition, but they really don’t know that DSLs exist. Maybe after years of looking into it they find an article, but it’s hard for them to know that DSLs exist. In your experience, how do people find about DSLs? And how do people find out about your company?
Juha-Pekka I think there’s no single answer here. In some cases, there are movements in the industry towards creating languages or metamodels or formalizing them. Let’s say in the automotive sector, there have been approaches like AUTOSAR in Europe or JASPAR in Asia or AADL in U.S. where multiple companies realize the importance of abstractions and get together to build something. The same thing happens in railway systems with railML or Telecom systems with CPL and other standards. So that’s one way: the industry itself realizing that we can’t do everything based on programming language level. We really need to have better interactions. And then normally there are visionary customers who basically see that they can get competitive advantage over their competitors if they automate developments compared to others who do it in a traditional manual way.
The problem for marketing DSLs in the broad sense is that people are not aware of it – or there is not such a word that could create a market for DSLs in general. But, there is markets within each domain: like with AUTOSAR or railML or something like that, as people in railway business realize what it is in their own domain. It’s sometimes funny because you may have implemented almost the same kind of language for a certain industry, let’s say in the medical sector, and then you have industry automation in chemical processes who never speak with people in medical sector, but they actually use the same kind of meta-model, language structures, to solve their problems, too. So, they never get a chance to talk with each other, and they never think that they are in the same market albeit the DSL they are using are very similar. Yes, so sometimes it’s really surprising.
Federico: It’s difficult to see this connection from outside.
Juha-Pekka: Definitely.
MetaCase
Below you can see a presentation about MetaEdit+, the Language Workbench created by MetaCase.
Federico: Can we talk now a little more about MetaCase, or can you tell us a bit more about your company?
Juha-Pekka: Well, at the very beginning I briefly mentioned that we basically have background from university research. Ten people who studied together founded the company and now work closely together to build the languages. We built first something which we called MetaEdit. A first graphic meta-modeling tool, and then we learned that it had several limitations. For instance, if you changed the language, your models would break. You could only support one user at a time, write small models one language at a time, and all these kind of limitations. Then we realized that the proper way would be to build the tooling so that it enables evolution, multiple languages, large models like million of model elements, multiple users, different views, not just graphical but also other formats. Then we built this current tooling what we call MetaEdit+.
So background comes from basic research and that’s how we then founded a company, to seize the opportunity because this was something what we wanted to do also after the academic life. For me personally, having done a thesis on meta part, it was easy to switch to the business side because I enjoyed more seeing customers building languages to get product development faster than getting articles published.
Federico: Yeah, that makes sense.
Juha-Pekka: That’s my joy – I like to improve the productivity. Of course, I like writing the papers, but if I need to make a choice, then I would decide to step off the academic road. I still like it and I’m still involved, but doing for me is perhaps more interesting than studying or research.
Federico: Yes, I fully agree. I also like to write papers from time to time, but working on real projects is more satisfying for me. Speaking of joy, I wanted to ask you what project you liked working on the most? Is there any specific project or any type of project that gives you more satisfaction?
Juha-Pekka: Really, the joy of this work is being able to see so many different companies and how they build software: like if you are a pacemaker manufacturer it is different that, when working with a chemical process plant automation software or on a web application or mobile application and seeing how things are built in so many different ways. This is very interesting to see and also how our whole industry has got more diversity into it and therefore it’s even became richer in the ways how the software is build now than it was, let’s say 25 years ago. That’s maybe the nicest part of this work.
Federico: Yes, we’re in an interesting field and really seeing things changing.
Juha-Pekka: I think we should really appreciate this, all the people and software and systems area, to really enjoy this interesting time. An interesting period is going on and has been going on for a long time.
Federico: Okay, and can you tell us more about the customer journey of your customers? They typically go and download the evaluation version of MetaEdit+, they play with it and if they have problems, they contact you, right? Otherwise they just use it, follow the tutorials, build their languages and start benefiting from it.
Juha-Pekka: Correct. The tool is available to download from MetaCase.com and people then do that and try it out. We have tried to pack there multiple tutorials so people can do everything by themselves or contact us by email directly, visit user forums. This is also an interesting part in DSLs: the fact that they don’t want to put necessarily their questions to the public forum about their language. They just want to ask us directly how to do certain things. That’s maybe a common thing.
Then if companies want to get to the fast track, have their first language ready very quickly, say for next week, then they contact us and we provide consulting for them. We sit together and build the first version of the language for them in couple of days. It is normally not ready immediately, but it will cover maybe 20% or even 50% of all the language concepts so that they can try it out and see whether it makes sense to continue and implement the rest. Usually at this point in time management also gets involved and they come up with questions like if they could also use generate tests, configurations, extend the language and so forth. Then they really understand this kind of power having first language version running. What we wish to show is that the investment is small and then it starts paying back very quickly. So these are immediately available the two options that we basically offer.
Then some customers also say that they are so busy and don’t have time, but need to have something built for them and ask us to jump in, which is more or less the consulting kind of business. Typically, however, most customers build languages by themselves.
Federico: Does it happen that these companies that are too busy and ask you to build the language for yourself, then they fail to give you assistance and access to the domain experts to help you build the language?
Juha-Pekka: Sometimes companies want to use the time for specifying, so they want to formulate what the language looks like, what some of the constraints are what symbols should look like and things like that. So they give specification and asks us to implement them. However, one thing that I think is crucial for domain-specific languages is not just the concrete syntax and abstract syntax, constraints of the language definition, but the overall use process and, let’s say, how to reuse the models. If I make a model, is it something that another person can refer to and to how that can be done, and how the models are checked together and how to translate those models to some analysis or simulation tool so that the development process is fluent. Like I want to press a button after making my designs and then-tool checks the design, generates the code, sends the data to the simulator, reads the results from the simulator, and produces a document saying how it all went. So the language definition must cover also, how to automate those kinds of development flows and processes.
Often, a companies making these manually – copying things from one place to another – don’t necessarily always realize how much things could be automated when they get used to certain manual practices. It is also often so that when they are busy, and while we can build a generator, we can only build a generator if the company knows and communicates to us what kind of output they want to generate. It’s hard for us to invent that, but that’s the crucial piece to be involved by them. When people write the code manually, people always have their own preferences on how things should be done and then it could be that they need to decide first internally what a good thing to be generated is. What a good-looking code is: what the code patterns should be applied and things like that. That is what their expert is needed for.
I should also say here and emphasize that when we build a generator, we always build a generator so that it produces exactly like they do it manually today. Maybe there’s a lot of engineers, maybe majority of the engineers, who will say, “No, I don’t want to use a code generator because I have been using some UML tool and it generates awful code. I can’t maintain it,” and it’s of course natural because it’s impossible for the company making the UML tool to know what the code should look like and how it should integrate with their existing legacy code. But if the company itself makes the generator, then it can produce exactly like they are doing it now or would like to do it in the future.
Federico: So you can have also domain-specific code generation.
Juha-Pekka: Correct. Some customers have also measured their performance if they had doubts if the generated code would be efficient. So then they compared these (manual and generated) and then if they could see that a particular piece of generated code was not efficient, and if they could tell what the efficient one was, we could change the generator and then nobody anymore needs to know how to write this particular point or feature. When generated it always goes the same way. So the luxury of this is that it gets automated.
Federico: Okay. I also wanted to ask if users enquire about a web version of MetaEdit+ because this is something we keep seeing with other language workbenches. Sometimes users are happy with the desktop application, sometimes they ask, “Oh, is it possible to have an editor running the web?”
Juha-Pekka: Well, indeed. It’s a trend. Maybe the usability aspect is not particularly good in these web tools when the size of the model gets larger, but even today if a customer wants to put this into a web, well sure, they can use cloud services and run it in a server and easily access it remotely, so that’s not really the problem. Then they still have the familiar desktop capabilities in use, which is normal, at least today, superior to what cloud-based ones can provide in terms of speeding and moving things in a graphical model, for example.
Federico: Another thing related to MetaEdit+ – are companies sometimes worried about the fact that the tool is closed-source or perhaps happy because there is someone maintaining it? How does it compare to other language workbenches that are instead open source?
Juha-Pekka: I personally have not yet come across a company that said that they don’t buy a tool because it’s proprietary or closed. A company may say that publicly, but then they actually do things differently in practice. Interestingly though, I have met and made contracts with companies that say they don’t want to have an open source tool.
Federico: Oh, interesting.
Juha-Pekka: It is interesting and sometimes it’s also challenging for us because we provide open source extensions and plugins for Visual Studio and Eclipse and so forth. But I guess one thing is that many companies when they face a problem, they wanted it to be solved by a company that masters the technology. So if it’s built on top of an open source stack, then it’s really hard for people to ensure that well, it continues to work next year for sure too. That’s the path we have been taking 20 years ago and that’s the path we currently continue. Of course, I understand that companies have their doubts if it’s a closed tool. I think two issues are important here. One is that all language workbenches have the common factor – if something happens to the language workbench, whatever it is, you should be able to translate your existing work to any other format, even the formats we don’t know yet. So whatever happens, you have your work in MetaEdit+, you can make a generator that puts it to CDIF, XMI, whatever format you prefer. But then if companies require it, a common practice has been to have an escrow agreement. It could be that if we decide to stop doing business or become even bankrupt or something like that, then they still can continue using the licensing or even get the source code for the tool. It’s just a contract, and not a closed one anymore. But many companies don’t want to get the source code, they just want it to run and continue to work because most companies are not in the tool business. And that’s normally the way to solve this kind of doubt.
Federico: Good answer. The escrow is a very good solution for most companies that can be worried given that they depend so much on the tool you provide, right?
Juha-Pekka: Yes.
Federico: It becomes a crucial part of their business. They need to think about all possibilities.
Juha-Pekka: The nice part in language workbenches is that they are never closed. They never close any doors, as you can always take your stuff from there if you want. Once the companies realize this, then the typical issues becoming somehow locked into a tool or can’t do anything else than use this tool are not relevant. So vendor lock is not applied similarly to Language Workbenches like MetaEdit+.
Conclusions
Federico: Okay. I have taken up a lot of your time, so maybe I will ask a couple of questions and jump to the conclusion because I think this has been a very interesting chat, but I wouldn’t want to steal your entire day. Do you see any interesting trends in the DSL world?
Juha-Pekka: Yeah, we see many trends, especially small ones because more and more domain-specific languages are being developed. On our company web site, we have published probably 200 domain-specific languages all built with MetaEdit+. So what we see is that languages are built into more and more different domains. And maybe among the trends collaboration is one and- maybe the web portion that you mentioned is another. However, MetaEdit+ being a multiuser tool where multiple people edit the same diagram at the same time, it’s already providing collaboration in a continuous manner, compared to classical IDE kind of tools.
Then also managing the models is one: when the people using DSL is not all programmers, they don’t necessarily want to use Git and things like that, so making the collaboration easy for them is one trend. Also have some kind of governance support, like some people are not allowed to change the models, but they can only reuse them from the other DSL is one trend we see growing in how DSLs are defined. These are some of the things that we see customers requiring more.
Federico: I think this also is related to the next question: I was wondering if there is anything that you are working for a future version of MetaEdit+?
Juha-Pekka: What I’m working on currently is three language engineering cases with milestones coming so I’m a little busy. ln terms of MetaEdit+ product development, I guess improving the expressiveness of the languages is one major thing. I’m not personally involved in developing the tool anymore, others have been in charge of it, but better language engineering capabilities, better model management capabilities and performance are the type of things we are looking to provide in the next versions of MetaEdit+. We really listen our customers, and what they want and need. We don’t do it for research but we do it in order to provide tooling for what the language engineers and customers prefer. So pretty much most come from the users.
Federico: Okay. Finally, I wanted to ask you if someone wants to find more about you, your work and your tool, where should they look?
Juha-Pekka: I think our company website, MetaCase.com, is perhaps the single point because it points to the articles and videos and tutorials and trying out MetaEdit+ if you prefer. But if you are looking for other contacts, perhaps already in your domain there is a person already creating DSLs for your area, so maybe they have some ideas: Performance – modeling or testing DSLs – follow those people and look what they have been doing and what has been the result. Of course, you are welcome to try out our technology as well.
Federico: Good, good. Do you have anything else to add, anything that we forgot to discuss?
Juha-Pekka: One thing I would like to say is that I personally have not seen any other technique comparable to domain-specific modeling languages that can bring 5 to 10 times productivity improvements. That’s why I think listeners or readers should consider domain-specific languages and if they have found out other techniques that provide similar results, please let me know.
Federico: Yes, I would be also curious to find them out. Okay, so I would like to thank you a lot for spending all this time with us providing your unique experience to me. It has been very interesting to talk to someone who has built and seen a lot of DSLs over the years and learned a lot and I hope that listeners and readers can benefit from it as well. Thank you very much.
Juha-Pekka: Thank you. It has been a pleasure answering your interesting questions.
Federico: Thank you. Talk to you soon. Bye.
Juha-Pekka: Yes, bye.
The complete guide to (external) Domain Specific Languages
Receive the guide by email and get more tips on DSLs
