Igor Dejanović, the founder of the textX project, tells us about his experience implementing domain-specific languages and tooling for hardware testing and law codification and how the tooling benefits the users. We also talk about the business value and teaching of DSLs.
It was really, really great to see how people react to the whole idea, how students react to the whole idea. So at first many of them do not believe it’s possible to express the solution at that level (…). After they finished the course on DSLs, from what I heard, they go to the companies and start to advocate the approach there.
TextX is used for developing small languages, DSLs but also for parsing. So if you need to parse something, it’s very easy to specify the parsing in textX, because with textX you specify the syntax with very compact and elegant language and then you don’t have provide usual semantic actions to build the output.
You connect the controller to a device that sits on your table. That device is able to simulate the real system in real time. Your controller is fooled into thinking that it talks to the real system while it talking to the simulation. Then you can run bunch of tests cheaply. You can repeat it. You can do continuous integration and you can test even the states that would be dangerous in real life.
We can quickly build the tool chain and then if needed we can later build this complex, more expensive additions like graphical editors and simulators and stuff like that. But we can get quick feedback from electrical engineers about the tool and language itself, and when it is all cleaned up we then can build this above that.
The business value is, first, we can iterate much faster, so we can get feedback from the user of this languages much faster, so we can build cheaper and faster.
The language is most of the time very loosely defined. With the process of making it more formalized you are actually cleaning or building a better understanding of the language itself. So I think that is another benefit of applying DSL, because when you have some loosely defined language then it may be interpreted differently by different people. But if you formalize it, make a compiler for it, make a formalized semantics for it then you build a common understanding for that language.
I really believe that DSL approach is a way to go but I think still we have a lot of work to do to make it happen. Probably more teaching, more books on the topics, raising awareness of the approach, and we need to constantly improve tools we’re building. More marketing. I think we need somehow to avoid that perceived lock-in that are usually connected to DSL tooling.
Sergej: Welcome to Beyond Parsing. This podcast is dedicated to language engineering, creating custom languages and using them to develop domain specific software tools.
Federico: We are your hosts Federico and Sergej, two language engineering consultants.
Federico: Today our guest is Igor. Igor is a professor of software engineering at the University of Novi Sad and a language engineering consultant. He’s an active open source contributor and author of textX, a free and open source library for the development of DSLs and parsers in Python. Thank you Igor for joining us.
Igor Dejanović: Hi Federico. Hi Sergej. Thanks for inviting me and thanks for running these podcasts. It is really great to have a podcast focused on the field of language engineering.
Federico: Good. At least we have one enthusiastic listener so that’s encouraging. Can we start telling us a bit more about you so that our listener can get to know you better?
Igor Dejanović: Okay. I work as an associate professor at the University of Novi Sad. There I teach several software engineering courses. Most relevant for this talk is a course on DSLs, which I started back in 2013 so it’s seven years now. I’ve been in a software engineering for 20 years. Although I’ve been working at the university all this time, I tried to keep myself in shape by doing consulting work and then to transfer that knowledge and experience to teaching and vice versa, use my teaching experience as a vehicle for advancing in the consulting job because there is a famous quote, I think it’s attributed to Richard Feynman, “If you really want to master something then teach it.” I tried to make a balance between those two. It is fun, but it’s not always easy. And I really like language engineering and especially domain specific languages, so I spend quite some time working on open source project in that area. Yeah. That would be in short how I keep myself busy.
Federico: Good. And then I’m curious, how did you find out about domain specific languages at first?
Igor Dejanović: Yeah. It started back in… I think in 2002. In the beginning it was not about DSLs, but it was more about model-driven software development. There was a project done by my mentor and one of my colleagues. They were doing development of business information systems using really simple but very effective approach. They would build a very simple tool that would extract some metadata from some source and they would use that metadata as a model. For example, they would pull a metadata from a relational database and then they would use that as a model and then they will add some information to that model, annotate that model with some additional information. And then they would build a code generator for the target platform. So with this approach, they were able to really quickly build a fully functional CRUD applications.
Igor Dejanović: They achieved more than 80% of code generation so it was really an effective approach. At that time they were hired to do a really big project for a health insurance fund. It was their information system re-engineering. It was a large system. Size would be approximately like a 1000 entities and more than 1000 GUI forms. I joined the team so I was exposed to that model-driven software development idea at that time and it was really great. It start me to look into that field more. Real mind shift I think happened somewhere in 2004. It was I think a paper by Sergey Dmitriev, Language Oriented Programming. It was an article actually published. And that was really eye-opening, that idea. Sergey really nailed it by explaining why development with the general purpose languages is hard: because you need to do concept mapping between your conceptual solution in your head and general purpose language constructs.
Igor Dejanović: So it was really, really a great idea. And I then started working on that idea and the tool chain around that. I remember around that time I was start using the Xtext. It was part of the openArchitectureWare and there was a book published in 2006 by Thomas Stahl and Markus Völter. It was Model-Driven Software Development, a very practical book with a lot of experience from the industry and very pragmatic. So that was actually the time when I started to be fully immersed in this whole field and whole idea.
Federico: I can really relate to your stories because I also started with MDD and I went through Xtext. Unfortunately I didn’t find out, when I was starting, about the book from Markus, otherwise I think it would have saved me a lot of time. Nice. And today you are teaching domain specific languages, which is great because I think many universities should need to do that, but can you tell us a bit more about your experience teaching domain specific languages?
Igor Dejanović: Well yeah, it was a really, really great to see how people react to the whole idea, how students react to the whole idea. So at first many of them do not believe it’s possible to express the solution at that level. So I wouldn’t say at the higher level of abstraction. I would say at the right level, so at the domain concept, and then actually generate or integrate the solution. In general, I have a very positive experience. After they finished the course on DSLs, from what I heard, they go to the companies and start to advocate the approach there. And even conduct a little courses and presentations and stuff like that. So I don’t have a full information about what’s happening in the companies when they arrive but I see… I heard some side channel talks, what’s happening there because companies tend to keep those approaches they find very attractive like their “secret weapon.”
Igor Dejanović: They don’t like to tell us all about their success or failures. But there is an interesting story about a tool for a student that actually go to the company. It was maybe even before I started this DSL course, so they heard about the whole idea through some other courses my colleague and I are teaching. They were hooked on the idea, they went to a company and they try to persuade the management that it is sound approach and that should do that. And one of the tech leads joined or found that attractive. And they formed a team inside the company to work on the tool chain for model-driven software development or DSL approach and generating code out there. And they worked on that I think more than a half a year, maybe eight months. And they failed.
Igor Dejanović: They failed and they called us, my colleague and me, and we went there to hold a meeting and see why it happen? And it was obvious to us what was wrong. They tried to do some kind of holistic approach to make a tool chain they felt could describe everything with that, and generate a 100% of the code. So their domain was too broad and they didn’t have any strategy for incorporating manually written pieces of the system, what they actually tried to build was another general purpose language. I noticed, that is a common mistake with someone who is starting to do this.
Sergej: Yeah. I think this is actually an interesting observation that if you create a domain specific language for… That is more abstract than the general purpose language, you actually still need to think how it will integrate with the rest of the system. And either you provide some sort of escape hatch to the general purpose language or you somehow limit the DSL in scope, I think, so that the general purpose language can call parts of the code that are written in DSL, but the whole code around it is written in a lower level language. But I think, also in my experience, most of the systems need to somehow combine both but the DSL and the general purpose language. What do you think about this?
Igor Dejanović: Yeah, exactly. It’s usually more that you need to build several, because DSL should be focused. So it’s usually you need to build several DSLs and find a way to integrate those DSLs, and then fill the rest of the space, probably with general purpose [language]. You cannot cover the domain from start probably, so you should probably start small. You’ll build just for this part, some small language and do it there and have a strategy to integrate with the rest of the system.
Igor Dejanović: After that they try it. Second approach. And this time they were successful because they just made a little DSL. It was like entity-relationship language, like entity language we always see in Xtext documentation or textX documentation or, I don’t know, Telosys. So with extension to describe the APIs and it was very successful. They had a more focused domain and they made code generators. It was a success and the company helped them to make a spinoff, a startup company that will pursue this direction.
Sergej: So when you say it was a success, how do you determine, by what measures, what is success?
Igor Dejanović: Well, they started… They made a startup to pursue this idea and they did some great job in marketing. So they won some startup competition and got some financing from the venture capitalist. They worked for several years, build a team, develop this tool. It was a relatively simple tool, simple language, but they managed to persuade people that it is good and it was actually good for what it was built for.
Sergej: What kind of benefits did they receive with the tool? Can you talk about that? Do you know?
Igor Dejanović: Well, I know for what I can hear in the side channels and in the news and see what’s happening with the company. They promoted the tool like quickly building and describing the 80% of the system. So they built, for example, they’d describe a data layer, and the APIs and they could build CRUD/REST APIs for the system. It was very pragmatic approach. They built the team and they succeeded in… They got acquired later by Silicon Valley company and they continue to work in that company on the topic, on this area of building these DSLs and code generators.
Federico: It’s nice success story about marketing DSLs because I think that’s important because I think we’re not doing in general good job at marketing DSLs, so maybe we could learn from these guys.
Igor Dejanović: Yeah. Definitely. I think we take it for granted that DSLs is the way to go. We all know that. But we need to persuade somebody that this is the area worth investing in. It’s hard.
Federico: Now I wanted to discuss with you about the tool you have built. I can see from the name that there is some relation with Xtext. Can you tell us a bit more about textX and explain also the origin of the name?
Igor Dejanović: Yeah. I started back in 2006 to play with Xtext. I was really impressed by the idea that you can actually with one single grammar specification, you can describe not only the syntax of your textual language but also the meta model. The idea was great but it was always love-hate relationship because the Xtext was built on the Eclipse ecosystem and it was always a bit heavyweight for me. When you change your grammar you have to restart, or start another instance of Eclipse to see what you have done. So I was always looking for some similar but simple solution, something that I could play with. Most of the time you need some small language or you need something for teaching purposes. I looked around and there was nothing like Xtext at least at the time. I couldn’t see anything. And then in 2008 I started learning and playing with Python. It was a great experience, really, and I figured out it would be great to have something like Xtext but for Python. Something lighter, more dynamic. Something like that. For Python there were some great parsers around but nothing really similar to Xtext.
Igor Dejanović: So I got an idea at the time, that I should build something but I never had enough time to put aside to try something like that, and I didn’t have at that time enough knowledge about all the parsing technology. So I start first learning parsing. First project I built was Arpeggio parser. It’s a PEG parser for Python. It got quite popular. Then later, I think it was 2014, I was already doing this DSL course, I decided, okay, now it’s time. I should sit down and try to build this tool. Initially the idea was that it will be Xtext implemented in Python. So I think about PyXtext or something like that but I was really allergic to Py something in naming, so I put working title textX. It will be working title for this project, but I never planned or realized it will take off, become popular later.
Sergej: What do people use textX for, do you know? Do you hear from the users?
Igor Dejanović: Yeah. TextX is used for developing small languages, DSLs but also for parsing. So if you need to parse something, it’s very easy to specify the parsing in textX, because with textX you specify the syntax with very compact and elegant language and then you don’t have provide usual semantic actions to build the output. And you don’t get the plain tree, you already get the model of your textual representation, what you’re parsing. It is already resolved, so you get actually a graph of Python objects that are dynamically created out of this grammar specification. Due to Python dynamic nature I was able to generate Python classes on the fly, and when you’re parsing your program or model, you actually get instances of those dynamically created classes. It’s a very overhead you have. You just write grammar and that’s it then. You can parse something and get the in-memory representation of this nice graph. You can traverse or do something with that.
Sergej: And do you know what your users use it for? I mean the actual subject areas or the actual DSLs they parse [with it]?
Igor Dejanović: I know what it’s being used on the projects I’m directly involved, or sometimes I know for what it’s being used by some context I get on GitHub, or by email. I know it’s used for developing DSL in the scientific communities. For example, in physics or chemistry they’re using for some languages.
Sergej: Anything in the data analysis community maybe? Because I think Python is used quite a lot in machine learning data analysis and this kind of-
Igor Dejanović: Yeah. I believe it is used but I don’t have any specific information about which company it is. But yeah. TextX could be a nice way to parse some input data that are textual.
Federico: That’s a sad reality of running an open source project: when people are happy with it they don’t write back to you telling you what they’re using it for.
Igor Dejanović: Yeah. Definitely. If they have no problem, they don’t write.
Federico: But if there is a bug, then-
Igor Dejanović: You just get that kind of negative feedback, but that’s okay. I like to get bug reports because it’s make project stronger.
Federico: Now there is also a nice feature on GitHub that tell you, for at least some languages, where your project is used. I don’t think it’s yet supported for Python but for other languages there is, so maybe in the near future we will be able to figure out which repository are using textX and that could help.
Igor Dejanović: I think it is supported. Yeah. I have a list of projects there. Yeah.
Sergej: And what do you use Xtext for yourself?
Igor Dejanović: Besides teaching, I use it for this language engineering consulting I provide.
Sergej: Mm-hmm (affirmative). That’s interesting. Could you talk more about that?
Igor Dejanović: Yes. I have several clients I work for where I use these libraries I developed. Probably the… I have two clients with whom I have a longer relations so I already got their permission to talk about that, so I can say something about that.
Sergej: What can you tell us?
Igor Dejanović: The first client is a company called Typhoon HIL. It is operating in the field of ultra-high fidelity controller Hardware in the Loop, simulation for power electronics, microgrids and distribution networks. It’s a full mouth of words so let’s explain a bit. They’re operating in the field of power systems, right, and when you’re working in field of power systems you have for example, some components in system. For example, imagine some wind turbine or some solar invertor or something like that. All those subsystems, they need a control. They need a device called a controller that senses some data or some state from that subsystem and then fire up control signals to bring that system to some desired state.
Igor Dejanović: When you are developing that controller you need some way to test that controller. The old way how people test that, was to actually connect the controller to the real system. So either in the laboratory they build the real system, so real turbine and they connect the controller, and then they drive that turbine through various states and see how it behaves. And you can imagine how expensive that test. It’s very expensive. You can burn the equipment and cause big losses. You’re at risk to lose someone’s life if things go really bad.
Igor Dejanović: And with this approach they’re developing, it’s called controller HIL in the loop, you actually connect the controller to a device that sits on your table. That device is able to simulate the real system in real time. Your controller is fooled into thinking that it talks to the real system while it talking to the simulation. Then you can run bunch of tests cheaply. You can repeat it. You can do continuous integration and you can test even the states that would be dangerous in real life. So how the system will behave if something goes wrong, some malfunction of the system, and stuff like that.
Sergej: So this controller or, not the controller, device pretends that it’s basically a wind turbine, or-
Igor Dejanović: Exactly.
Sergej: Solar panel or something like that.
Igor Dejanović: Exactly. You do the modeling. You make the model of the real physical system and then you compile it and upload it to this device and then you run the simulation and you just test your controller and see how it control the simulation. So it’s really, really interesting. Interesting domain to work with and the company is really great. It’s full of smart engineers. I learnt a lot while working there. I started to work for Typhoon in 2013 so it’s seven years now. I was hired together with my colleague. We at the beginning, of course, we were not hired to do some model-driven or DSL stuff. We were hired to do improvement in the architecture and the development process. But of course it was very obvious to us at the very beginning that we could employ model-driven techniques to actually boost productivity of their teams.
Federico: And the moment that you suggested using model-driven you… They were already trusting you, so I think was… That helped convincing them adopting this techniques.
Igor Dejanović: Yes. We realized that they’re producing a lot of low level C code manually while describing these components in the system. While they already have some form of description with components in some form of a model. It was a model built by some form of internal DSL. We realized, okay, if we extend this model a little bit with some additional information we could generate that C code, completely. Because that was mostly a boilerplate code with a lot of repetition and staff like that. We suggested that approach. It was very interesting to me in the field of power system all of them use compilers. They’re describing a hardware with the VHDL language and they compile the hardware specification and compile C code to machine code and stuff like that. They were pretty reluctant to idea that they can generate C code from some high-level specification.
Federico: And why?
Igor Dejanović: I’m not sure. Maybe they had some bad experience in the past with this code generator approach.
Sergej: I could imagine that generating something low level seems simpler than generating the high level code.
Igor Dejanović: Maybe. I’m not sure. But actually generating a C code or some code from third generation languages always seemed easier to me than generating some lower level code. Not sure, but we were lucky enough to… Their CTO is a very smart guy and excellent engineer so he realized the potential of this approach and he gave us the green light to implement the first proof of concept implementation and it goes really well. After that, I think, we never had any need to explain why it’s a good approach. So Typhoon HIL is now using model-driven development approaches.
Sergej: So in a way you say they were using it even before, right? They had some sort of model. They just didn’t go far enough.
Igor Dejanović: Yeah. They didn’t use it to its full potential at that time.
Federico: Okay. So this is a recurring theme that people that are already use some form of modeling they can be good adopters of DSLs, I mean physically attach a code generator to what they have. Just to be sure I understand. Your users, the user of your DSL are actually engineers but they are electrical engineers, not software engineers. Is that correct?
Igor Dejanović: Yeah. Exactly. They’re electrical engineers. They model the components in electrical systems and they use this DSL to describe. Initially it was internal DSL but now it’s an external DSL based on textX.
Federico: Okay. So the language is a textual, right?
Igor Dejanović: Yes. It is textual but we have graphical modeling tools about that textual representation.
Sergej: That’s interesting to me because I think electrical engineers, in my maybe stereotypical imagination, they probably prefer to look at circuit diagrams or data flow diagrams or any kind of diagrams. What was their experience with text languages?
Igor Dejanović: For this scheme description, when they’re describing schematics, they are using graphical editing. They use graphical editing. Even when I got working for them they had that graphical editor, but underlying representation, storage format was some kind of XML which was quite unreadable. Since we had a need to describe all sorts of things, not just the schematics, but single component description. Each component is described by some properties and stuff like that, so we needed some more languages to develop. Developing graphical editor is not cheap. The maintenance of this persistence layer had a lot of overhead. You had to read the XML and instantiate the domain objects and then you had this graphical editor above these domain objects.
Igor Dejanović: I think it was 2014 or 2015. The textX was at stable version at the time and we started to think about re-engineering this whole approach. I suggested to try textX for this description of the schematics and of the components. We organized the series of meetings to discuss about that and to think about that language. We used that to clean up the language and to introduce some new concepts, but it was very pleasant experience because we do that through the textual syntax. We were able to just open editor and say okay, we will need this here and that here, and it would be nice to be like this. We had a feedback from these power electric guys how they would like to see that. At the end we end up with a nice readable textual syntax and the textX would handle all this instantiation of objects, Python objects, and this mapping which was really error prone and hard to maintain.
Igor Dejanović: What this bring us on the long run is that for free we got this possibility to edit our schematics with plain textual editors, to use Git for version control and distributed development. And what we do know is, when we start to build a new tool, we start by describing the language, then we clean up the concepts, so we came up to the common understanding in what the domain concepts are and how the language looks like, and we can iterate very quickly. We can build that very quickly and then if we need we can build some more complex tooling above that, like some graphical editors or some simulators or stuff like that.
Sergej: So it means that some editors still are only text based and for some cases you build you kind of have both, right. You have a text based representation and you have graphical editor on top of that can edit this text based representation, right?
Igor Dejanović: Exactly. Exactly. So we can quickly build the tool chain and then if needed we can later build this complex, more expensive additions like graphical editors and simulators and stuff like that. But we can get quick feedback from electrical engineers about the tool and language itself, and when it is all cleaned up we then can build this above that.
Federico: I wanted to ask. You’ve been working with them for seven years so it’s clear that they’re happy with the results that you provide to them. Can you tell us a short summary of what is the business value they got out of adopting DSLs?
Igor Dejanović: The business value is, first, we can iterate much faster, so we can get feedback from the user of this languages much faster, so we can build cheaper and faster. They’re actually in process of releasing these languages to the open source. It’s interesting idea to release these description, these languages, textual languages to the open source and then some third party companies or persons can builds some tooling for their tool chains.
Federico: So we could say that they got agility out of using DSLs because they are able to move much faster. That’s nice.
Sergej: And maybe if we go one level further, what does this agility give them? Why do they need it?
Igor Dejanović: It’s always better… Today markets, you have to move fast. So this agility gives you a way to move faster and to get feedback much earlier in the process. I already mentioned what we got for free and it’s very important because when you’re building some language, if it’s based on some graph based representation, you need to provide, if you want to enable user to do distributed development and to have version control, you have to provide that, to have some way of providing those features. With text based syntax you get that for free by using just a Git, and GitHub, GitLab and tools like that for distributed development.
Sergej: Would it be correct to say that it basically helps the company save costs by reducing errors and the amount of rework they have to do because of some misunderstanding, or something like that?
Igor Dejanović: I think it does because if you have a shorter developing time and quicker feedback then you’ll have a lot less waste while you’re developing your product.
Igor Dejanović: So you’re cutting waste. Yeah.
Federico: You say that there were two clients that you were allowed to talk about with us, so I think it would be interesting to hear about the other client in the remaining time.
Igor Dejanović: The other client, I started working for them in 2017, so it’s now three years. It’s a non-profit organization called Open Law Library, based in the U.S. Area they’re working in is law. Their mission is to make laws available to all citizens. When I started working for them it was very strange to hear that in the U.S., it’s probably the same in most other countries, citizens, although they pay taxes and everything, they don’t have free access to laws. So if they want to know what applies to them when they are doing something they have to pay for it. The reason for that is relatively simple.
Igor Dejanović: In process of creating laws, you have drafting law, so you have the lawyers make some proposal. When you draft the law, that law passes through some kind of body that votes on that, and if it’s accepted it should be applied to the general document. It is called the Code, so it’s a sublimation of all the laws that are passed till this point in time. And the law they’re passing is like kind of diff or patch to this code. So it states like something, section X, Y that is changed to be read like this and there is some change to that section. It’s basically like a patch. Process of applying this patch to the code is called codification. And this process is manual and it’s very labor intensive.
Igor Dejanović: The jurisdiction usually don’t have enough resources to do that and what they do is they outsource this job to the publishing companies. Publishing companies in return get a right to sell the code. The jurisdictions don’t provide this code online because the right to do that, to sell that has the publishing company. The whole process is very long usually when the law has passed the voting it takes like six or maybe more months to be applied to the code. The idea of Open Law Library is to make this process so automatic that the jurisdiction, the lawyer working in the jurisdiction can do that alone, the whole codification process, and that codification is done nearly in real time. So when the law pass the council it gets supplied to the code.
Federico: I can understand the steps that brought us to this situation but the result is bit dystopian. I hear about a similar company in Italy doing something similar. What they were also offering was like the possibility to see how a certain law looked like at the certain point in time. Like you had a slider you could say, since that day they changed it like that. Does also Open Law offers something similar?
Igor Dejanović: Yeah. Exactly. They offer technology that do exactly the same. If you have the series of patches that change the code, you have all the information to recreate the code at some exact point in time and you can also for example get diff between two versions. So you can say okay, give me the difference between this date and this date, and you’ll have a nice a GitHub like representation with greens and reds for stuff that got removed and stuff like that. So you can see the difference in the law between two points in time. It is really, really great. The whole history is kept… the whole history of changes is kept in the system. You can do all sorts of analyses on top of that.
Federico: Nice. So modeling applied to law.
Igor Dejanović: Yeah.
Sergej: How does it actually apply? What is the part that language engineering is playing there?
Igor Dejanović: The most visible part of the story is, if you think about the process of drafting, lawyers are usually using some office tool, mostly Microsoft Office Word, they are writing their law. They’re writing sections and each section need some kind of instruction. What needs to be changed and stuff like that. That’s their DSL. That DSL has a structure, so it has a syntax. It has a meaning, so it has a semantics. You can apply all language engineering, tools and techniques on top of this language.
Sergej: So you mean all these lawyer like expressions or this kind of formulaic things like, hereby, hereto, notwithstanding and so on. You mean these forms of DSL, right?
Igor Dejanović: Exactly. You have a rule how those paragraphs in that document can be laid out. You can check the syntax of the document. You can see for example, what Open Law Library provides is a tool called Draft. It’s actually a plugin for Word. While the lawyer is typing the draft that tool will continually check the syntax and semantics, so it will report errors. Either styling errors or structural errors or semantics errors, some stuff like that, and it will help. If you think about it, it is like a IDE for lawyer.
Sergej: Does it do like auto completion when you type two letters and it gives you a full paragraph out of it?
Igor Dejanović: Yeah. Exactly. It has some sort of auto completion but, not that fine grain but more coarse grained. For example if you reference some paragraph from the code, it can automatically insert that part of the code in the document. So it’s very, very easy for the lawyer to make a draft which is completely correct, syntactically and semantically correct. Right?
Igor Dejanović: Because the tool will help them. It is like you have a compiler that all the time checks for errors and reports them, until everything is clean.
Sergej: This is a bit similar in spirit to what the Dutch Tax Agency does with MPS where they have this project called ALEF, Automated Law Execution Factory, and they created a domain specific language in MPS to basically describe their tax laws, and I think, I’m not exactly sure of the state but I think currently already some part of it runs in production and already calculates the taxes for the entire country of Netherlands.
Igor Dejanović: Wow! That’s great.
Sergej: So not only do they write these laws and obviously check for syntax and semantics but they actually can execute them like programs.
Igor Dejanović: So what is the learning curve of MPS, I’m just interesting to compare this approach when you have some tool they’re already using and try to integrate into that and giving them new tool to do some specification.
Sergej: Yeah I’m not sure about that, I guess we’ll have to do a podcast episode with them at some point. I just know it in general with MPS it’s being said that it doesn’t have a learning curve but learning wall. So at some point there is a big wall that you have to jump over. It’s a bit unfortunate but it’s the reality. Anyway, it just reminded me a bit of that project so I wanted to mention it.
Federico: I really like the idea of having something that integrate with Word because you basically you build the power of language engineering to the tools that they are already familiar with, so it seems very convenient just to adopt them. Right?
Sergej: Yes. You kind of meet the users where they are.
Igor Dejanović: Exactly. So they don’t have to learn much. They have tool that helps them, so they immediately see the benefits. They continue working like they are before but they get help, like assistant that help them, okay you made an error here, correct this, correct that. If you think about it we as software engineers are similar, we all have some editor or some environment we like. We are not that easy in changing that. But if someone offers us a plugin for our editor, we will be more than happy to use it.
Federico: Yeah. That’s a good point of view. It’s like, I don’t know, I’m using IntelliJ and someone give me a plugin for IntelliJ instead of asking me to switch to Eclipse, probably will have a better chance to convince me.
Igor Dejanović: Yeah. There are all kind of flame wars around internet. Is it better Vim or Emacs or Eclipse or some other… We are no different than lawyers or some other guys from some other domains.
Federico: But I really like the two cases you presented because it seems that these people were already using something that was formal at some point. You said the first company, Typhoon HIL, was already using a DSL and the lawyers, by the way you described them, were basically human compilers for a language that was very, very formal. So you just gave them powerful tools to do their job better. But the formalization was already there.
Igor Dejanović: Well. Not quite, because usually they have a language but it is not formalized.
Igor Dejanović: The language is most of the time very loosely defined. With the process of making it more formalized you are actually cleaning or building a better understanding of the language itself. So I think that is another benefit of applying DSL, because when you have some loosely defined language then it may be interpreted differently by different people. But if you formalize it, make a compiler for it, make a formalized semantics for it then you build a common understanding for that language.
Sergej: Yeah. It kind of becomes the ubiquitous language that the domain driven design people talk about, I think.
Igor Dejanović: Exactly. Yeah.
Federico: I think everything is very interesting. I would like to go on for another hour but we are running out of time, so I wanted to ask, Igor, if there is something that we didn’t have the chance to talk about and you want to add?
Igor Dejanović: Maybe two things, just quick. For example, one interesting thing about textX in particular is some work done by Daniel. It’s my ex student who continued to work in the area of textX. It is Language Server Protocol support and integration with Visual Studio Code. With this stuff the textX library will became a language workbench in its own, but will still remain the simplicity of a plain small library. You can use just library or you can use the whole ecosystem and toolchains around, too.
Sergej: Right. This seems like a nice modular and useful addition.
Igor Dejanović: Yeah. I really believe that DSL approach is a way to go but I think still we have a lot of work to do to make it happen. Probably more teaching, more books on the topics, raising awareness of the approach, and we need to constantly improve tools we’re building.
Federico: And also more podcasts.
Sergej: I think Federico and I would say we need more marketing.
Igor Dejanović: More marketing. Yeah. Definitely. I think we need somehow to avoid that perceived lock-in that are usually connected to DSL tooling. We need to find some way around it.
Federico: Yeah. We have many problems to work on as a community but I think it was inspiring to see what you’re doing, both as a professor, teaching a lot of young developers how to use DSLs, what you’re doing as a consultant and also what you’re doing as an open source maintainer. Thank you for your contribution to this community.
Igor Dejanović: Thanks You. I’m really grateful to you for starting this language engineering community. It’s really great. I think it will be beneficial to the whole idea of DSLs, language engineering in general. A lot of great people are already there so it’s really great.
Federico: Maybe we should tell our listeners that they can join the waiting list by going to strumenta.community. If they’re interested in learning more they can read more there. Hopefully we’ll have new more members joining.
Sergej: And Igor, where can people go to learn more about your work?
Igor Dejanović: I’m on GitHub. Most of my work is in the open. Also on Twitter, although I don’t tweet that much. But yeah. That’s it, GitHub is probably the best place to go. And I have some blog but I didn’t blog for quite some time.
Sergej: Okay. So how does one find you on GitHub?
Igor Dejanović: It’s github.com/igordejanovic. So my name, first name, last name combined.
Sergej: Okay. Thank you very much.
Igor Dejanović: Thank You.
Federico: Thank you.
Igor Dejanović: It was really my pleasure.
Sergej: Thank you very much for joining us today.
Igor Dejanović: Bye.
Sergej: Good Bye.
Sergej: Thank you for listening to this episode of Beyond Parsing. We are your hosts Federico and Sergej. Two language engineering consultants.
Federico: If you want to learn more about domain specific languages and language engineering, visit beyondparsing.com.