Strumenta 
Why this interview?
Meinte Boersma is a well-known DSL consultant. In this interview, he tells us about his new book “Domain-Specific Languages made easy”, which he has recently published in Early Access with Manning. This book is very important to build more awareness on this topic, so I think it’s a great possibility to discuss it with the author.
Here there are some quotes I found particularly interesting:
I wrote this book because I think what we lack as a software language engineering community is a book which we can give to basically almost anyone, anyone who has some experience with programming and software development in general. So that we can give the book and tell them to read it, and then have a good feeling about what DSLs are about and how you can implement them.
I start with explaining what a DSL is, and what it is good for. Actually, I start with explaining why DSL might be beneficial for you, before I actually start to explain what a DSL is. If you read the first 10 pages then you should have a good idea about what a DSL is and why it could be useful for you.
I think DSLs are reasonably well adopted, but you don’t hear about all successful DSLs. And the reason for that I think is that a DSL is, by definition, domain-specific. So that usually means that it’s specific for a certain company. I think there are a lot of successful DSLs which are used in only one company, or maybe only in one place within one company, and maybe this domain doesn’t even know or realize that the thing they’re using is actually a DSL.
I think one of the main lessons that I learned is that DSLs are software as well. So they might be a very different kind of software than your regular kind of software, but in the end it’s software as well. So you need to have the usual things, the usual best practices for software in place. (…) Once you have a DSL it’s like the secret weapon or the goose with the golden eggs or something like that. But that does not exempt you from having to build it as a decent and high quality piece of software.
If your domain has a lot of “stuff” that looks the same, but there’s still a lot of variability in that, then it’s a good contender for a DSL. To make it a little bit more concrete, if you can capture your domain with relatively few concepts, but those concepts exist in a large variety of shapes and forms and users, then you probably have a good situation for a DSL.
You can find the resources related to this interview here:
Book link: https://www.manning.com/books/domain-specific-languages-made-easy (discount code: twitboer40)
Federico Tomassetti: Hi Meinte, thank you very much for joining us today.
Meinte Boersma: Hi Federico, thank you for having me. I’m glad to be here.
Federico Tomassetti: Yeah, thank you. I think we are very lucky to have you today, because you are a well known leader in the area of language engineering, and you’re also working on a very important book on domain-specific languages. So, I think today we can learn a lot from your experience.
Meinte Boersma: I certainly hope so.
Federico Tomassetti: Good. I would like to start by asking to tell us something about you, to introduce yourself.
Meinte Boersma: Yeah. Well, my name is Meinte Boersma, I am a software developer, software engineer, however you want to call it. I like to program and make software and make people happy with it. I have been doing it for some years, about 20 years by now. Originally I started out as a mathematician. I studied mathematics, but during my studies I always did a lot of programming, programming contests, things like that.
Meinte Boersma: So I always had a keen ear towards the computer science side of things. And after I graduated I thought that going into mathematics research would be a fun thing. Could’ve been, but it was not to be. So I ended up in software development, and after having done that, in let’s say via the traditional route for about 10 years, so I started out at what was then called Atos Origin, after a while. And then I came into contact with model drift and software development.
Meinte Boersma: We did a project at Atos Origin legacy transformation factory, which was very interesting. You take an old piece of code in COBOL in this case and you try to extract the model out of it and then generate new shiny software from that model. That was actually the first time I had some exposure to model driven software engineering. From my studies and from programming I knew a little bit about parsers and things like that, but I had never really done a full compiler construction and things like that.
Meinte Boersma: And certainly I had never seen anything like model driven software development, so that was my first exposure and I’ve been hooked ever since. The virus bit me then, this was about 2007. And I’m still not cured and I have no intention of being cured. So, after that I have done mostly, mainly model driven things. DSL-based things. So after a couple of years I moved to Capgemini where I worked a little bit with intentional software in their intentional domain workbench. I guess we’re going to talk about that later as well.
Federico Tomassetti: Definitely.
Meinte Boersma: Then I went independent, did a couple of interesting projects, again based around model driven software development. I tried making my own language workbench, it’s called Más, it was very interesting. I learned a lot of that, and it failed spectacularly, which is interesting in its own right I guess. Since I couple of years I am working mainly for the Dutch tax agency, or the Dutch Customs and Tax Administration, as it’s officially called I guess. Although the custom parts will be separated off in the near future.
Federico Tomassetti: Regarding Más, yesterday I was talking with a student working on a language workbench and he found out about Más and was an example that really inspired him. And I also remember reading an article that you wrote on the lesson learned from Más so I think that maybe it’s not been successful in the way you were expecting, but definitely played a role in moving the field forward.
Meinte Boersma: Yeah, that was also the reason why I wrote that. I think you’re referring to the post-mortem blog that I did. I think it was important to get that out to the field that that was already very valuable for me to realize that this is why it’s not working and this is why I had to stop it, this is what I would’ve had to invest in it still to get somewhere that it’s good enough to be useful for a client or a potential client. To get that out to our field. That was an important message, I think.
Meinte Boersma: Myself I have learned a lot about the whole experience, so in that sense it’s not a total failure. But it’s also not a big success in the sense that Más still exists and is being used, et cetera.
Federico Tomassetti: No, but I think that it’s also something that as a community is important and is really nice to share and teach like you’re doing with the book. We will talk about it.
Federico Tomassetti: Before we talk about the book I would like to talk about your current company, if I’m not mistaken is called DSL Consultancy. So, the name, already suggests a little bit about the kind of services you’re offering, but if you could tell us more about this?
Meinte Boersma: Well you would think that, but especially in the beginning I got a couple of requests whether I would be interested in doing projects involving cable, like cable internet and such, because DSL and ADSL is also a technology thing. Apparently people thought that I was in the cable business. I have this company as a private one person company since 2011, and I’ve done a couple of projects there, a couple of consultancy things as well.
Meinte Boersma: At the moment it’s a little bit of a shelved company, in the sense that I have a day job at the Dutch Tax Agency. But yeah, in the future I intend to pick up on the “real” consultancy gigs at some point, especially after the book’s been done and I get some nice opportunities from that direction.
Federico Tomassetti: Do you have experience, and are you looking for clients primarily in the Netherlands, in Europe, or worldwide?
Meinte Boersma: Well, especially at the moment primarily in the Netherlands, but that’s mainly for logistical reasons because I have a family. I have three young kids, so it’s not very realistic for me to say, I’ll hop over the pond for a couple of months to do a job there. I guess at the moment everything has to be done remotely, then it’s of course less of a problem, although with time zone differences it’s still a difference.
Meinte Boersma: It’s still a bit of a hassle. The Netherlands, Europe, for logistical, practical reasons is the main target. But my first job was actually in the U.S. I had an interesting job around Xtext in the U.S., in San Diego. A bit company there. Which was very interesting. It was a nice experience as a first job to go into the U.S. and to arrange all that, and learning a lot and being able to help those people with Xtext.
Federico Tomassetti: So Xtext is a very important role in the community, we will talk also about that. Now I think would be interesting to talk about the book. So, my first question is why are you writing this book?
Meinte Boersma: Very short answer, because I’m crazy. But that’s not very useful. I think what we lack as a software language engineering community is a book which we can give to basically almost anyone, anyone who has some experience with programming and software development in general. So that we can give the book and tell them to read it, and then have a good feeling about what DSLs are about and how you can implement them. Because I don’t think we really have a book like that or a corpus of learning texts like that so much. Most people we meet in our field, for example in the Strumenta community, they either have a master’s degree or a PhD in computer science, have been doing this for 20 years, or got into this field via a different route but have spent years and years learning about this stuff. Learning about the basics, learning about the more intricate stuff, learning how to work with tools like MPS and such.
Meinte Boersma: So there’s a lot of investment up front. And I guess in a certain sense you need to invest in it as a person to learn about this stuff, as you have to do for everything. But we as a community should also not make it more difficult than is necessary. A book which has a good introductory level, which doesn’t assume too much, I don’t assume that you have a computer science degree of any kind, I just assume that you have a bit of software development experience and are able to write some JavaScript or can pick it up easily. So that’s really what I require as a minimum.
Meinte Boersma: Then I tell what are DSLs, what are they useful for, when are they not useful, is also an important question. And then I explain all the basics like what is an abstract syntax tree. We use projectional editing in this case, so I just ignore the whole parsing business, which is interesting because, for example, a lot of reviewers keep coming back “yeah but when are we going to start writing grammars”. Yeah, sorry not in this book. I can point you to a different book, but this book we’re just going to do projectional.
Federico Tomassetti: I think that people tend to teach in the way they learned, and maybe many have learned initially Xtext, and so they were familiar with parsing, so in their minds you have to go through the steps to come to the projectional editing, I guess.
Meinte Boersma: Yeah. Well, that’s another reason to write this book. I think there are not enough books yet that are about projectional editing. There’s a couple of books, everything that Markus Voelter writes will definitely have projectional editing in it. The last DSL book by Martin Fowler also has a bit of projectional editing in it, but for the rest there’s not that much out there. So that’s the second big reason to write this book, and that’s I wanted to do a text about projectional editing specifically.
Meinte Boersma: I think that’s a nice setup because it also kind of prevents the usual route you probably would take if you went a parsing route. So I really have to re-think how I explain all this stuff in an order that makes sense if you do projectional editing anyway. That may be a different order than when you do it with parsing. So beyond purely projectional side of thing, of course still have to explain stuff about type systems, code generation, how do you evolve a DSL, things like testing and such. That’s definitely also in there.
Meinte Boersma: And then at the end of the book I intend to spend some time on what I did not have space and time for to explain in this book, so points to other books maybe, points to topics like what is a language workbench. Why is projectional editing better or nicer than parsing, when is it better, nicer than parsing. Questions like that. Yeah, that’s the last chapter’s going to be able that. A couple of points to these things. Maybe there will be a second book at some point.
Federico Tomassetti: In practice it’s a book that a software developer can pick up to learn how to be in practice DSLs that run in the browser, and in particular DSLs that are based on projectional editing. That is the most advanced form of editors that we use in the domain-specific language field. Instead of using textual based languages, projectional editing.
Meinte Boersma: Exactly, yeah.
Federico Tomassetti: Do you also explain what is a DSL, or in which case you should use a DSL? To, say, increase awareness about this problem? Or do you expect that the reader is already aware of this before buying the book?
Meinte Boersma: Well there’s always a little bit of a chicken and egg problem here because the title is Domain-Specific Languages Made Easy, which is a bit of a corny title of course, but it fits in the series that Manning is doing. So you have to be at least aware of the term domain-specific language, or maybe you can imagine enough from the term to at least read the abstract. But I start with explaining what a DSL is, and what it is good for. Actually, I start with explaining why DSL might be beneficial for you, before I actually start to explain what a DSL is. If you read the first 10 pages then you should have a good idea about what a DSL is and why it could be useful for you.
Federico Tomassetti: And how difficult was the process of writing the book? I mean the book so far? Because maybe we should explain that the book is already available, even if you have not completed writing it. So, someone can buy it and already read a good amount of chapters, and more and more will be released over time.
Meinte Boersma: Well it started a couple of years ago when I was contacted by someone from Manning publications asking whether I would be interested in writing a book, and crazy enough to write a book. So, then I said yes I am certainly interested in that. Spoke a little bit about the contents. The next step was writing a pitch, so what is a 10 page document about why I think this book is necessary, why current existing books are not good enough. Why should I be writing this book, et cetera.
Meinte Boersma: So, based on that pitch they gave the go-ahead. Then you get a development editor, and I got a great development editor. Her name is Heidi Nobles, she is a professor in the U.S., and she really helped me enormously with learning how to really write in a teaching style. I mean I can bang out some text on a keyboard no problem at all, but really writing a text which allows people to learn is a different thing. So she really supported me and gave a lot of feedback on my writing style. Reigning it in, so to speak. That has changed my writing enormously.
Meinte Boersma: So even I’ll read back texts from a couple of years ago, or even from half a year ago, I’m thinking who wrote this? So that’s a very interesting process. It’s also a bit of a slow process because I wrote the first couple of chapters quite rapidly, and then it went into review, and then we changed a lot around. Basically I think I ended up cutting three quarters of the first chapter, and re-writing the rest. And the second chapter is now going to be chapter 13, and I re-wrote everything in the third chapter which is now chapter two, et cetera, things like that. So that happens, that apparently is pretty normal in writing a book. I can see that’s pretty normal, but it’s also very time consuming, so that’s why we’re not there yet.
Meinte Boersma: Now we are in MEAP, in Manning Early Access Program, so it’s already available. The first six chapters are available right now. Seventh is almost done, so that should hit the MEAP in maybe a couple of weeks. Now I have about half a year to finish the rest of the book, which should go rather more rapidly than the first six-seven chapters in the two years. Also because I have now a sabbatical leave from my day job so I can really focus on that.
Meinte Boersma: And of course you do notice that once you have learned how to write, the writing process speeds up as well.
Federico Tomassetti: I don’t know, maybe the technical chapters are easier than the explaining what a DSL is, or have they had comparable difficulty?
Meinte Boersma: Well, it’s very different. As said, I re-wrote chapter one, I think two or three times and threw away basically everything that I had. At some points chapter one was definitely very difficult to write, and the end result is only 10 pages long, so. Technical chapters do tend to go a lot quicker, as soon as you have the codes really set up right.
Meinte Boersma: As soon as you know where you’re going with the code and explaining it, then it tends be relatively easy. Also an interesting thing in writing technical chapters is that at various points you think “hey I didn’t explain this well enough”. So, then the chapter sort of balloons up, or runs the danger of ballooning. So in fact what is now chapter five and six, which is about editing the projection, so editing the AST through a projection, that started life as chapter five, or maybe even started life as the second half of chapter four, or something like that. So you read it back and you think mmm, yeah this is maybe not… this is maybe too quick or I jump to conclusions too quickly, or I leave a couple of steps out.
Meinte Boersma: So in that sense writing those technical chapters is relatively easy in terms of size, although you still have to pay a lot of attention to how you set up the code, how you work towards a certain goal, and not missing any steps.
Federico Tomassetti: Makes sense. Okay. As I said, we can benefit from your experience with DSLs, and so I would like to ask you some questions about your vision on DSLs. So, what developments are you seeing in the domain-specific language work? We have already entered a little bit to the introduction of projectional editing, but do you see any trends or any interesting new development?
Meinte Boersma: Well, there is an obvious trend from the last couple of years, and we’re speaking five, maybe seven years I guess. And that is that the tooling is getting a lot better, and also a lot more user-centric. A tool like MPS is now really hitting its stride, and really becoming quite mature. And that helps a lot in getting the message out there and just building DSLs and helping people with that.
Meinte Boersma: I think also there’s slowly more interest in the community for actually helping people with DSLs. I think we still have the tendency as a field to want to apply the field to ourselves, in the sense that it is very tempting to write a language workbench. I fell victim to that myself as well, big time. It’s very tempting to try to first make a very good language workbench and have really good meta languages so that we can build DSLs, better DSLs, and we can build them quicker for our business users, our business clients, or however you want to call it.
Meinte Boersma: But I think we’re sometimes forgetting to actually go to that business, and the business is certainly not coming to us automatically. We really have to work on that. Especially, business people they will not know what a DSL is until they’re hit in the head with it basically. And then there are complete edits. I’m convinced that selling a DSL to a business-person is like shooting fish in a barrel. I’ve had very nice experiences with that. One of the best experiences with it I was working on a project which was already model driven, but we had a problem with one specific area which had a bit more logic on screen and fields being swapped in or out depending on certain other things. These days it’s fairly standard to be able to model logic like that, but those days it was not so trivial.
Meinte Boersma: So I made a small DSL with Xtext, and I showed it to a couple of our business analysts. Well we’re having trouble with the screen, so I made this thing called a DSL, it happens to be textual, so I hope you don’t mind that too much. Well, this is how I would model the screen with that, hopefully that helps. And her response was move over I have to finish the screen. So she completely saw that it was working and that she could benefit from that. And she also understood how it was working, so I think it’s really easy that if you show the right kind of DSL to a business user it’s a done deal essentially.
Federico Tomassetti: I agree that, I think that at some points we were trying maybe to be DSLs for developers and this doesn’t work as well as building DSLs for non-developers. But maybe sometimes we still are writing content that is for technicians. So maybe business people are the ones that will say yes to DSLs, but we are speaking too much to developers that could instead be interested in writing their own language workbench, not in really using a DSL. So it’s complicated.
Meinte Boersma: Yeah, and I do understand where the temptation is coming from. It’s a very logical kind of thing to also want to do, but I think we have to actively go to the business, sell ourselves a bit better. I hope the book can help with that a little bit. And just go out there and do this kind of stuff, and build stuff, maybe even we build some DSLs without knowing beforehand whether you get paid for it. And in a certain sense that’s not so different from having an open-source project on GitHub with some technical DSL, and there are enough of those. I mean there are like hundreds of data-modeling DSLs out there, all kinds of DSLs for technical purposes like having better CSS, things like that.
Meinte Boersma: So, DSLs are out there, but a lot of them are technical. Why not instead of making a technical DSL really try to make a business DSL and try to go to users with that? That’s also the reason why I am targeting projectional DSLs because that looks a lot more like a regular desktop or business application than any textual DSL will be. And you have much more freedom in how you integrate your DSL editor with the rest of your process. So you can make it much more look like a business that happens to have DSL instead of it, but it’s nicely integrated with the rest of your process. Whereas if you have a textual DSL you often drag along an ID “for free” with that. Which you somehow have to integrate into processes, so that’s a much bigger challenge than actually coming with a projectional DSL.
Federico Tomassetti: But, I mean, one of the biggest reason of frustration for me is seeing so many experience of successful DSLs like the one you have discussed, but at the same time we can see that there are not so many companies adopting DSLs or at least doing that publicly. Maybe they’re using DSLs, but one could get the perception that it’s just a minority of companies out there taking advantages of DSLs. Do you think there is any particular reason that is limiting the adoption of DSLs?
Meinte Boersma: I think DSLs are reasonably well adopted, but you don’t hear about all successful DSLs. And the reason for that I think is that a DSL is by definition, domain-specific. So that usually means that it’s specific for a certain company. I think there are a lot of successful DSLs which are used in only one company, or maybe only in one place within one company, and maybe this domain doesn’t even know or realize that the thing they’re using is actually a DSL.
Meinte Boersma: So they also don’t go out to the world shouting “hey we have this nice DSL, maybe you want to use it as well”. They might not know the term, it might be a competitive advantage to be the only ones having that DSL, the thing might be too specific anyway for anyone else to use. So there’s a reason why you don’t hear or see as many DSLs as actually exist in business contexts.
Meinte Boersma: I think that’s one limitation, which is not necessarily a limitation for adoption, but it is a limitation in getting the word about DSLs out there of course.
Federico Tomassetti: Yeah, so as you say, maybe it’s a competitive advantage and so one doesn’t spread the voice, so maybe the fact that they work limit their success in a way. So that’s a challenge for promoting them.
Meinte Boersma: That’s already true for what I’m doing at the Tax Agency, because it’s not open source, what we’re doing. There are some publications out on it but generally we are under an NDA to not talk about that too much, so I can share what has already been publicly available in stuff that has been vetted, but for the rest we cannot throw it on GitHub right now, which I think is a pity. Because I think it should be. But right now that’s just not an option. So it’s a very successful DSL, or a set of DSLs actually that’s being used by… well, I think in the meanwhile by a couple of hundred of people within the Tax Agency, and with far-reaching consequences. So really a lot of work has been done with this product, which is called… that’s stuff that I can tell, it’s called ALEF, which stands for Agile Law Execution Factory, so A-L-E-F.
Meinte Boersma: If you Google for that you should find some stuff about it. There’s a couple of videos on the different sites from a couple of the community meet-ups, and there is also some articles from someone called Mariette Lokin, where she also explains about how ALEF is used within the Tax Agency. So, those are success stories that you can get at, but I think for every such story or exposure is probably two or three DSLs that are just not seeing the day of light outside of the domain they are being used in.
Federico Tomassetti: I think that many people are listening to us may be familiar with this project, but for those who are not familiar, I will try to explain it how I understood it. Then please correct me. If I understand, basically, the Dutch Tax Agency, like every tax agency in the world every year has to adapt the new calculation of the taxes because tax code keep evolving, and so they have this big problem of having lawyers or anyway expert in taxes, verifying that the new code is aligned with the changes that happening below, and so verifying they are aligned and do that also in a short time.
Federico Tomassetti: Because this change every year, so you cannot take five years to verify that it’s correct. Right?
Meinte Boersma: Yeah, that’s completely correct. That’s why it’s called agile law execution, because yeah, you have to change the software whenever the tax code or the tax law changes as well. That’s absolutely correct. Give a little bit more detail.
Meinte Boersma: What usually happens is you have a law, but the law itself, the law tax itself is not in itself precise enough to create software with. So what happens then is that the law is… a couple of lawyers and business analysts have a look at the law and they create rules from that. They are called rules analysts, within the Tax Agency. So that’s basically the law but then made precise enough that you can actually stand a chance of making software with that.
Meinte Boersma: And what normally would happen is that there’s like hundreds or thousands of pages of Word documents, would’ve been passed down to developers who then make code for that and once they were done you have to test all of this, so you have to input a lot of testing situations into the software that was produced, and then see whether it’s all correct, et cetera.
Meinte Boersma: So that’s just the usual way of doing things. What ALEF allows you to do is to input these rules directly into the ALEF tooling. So, these rule analysts, they would re-type these rules by themselves, so instead of typing it into Word documents, they type it directly into ALEF so ALEF can verify the correctness, and help a lot with guidance in the sense of… if you want to speak about the this of that of dispersion, the income of the children of your neighbor.
Meinte Boersma: The tool will help you with formulating that by giving the option, okay I know what a neighbor is, I know they can have children, I know they can have an income, et cetera. And check whether things are typed correct, are complete, whether cases are missing or not. And the nice thing is you can test this. So you can formulate test cases and say okay, shoot this test data to the rules, have the rules work on the data, and see whether the right results come back. For example, the right taxation comes back.
Meinte Boersma: So that’s very powerful because we literally cut out software development from this whole process. So, whenever the law changes, then those rules analysts just have to update those rules, and they add new rules versions for the next year’s tax law, they add test cases. They check whether all the existing ones still do what they are supposed to do, and they check whether the new or the added rule stuff is doing what it’s supposed to do. And then they press the button and the stuff gets deployed as a web service in our case, to be integrated into the rest of the whole chain.
Meinte Boersma: So, literally no developer has to write code from looking at tax law or these rules to make this happen. And that’s very powerful, it really empowers the rules analysts and it really cuts out a lot of effort.
Federico Tomassetti: So, were these analysts really supportive of this new tool? Or were they resistant at the beginning of changing the way they were working?
Meinte Boersma: Well, change is always a bit difficult, so I don’t think that everyone was immediately on board, but we’re slowly getting into the steamroll phase of things in the sense that it’s now becoming more a question of why not use ALEF in projects, than why use ALEF in projects. Which is a good position to be in. But it has been a process of years. So you always have the early adapters, and you always have slow adapters, or maybe resisters. But we’re now getting up to steam that we can roll this out to more and more places in the organization.
Federico Tomassetti: What is the level of maturity? Does this something already been using in production, let’s say? I don’t know if this is something you can disclose.
Meinte Boersma: Yeah, it’s already in production. So it has been used in a couple of places within the Tax Agency that are relatively high risk in a sense that, things should not go wrong there.
Federico Tomassetti: So I can give some confidence to people considering DSLs because this seems like a very critical place to adopt this also. If it works for them it should work for any of you out there.
Meinte Boersma: Yeah.
Federico Tomassetti: There are like one other million questions that I would ask you, but I think we will need to make choices. So I would like to ask you if there are any lessons that you have learned in designing DSLs. I know it is difficult to share lessons that are valid in general, I don’t know if there is something that…
Meinte Boersma: Yeah, I think one of the main lessons that I learned is that DSLs are software as well. So they might be a very different kind of software than your regular kind of software, but in the end it’s software as well. So you need to have the usual things, the usual best practices for software in place. Like you need to have continued integration, you need to do version control, you need to have an architecture. You need to do quality control, you need to do testing, et cetera. Once you have a DSL it’s like the secret weapon or the goose with the golden eggs or something like that.
Meinte Boersma: But that does not exempt you from having to build it as a decent and high quality piece of software. That’s the main lesson that I’ve seen in implementing DSLs along the years.
Federico Tomassetti: In your book do you focus exclusively on the technical side? Or can we find some advices here and there on how to design DSL?
Meinte Boersma: The second to last chapter will be about designing DSL or rather a process for designing DSLs in conjunction with your domain experts. Together with the first chapter which is about why DSLs and what are DSLs, that’s the most non-technical chapter in the book and it presents an iterative process of working with your domain experts to find what type of DSL you should make, what you should focus on at first, we choose how to focus on things. How to use things like whiteboards and paper mock-ups to actually come up with a decent syntax, and to check that and validate that syntax with your domain experts, et cetera.
Federico Tomassetti: I think this would be incredibly valuable because I don’t think there are many good resources on this out there, so thank you for writing this.
Meinte Boersma: Well, in a certain sense it’s the “usual” stuff, as in it’s nothing new. Again, it’s just software, so it is still about what do your users actually need, how do you pry that information out of them, and how do you go forward with that. But then specialized for DSLs. I can really talk about, okay, how do you use whiteboards to flesh out your syntax for example, your notation. You can also focus specifically on things like type systems and such and how do you ask your domain experts information which you need to have in order to make a type system, et cetera.
Federico Tomassetti: Good. I wanted also to ask you about different language workbenches before you have named Xtext, of course we have talked about MPS, I think you also name intentional software. So, you have created Más, I think you have experience with a lot of different language workbenches. Can you compare them for us, or can you tell us something about the differences between these language workbenches?
Meinte Boersma: For a couple of years we were in the language workbench challenge. First year was called competition, but that was just before my time that it was involved with that. But I think the feeling then was that these language workbenches were too different to really compete against each other, or at least to make a fair competition with them. So that’s why it was re-named to challenge.
Meinte Boersma: I think that situation persists to this day. All these workbenches are really very, very different in terms of which paradigm they offer. What level and what kind of integration they offer, so it’s very difficult to compare. My name happens to be in the list of authors of an article that a couple of people from the language workbench challenge and software language engineering community did a couple of years ago, especially Markus Völter and Tijs van der Storm, well they did 90 percent of the work if not more of that article.
Meinte Boersma: That article also tries to compare all of these different language workbenches in terms of maturity, et cetera. It’s a very diverse matrix which you can draw up. They are really very different. They all have their pros and cons, they certainly also have very differing levels of maturity. I think at the moment the most mature ones are definitely MPS and Xtext. There’s a couple of other ones that are not far behind, like a couple of technologies from the Eclipse ecology, outside of the Xtext of course.
Meinte Boersma: There is a couple of academic language workbenches as well. I say academic, well, languages workbenches that started life as an academic research project and have attained now some level of maturity that is good enough for doing actual work with. We already mentioned Tijs van der Storm, he’s making Rascal, and that looks more promising every year as well.
Meinte Boersma: Unfortunately, Intentional domain workbench has gone underground already years and years ago, and I’m not sure it actually still exists in any shape or form. It was very interesting… it was a very interesting product, very advanced, especially for the day and age. Really impressive what they could do. But it was also incredibly difficult to try and use yourself.
Meinte Boersma: Once you had a nice workbench, once you had a really… set of DSLs, your users could use it very well. But getting there was really hard. Much harder even now with MPS. MPS also has a certain learning path, learning hill. But Intentional domain workbench had a learning overhanging cliff or something like that. It was just too difficult to use. I think that’s also what hindered the adoption because outside of the Intentional people themselves there was just no one that, maybe Markus could use it. But outside of that there was no one that could actually make their own domain workbench with it.
Federico Tomassetti: Yeah, and maybe also took probably more than 10 years anyway to MPS to increase its usability. The other day I was talking with a person that say “oh it’s really hard to learn MPS, it takes two weeks”. And I was thinking well, when I started it used to take six months, so it means that it is getting easier.
Meinte Boersma: Getting better fast. Yeah, absolutely.
Federico Tomassetti: I think one of my final question will be, is there any situation in which you think DSL will work really well, or a contest in which instead the DSL will not be the right choice? And again, I know it’s a very open question, but I want to take advantage of your expertise.
Meinte Boersma: I tend to look for something which I like to call conformers and variability. If your domain has a lot of “stuff” that looks the same, but there’s still a lot of variability in that, then it’s a good contender for a DSL. To make it a little bit more concrete, if you can capture your domain with relatively few concepts, but those concepts exist in a large variety of shapes and forms and users, then you probably have a good situation for a DSL.
Meinte Boersma: So one of the obvious ways to meet the criterion is, for example, to have a business domain where you tend to have relatively few concepts, but there is a lot of business logic involved. And business logic, we know how we can express that, we can make expression languages for that, and expression languages tend to have relatively few concepts, but which can be used together in a nice way, in a composable way, or in an orthogonal way to really express that business logic that you need to express.
Meinte Boersma: So that’s basically what I look for. It needs to look, on the whole, homogeneous enough to know that there’s a couple of important concepts and not that much beyond, and that those concepts generally come in the same form. But there also needs to be a lot of variability in the sense that how they are used and where they are used needs to be relatively heterogeneous.
Meinte Boersma: For example, a counter example for a DSL is configuration languages, or configurations. As soon as you can express it as a bunch of YAML or properties files, things like that, you probably don’t have a DSL, or not really a good one. But for example if all of a sudden there’s a lot of expression, there’s a lot of logic, expressions, going on in that configuration, then you might have something that would be worth making a DSL for.
Federico Tomassetti: Makes sense. I think we are running out of time. But I will like to discuss a little bit how people can buy your book so they can learn more than we were able to discuss today. Can they go just on the website at Manning and look for the book, Domain-Specific Language Made Easy?
Meinte Boersma: Yeah.
Federico Tomassetti: And if they buy it now can they get the physical copy when the book is finished?
Meinte Boersma: Yeah, exactly, yeah. You can buy it in two ways. Just the ebook or the ebook and I think they call it the p-book, or physical book these days. Either is possible, but if you do buy the book, make sure that you use a discount code for it.
Federico Tomassetti: Seems like a good idea.
Meinte Boersma: I think we will mention that in text somewhere?
Federico Tomassetti: Yes.
Meinte Boersma: That’s probably easier, also provide a link there. So the discount code will save you 40 percent off the price, and it also works on every other Manning book. Maybe another to mention as well is that I’m going to do a Twitch session in the near future, October 17th, which is a Saturday.
Federico Tomassetti: Yeah. I hope we have published this.
Meinte Boersma: If not, then, the video will be on the Twitch site still, I think. So that might also be interesting. In the Twitch session I will be going through the book basically in lightning speed, so starting with a very tiny idea for a DSL, idea for a tiny DSL, I will try and implement this live in about two hours time. This is going to be a very interesting challenge, but yeah I’m going to talk about things about how do you construct ASDs, what is an ASD actually, how do you make a projection for this very simple DSL. How do you do things like code generation, a very little bit of type system. Things like that.
Federico Tomassetti: Good. So I think a lot of interesting material to finally get particular idea of what a DSL is. Okay, so that will be my last question. Is there anything that you wanted to discuss and I didn’t ask?
Meinte Boersma: What might be interesting is the lessons learned from Más.
Federico Tomassetti: Yes, that would be very interesting.
Meinte Boersma: We already talked about the blog itself, but the contents of the blog we didn’t discuss so much. So, a little bit of background. I started Más in, I think in 2012, somewhere around that time. After I attended my first language workbench challenge, and I thought maybe I can do this as well. Probably, cocky 2012 version of me thought, hey I can do this as well. So I started building that. I used Martin Thiede’s Concrete editor, which was basically state of the art at the moment for projectional editing on the web, so I built a whole language workbench around that. The main reason why I stopped developing Más any further is because I hadn’t, apart from that there was no money influx, I realized that I had not tackled the integration problem. Basically I made a language workbench that said this is how you make an editor, have fun, whatever you want to do with it figure it out yourself.
Meinte Boersma: And that’s not a very good proposition. You really need to think about how you can do something with the models that your domain experts make in your editor. For example generate god from that, and how you do that, and how you integrate with the rest of your software development process. Doing things like continuous integration, et cetera. So that was the main reason to stop with Más, and after I realized that I actually went to work for Mendix which is, I mean it certainly does not make a language workbench, but what they do make is modeling software. And they’re really thinking about this integration problem because I try to give their users an environment that’s as integrated as they can make it.
Meinte Boersma: So you model a little bit of an application, you press the deploy button, and a minute later you have your application actually running somewhere and interacting with databases and web services, and the REST services, et cetera. So that’s where I should’ve gone more… what I should’ve thought about much more when developing Más. I think it’s also something that in general we have to think of as a software language engineering community. How do we integrate our stuff with the rest of the software development. There’s interesting things going also on with things like live programming. And I think we should really look towards that and join in on the fun there. Also add value through those kinds of developments.
Federico Tomassetti: Yeah, no. Integration is definitely the important part, but to put things in perspective, I guess that Mendix had an amount of resources that is difficult to match for a single developer, no matter how skilled.
Meinte Boersma: Yeah, absolutely.
Federico Tomassetti: So maybe in the next interview we will also talk about your experience at Mendix.
Meinte Boersma: Yeah. We don’t have enough time for that now, but yeah, that was also definitely an interesting experience. Learned a lot from that as well, very different kind of experience, of course, to making stuff on your own. But let’s save that for another time.
Federico Tomassetti: Now we can benefit from your experience by reading the book.
Meinte Boersma: Yep.
Federico Tomassetti: Okay, so I think I took over one hour of your time, so you’re being very nice to answer all of our questions. We will also add all the links in the transcript so people can take advantage of the discount and get your book. Thank you very much for being with us today.
Meinte Boersma: Well, the pleasure was mine and I’m happy to oblige. Thanks for having me.
Federico Tomassetti: Thank you, bye.
Meinte Boersma: Bye-bye.
The complete guide to (external) Domain Specific Languages
Receive the guide by email and get more tips on DSLs
