Transpiling for the Future: Innovative Solutions to Language Translation and Software Development Adaptability

‍

Frederico Tomassetti does something very unique, he creates languages businesses use to communicate. He uses software to make this happen through his company Strumenta. How? Well listen to him yourself. I’m very excited to have him on!

Host:
Hello Fred, how are you doing?

Frederico Tomassetti:
Doing well, and you?

Host:
Very, very well! Very excited to have you on the podcast.

Frederico Tomassetti:
Very excited to be here. Thank you for the invitation.

Host:
Absolutely! Okay, first, I'd like you to just introduce yourself a little bit, talk about your company, and where you're from, and things of that nature. Just let people know about you a little bit.

Frederico Tomassetti:
Sure, I'm Frederico. I'm Italian, and I've been living in a few countries, well, all around Europe. I've been living in Germany, in Ireland, and France, and now I'm back to Italy. I started my business while I was in France because I was coming from Ireland, where there are a lot of job opportunities for people in our line of work. I moved to France, where the job market wasn’t as exciting as in Dublin, and also, to be honest, I didn’t speak much French at the time. So when I moved to France, I started my own business. Originally, it was just me, and then things went well. I moved back to Italy, started a small company, and now we have Strument, which is this language engineering consulting company. So we specialize in this niche area of software engineering.

Host:
That's a very interesting niche indeed. Could you talk about why you moved around a lot? Was it for school? Was it the nomadic lifestyle that a lot of people are very interested in when they start entering into software?

Frederico Tomassetti:
Originally, it was for my studies. I moved to Germany two times: once for my master’s for a period during my master’s, and another time for a period during my PhD. Then I moved to Ireland because there were a lot of opportunities. A lot of American companies have an office in Dublin, so I worked for Trip Advisor and then for Groupon while I was there. It was also an opportunity for me to improve my English. Then I moved to France. Well, that's more difficult to understand why I did that... maybe the food, maybe it was closer to home, and also it has a fascinating culture, but it was definitely not work-related, let’s say.

Host:
Fair enough! That's a very interesting narrative. And then you said you started the company in France?

Frederico Tomassetti:
Yes.

Host:
What gave you the impetus to even think about this? Because I think this is a very unique way to contribute to the market in the way you're doing it.

Frederico Tomassetti:
To be fully honest, when I started, I wasn't planning to focus on language engineering. It's something I studied during my PhD, but I wasn’t sure there was a market for it. So I just thought, okay, I’ll be more of a generalist. Maybe I will write web applications, given I had experience working in large companies on web applications. But then I realized there was a lot of competition and clients in general, and so, I wasn’t able to find those clients who were interested in quality when it came to generalist work. On the other hand, people started contacting me for these more specialized skills that I had because they were listed in my LinkedIn profile. To my surprise, people asked me to work on that kind of stuff, and I enjoyed the work more, it was paid better, and it was easier for me to get.

Host:
So you just kept going?

Frederico Tomassetti:
Yes, I cannot say I was much of a businessman. I didn’t plan anything, just things happened. That might be the best way to start, to fall into an opportunity.

Host:
So, why not? For the people who don't know, what exactly does it mean to do language engineering? Just to clarify what it is that you're doing.

Frederico Tomassetti:
Yeah, we are specializing in these technical skills that are related to building tools around languages. As a developer, you may be familiar with a lot of programming languages like Java, Python, C, and so on, and you need a lot of tools to work with these languages in your daily life as a developer. So, for example, you need an editor, an editor that has some intelligence, an editor that understands, for example, the syntax of your language, that gives you suggestions on what you can insert, that points out errors in your code. So these kinds of tools are tools that you can build if you know how to process languages.

In this context, transpiling for cross-platform development is crucial, allowing developers to convert code from one language to another, enhancing compatibility and functionality across various platforms. For example, you may need to create a parser, or build editors and even compilers to execute the code. Then there are other tools that you may be less familiar with that require very similar skills. For example, writing transpilers.

So sometimes you have code written in one language for any sort of reason, maybe for historical reasons, and now you would like to have the same code in another language. Transpiling for cross-platform development becomes especially valuable in cases where legacy systems exist across decades in obsolete languages, and it’s very hard to find developers, or even hardware, that can support them. So maybe you want to translate this old code to some new programming language so you can run it on newer hardware. And transpilers serve that purpose.

‍

Host:
Okay, so tools that help you be a better editor and play with the code that has a little bit of intelligence, compilers, transpilers—that’s the domain that your company deals with in terms of providing value?

Frederico Tomassetti:
Exactly.

Host:
So I think the next part is, what kind of companies have you been working with so far? Because I feel this takes quite a bit of understanding to see the value and go and search for someone with your skill sets and with your service provisioning.

Frederico Tomassetti:
Yes, and this is not easy to answer because we are not doing ourselves a favor by not specializing in serving a particular client but instead focusing on a technical skill. This technical skill has the advantage of software development adaptability, allowing it to serve different purposes. I think there are two main purposes we can use our skills for. The first one is legacy modernization. This often involves transpilation techniques for cross-platform development, for instance, in situations where companies have code written in COBOL, RPG, SAS, or PL1—older languages that may no longer be viable on modern platforms.

It’s common for valuable systems written in these old languages to need modernization. Over time, systems can become difficult to maintain as experts retire, hardware becomes obsolete, and libraries are no longer available. Modern languages improve on older ones, enhancing productivity and making the transition easier. Sometimes we work directly with companies that own this old code and want help with language translation—either by converting it to a new language or by writing an interpreter or compiler that allows the code to run on current machines. Domain-specific languages also play a key role in these migrations, providing tailored solutions that can automate and streamline tasks like migrating from SAS to Python. This is where our skill set comes in, helping to build tools that enhance the efficiency of these migrations.

Okay, and this is the first kind of client. Then we have the second kind of client, and these are companies that want us to design a language for them, and that typically want to do that to create a language that is domain-specific and is specifically tailored for their needs. The most common scenario is for companies that are employing some kind of expert, for example, medical expert, a tax expert, some sort of engineer, and they build some software that requires these expertise. And so, they want a language so that this expert can directly use this language to capture their expertise, because without this language, they have to do things in a traditional way.

That means having the experts sit down with analysts and explain what they need, the analyst writing requirements, then showing these requirements to developers that try to implement these things, and then things don’t work. So, once developers have built the thing, they are able to show it to the expert, and the expert can understand that this was not what they needed, and it’s a process that is difficult for various reasons.

First of all, for some kinds of experts, it’s very difficult to think about all the corner cases, to imagine all the scenarios that they need to support, to formalize the way they think about a problem. So, it’s very hard to collect requirements from them, and also, it’s difficult for developers to understand these requirements because these experts are specialists in some other areas that developers are not familiar with. So sometimes, maybe you work with doctors, and they give you requirements, and then maybe, maybe doing a stupid example, but maybe you wonder, “Okay, but the doctor didn’t tell me what happens if I don’t know the systolic pressure is higher than the diastolic?”

And then you ask the doctor, and the doctor looks at you and says, “No, but that is physically impossible, so why are you asking me?” Not sure if I didn’t invert the true kind of pressure, but I think you can understand what I mean.

Host: 

Absolutely. Yeah, sometimes I have a very hard time explaining things in detail because for them, those are obvious.

Frederico Tomassetti: 

Yeah, and so you have a lot of effort for the organization to basically handle the communication between the two parts, and then you have to coordinate every change. Maybe it needs to be revised by the specialist, and they need to provide change requests, and developers need to understand them and implement them, and it can take a long time and be very painful and expensive.

Host: 

Okay, so I want to dive deeper into the old-to-new for just a short while, and then we’ll talk about the DSLs for the specialists, which I think is very interesting on a personal level. So, how do you work with people who are trying to transfer their old systems to a new system? And by system, I mean a platform, or they want to transfer the code and have a transpiler do it. Do you usually work with them to verify things, or do they hand this over to you? What is basically the lifecycle of your engagement with your clients in terms of making that feasible?

Frederico Tomassetti: 

That’s a good question because these kinds of projects are not simple, and they require a lot of different expertise. And one point to consider is that while we are experts in building tools for languages. Each language comes with its own platform, its own runtime, and we cannot be necessarily experts with those. For example, if you need to migrate some old code that was written in RPG, a language created in 1959—so not exactly the most modern of languages—they typically run on a platform from IBM that used to be called AS400, now renamed IBMi. It's a platform with its own specificities, and I don't know much of the libraries that are available there or how these architectures work.

So typically, we work with some other companies that could be the company that owns the software. These companies typically have people who know the architecture very well, or with companies that perform the migration for other companies—those that provide the services. In a way, these companies want to work with us so that we can build the tool, and then they use the tool, combining it with their service. So, they use the tool to maybe do the part of migration that can be automatized. That could be, I don't know, depending on the case, between 80 and 95% of the code. Then, they fix manually the parts that cannot be automatically translated.

And in this automatic translation, there is always... you always need to find a compromise to make the capability of the old language fit into the capability of the new language. Otherwise, you will need to emulate completely the original language. For example, on some platforms, they may have support for certain kinds of numbers with certain ranges, while you may want to translate this language to Java, where you can have primitives that support different ranges. You could create new types to represent languages with the same ranges you had on the original platform, but if you do that, you will have terrible performance. So, you want instead to use the primitive available on Java, but then you need to consider that there will be cases in which the difference in range could be a problem—could lead to overflow—and so you need to maybe identify those cases and treat them differently. There are always problems like this, so to cover the translation completely automatically could be very difficult.

So normally, in this case, there is some part of manual work that still needs to be done. On our end, we like to work with a fixed price, so we try to assess the problem and provide a fixed price to build an initial version of the transpiler and deliver it to the client. Then, typically, the client starts using it—the client themselves—or if we work with a company providing services, they use it on behalf of their clients. Then there are typically iterations as we find more corner cases. Also, because in reality, in this line of work, we don't start by reading the specification of the language and implementing everything from start to finish. These languages, that evolve across many years, end up being extremely complex, and typically, each client is using a certain subset of the language. If we were trying to cover the whole language, the transpiler would be very expensive, and in many cases, it doesn't make sense. So, we are always driven by the actual examples that we encounter, and as we encounter more examples, we improve incrementally this transpiler.

Host: 

That's very interesting. So it can be 100%, but it can give you more than 50%. Ideally, 80%, and 10 to 20% ends up being something that you have to grow into over time, and that's a client working with you to make that happen as you work with clients that work with clients or directly with clients who need the transpiler?

Frederico Tomassetti:
Yes, exactly. I think that this approach finds the best compromise with keeping the cost of the transpiler reasonable because maybe it costs a certain amount to automatically translate 80%. If you want us to build a transpiler to handle the remaining 20%, maybe it will cost you 10 times more. Yeah, you have to be pragmatic.

Host:
And that way... and then, but which also means you have to build per client, per their subset, so you can't keep... and keep growing a company-based variation because that’s just not cost-effective. Anyway, yes, that's fair. That's very... okay, that's very fair.

Host:
So then, now we're going to move on to what I think is a very interesting part, primarily because of how it interacts with the business side and what it does to produce the complexity there. And I think that's something that's very interesting. Let's talk a little bit about creating DSLs, which is the sort of second kind of client, and what it means to really have languages for non-technical specialists and seeing how that affects the organization.

Frederico Tomassetti:
Yes, I think it is something that has effects, of course, on the technical level adopting a DSL, but I think it's interesting also because it affects how an organization works and how the different kinds of professionals interact. In a way, in a typical organization, when you build software, you have software developers that are in charge, right? They are the ones that actually build the artifacts that you sell or you use to provide value. And in a way, all the other professionals have the purpose of serving developers and providing what they need to do the work.

Frederico Tomassetti:
As we were saying before, in many scenarios, we see that there are experts, and those experts do not work directly with developers but they work with analysts. Analysts are the people that are very patient and able to sit with these experts and help them reason about the different cases they need to cover. They put order in their way of thinking and are able to ask the right questions and solicit the answers until they have a sufficiently clear picture. But I think that what they’re trying to do is extremely difficult because, in a way, they are trying to capture the whole complexity of the requirements and embed them in large work documents, but they have no way to...

Frederico Tomassetti:
We, as developers, we have the habit that we look at requirements. Maybe we try to, maybe sometimes we spot immediately problems, but more frequently, we try to implement these, and then we realize it doesn’t work because at the moment that we try to write code, we realize there is a conceptual problem. Or sometimes we are able to write the code, but then we realize that when it runs, it provides results different from what we expected. And sometimes the problem is in their requirements, and I think that we, as developers, when this happens, we feel that we are very smart because we found out the problems and the people that wrote the requirements are very stupid because they didn’t notice the problem. But if we try to write our programs on paper and we try to write 300 pages of a program on paper and then try to type that on a compiler or in an editor, I’m pretty sure that we make some effort, right?

Host:
Yeah, absolutely. And I think that experts and analysts basically don't have the tools to verify they are correct, so their work is to grow into over time and that's a client working with you to make that happen as you work with clients that work with clients or directly with clients who need the transpiler. Yes, exactly. I think that this approach finds the best compromise with keeping the cost of the transpiler is reasonable because maybe it costs a certain amount to automatically translate 80% if you want us to build a transpiler to handle the remaining 20% maybe it will cost you 10 times more, yeah, to be pragmatic, and yeah, and that way. But which also means you have to build per client, per their subset, so you can't keep  and keep growing a company based on variation because that it's just not cost-effective anyway.

Host: 

Yes, that's fair. That's very okay. That's very fair. So, so then now we're going to move on to what I think is a very interesting part, primarily because of how it interacts with the business side and what it does to produce the complexity there. And I think that's something that's very interesting. Let's talk a little bit about creating DSLs, which is the sort of second kind of client, and what it means to really have languages for non-technical specialists and seeing how that affects the organization.

Frederico Tomassetti: 

Yes, I think it is something that has effects, of course, on the technical level adopting a DSL, but I think it's interesting also because it affects how an organization works and how the different kinds of professionals interact in a way. In a typical organization, when you build software, you have software developers that are in charge, right? They are the ones that actually build the artifacts that you sell or you use to provide value.

Host: 

And in a way, all the other professionals have the purpose of serving developers and providing what they need to do the work. And as we were saying before, in many scenarios we see that there are experts and those experts do not work directly with developers, but they work with analysts. And analysts are the people that are very patient and able to sit with these experts and help them reason about the different cases they need to cover. They put order in their way of thinking, and they are able to ask the right questions and solicit the answers until they have a sufficiently clear picture.

Frederico Tomassetti: 

But I think that what they're trying to do is extremely difficult because in a way, they are trying to capture the whole complexity of the requirements and embed them in large work documents, but they have no way to verify if they are correct.

Host: 

We, as developers, we have the habit that we look at requirements. Maybe we try to, maybe sometimes we spot immediately problems, but more frequently, we try to implement these, and then we realize it doesn't work because at the moment that we try to write code, we realize there is a conceptual problem or sometimes we are able to write the code, but then we realize that when it runs, it provides results different from what we expected. And sometimes the problem is in their requirements.

Frederico Tomassetti: 

And I think that we, as developers, when this happens, we feel that we are very smart because we found out the problems and the people that wrote the requirements are very stupid because they didn't notice the problem. But if we've tried to write our programs on paper, and if we try to write 300 pages of a program on paper and then try to type that on a compiler or in an editor, I'm pretty sure that we'd make some effort, right?

Host: 

Yeah, absolutely. And I think that experts and analysts basically not having the tools to verify they are correct, so their work is extremely more difficult because of this. We are the only ones that have the tools to verify that something is coherent, that something works, and in a way, we feel smarter, and we are the only ones that have access to this tool, so we are, in a way, the ones with the power of doing these checks. So I think the way it also affects how we think about these experts, because we are always the ones finding out the problems.

Frederico Tomassetti: 

On the other hand, these experts are the ones answering our questions and wondering why we don't understand what they're trying to explain. So I think that this kind of relation is not ideal for neither part involved, and also, there is a lot of cost in clarifying these questions and coordinating. A lot of cost in communication, and it of course affects the cost of building this kind of software. We've seen that in certain domains, maybe there are domains that are very highly regulated, like medical software. This process is extremely complex and frustrating and maybe can take you even 18 months to deliver the first version of an application, and 18 months in which you have experts and analysts and developers and testers also, and this is a whole other story.

Host:

 And so of course, this is extremely complex, also because I think that the cost of correcting an error grows exponentially with the times that it takes you to catch this error. If you do an error in your editor as you type it, your editor tells you, "Okay, no, you cannot do this because this variable has the wrong type, because you don't have this method, because this variable is not existing or is private that you cannot refer to it in this place." You type it, you see the error, you cancel, you delete, and type something else, and you fixed this error in 3 seconds. And so basically, it costs you nothing.

Frederico Tomassetti: 

But if instead, an expert makes an error in the requirements, and then you have the analyst spending hours writing down all the details about this requirement, and the developer spending days trying to implement it until they realize that this is a conceptual problem, and then they go back to the doctor, maybe organize a meeting with the doctor, and then you need to explain to the doctor why this doesn't work. And this is not always obvious. And then you finally have a correction for the requirements and you can go back and implement it correctly. Now, this error, instead of taking 3 seconds to be fixed, it's taken you maybe weeks of work, and now it has cost you in the tens of thousands of dollars, depending on how your organization works.

Host: 

So I think that if we can reduce the moment, the time that it takes to identify errors, we reduce a lot the cost of these errors.

Frederico Tomassetti: 

Mhmm. And this is where the DSLs come in, in the sense that they provide that formalization of the constraints that, now since it is debuggable, you can really save time because you can say, "Hey, this part of what you're trying to express does not fit the model for this specialization or this organization."

Host: 

Yes, this is exactly the point, that with this higher-level language specific for a well-defined domain, that could be, for example, writing, I don't know, something related to insurance, writing the quotation, or taxes or something like that.

Frederico Tomassetti:

Yeah, or taxes. Then in these cases, you have this language that the expert alone or the expert with the analyst can use to write some rules. As they write, the editor will point out errors, and if the editor is not able to identify errors, they can still try to run a simulation or actually, you know, play with the result immediately so they can see that it works differently than what they expected. So they can go back and fix it very quickly. And by the way, given these are languages that are very specific, very limited in what they can do at a very high level, we can do checks that we cannot typically do in common programming languages. For example, with transpiling for cross-platform development, we ensure that even language-specific tax rules can be adapted across various systems without rewriting code from scratch.

Let’s suppose that you’re writing, for example, some piece of code in Java or Python to define some tax, and you need to take into account tax brackets, right? So there are things that you obviously want to enforce. In this case, for example, you want to have tax brackets that are contiguous and cover all possible sections in natural numbers. Typically, you want to have rates that increase for each bracket. But if you try to write this code in Java, of course, the Java compiler has no idea about those brackets, has no idea that the second bracket should have a higher rate than the first bracket, or in the worst case, the same rate as the first bracket, because it doesn’t know about this concept.

If you create, instead, a language just for taxes, the editor will know about these rules and will point them out immediately as you write this. This approach also makes transpiling for cross-platform development feasible, allowing tax-specific rules to be easily adapted into various programming environments. So we can have checks that are more specific, more high-level, and more conceptual than the kind of errors that your typical compiler can identify. This method provides more value than a typical compiler for a general-purpose language. So I think this idea is really powerful.

‍

Host: 

Because for obvious reasons, in that you have this tool that really will save you so much time, because you just don’t make mistakes before things are sent off. I think that idea in and of itself, if nothing else, is gotten from what has been said or what we've discussed. The idea that you have immediate feedback for everyone who is partaking in your company with regards to what the expectations are for what they do, that is something most people would consider to be valuable. But I think the flip side of that, to some degree, is in order to make that real for their company, that means they would have to learn this new skill, and that’s what it translates as. So could you talk a little bit about what it means to integrate this way of thinking into companies?

Frederico Tomassetti: 

I think this is the most difficult challenge to win. Maybe the most difficult challenge is to let people know that this is a possibility. Because I think many people don’t think it’s possible to create their own language. When they think about creating their own language, they just think, “I don’t need a new Java,” because they don’t think about this possibility of creating a specific language. But beside that, the most difficult challenge is to convince people to embrace it, because it for sure requires people to change their way of working. On one hand, developers can be resistant to that, because they think they are the ones that see less of the problem. Because, from their point of view, they know how to build software, they know how to use Java, Python, C, and say, “Okay, what’s the problem? The software works,” and so they have a hard time understanding the problem on one end. And on the other end, they have invested in learning certain technologies, and maybe they want to preserve this investment.

For example, with transpiling for cross-platform development, a company could create a high-level, custom language that would be translated into the necessary code for different platforms, making development faster and more efficient. However, if you are a data company known for expertise in, say, the Spring framework, creating a higher-level language that generates parts of Spring code could feel like a threat to established skills and job roles.

But in reality, using techniques like transpiling for cross-platform development allows companies to free up developer time, enabling them to focus on building more products and enhancing infrastructure. This approach ultimately increases demand for skilled developers, proving that specialized language tools add value without reducing developer necessity.

Resistant to this for this reason. MH and also experts can be resistant because they—if you don’t explain it well to them—they can have the feeling that you want to make them developers and say, “Okay, I don’t know, I’m a tax consultant, why should I become a developer?” Yeah, and this is not the case. It’s just using some way to specify their expertise so the most valuable things they’re providing is their expertise, and there is no change in that. We are just giving them a better tool to formalize this expertise. So instead of using W, we are giving them something else.

Frederico Tomassetti: 

Yeah, yes. It’s like we are giving them a super version of Word that is able to understand what you’re writing and give you suggestions, things that you may want to revise in a way. Yeah, and testers also could be not too happy, and I think they are the one that may have more reasons to be worried because, in reality, it’s true that this kind of system reduces a lot. We work with organizations that, in certain cases, were employing more testers than developers. In some cases, they realized they needed less testers. Maybe they still needed very good testers—the ones that are very able to think about very strange corner cases or very strange situations—and these were still valuable. But a lot of testers that were doing manual tests and looking for trivial errors that we can automatically catch, well, we need less of them. And this is sad for them, but this is a reality.

But also, as a company scales, the products that they can provide, they end up actually not only getting better testers because the testers that they do get are people of higher quality, but they do need more because there is more to provide. The back and forth the company has to have is much less on an individual issue, so the potential for that company to hire more people over time is definitely greater.

Host: 

Yes, yeah, yes. But I think in a way, it’s the same challenge we have every time we automate some trivial parts. Yeah, and we make people that are less skilled have to upgrade your skills.

Frederico Tomassetti: 

Yes, yes, exactly. Yeah, yeah.

Host: 

Okay, I think this is one of the things I like about the—actually, I’d like to maybe even quantify what it means to do this for your company so that people really understand the value of this because from what I’m saying, it’s almost like it’s—let’s say—reduces cost by about 50% to be able to implement this, regardless of the pain of bringing it in, which doesn’t seem that much. It’s just really learning a new application, really, at the end of the day. And another part of it is that the people who are determining the way that this application is going to work, those are the specialists, so they have a very—they have a big hand in making this feasible. The onboarding of that’s something that they, because they partake in it, shouldn’t be as painful. Is that fair to say?

Frederico Tomassetti: 

Yes, I will maybe I will make some comment on the numbers. First of all, this is an approach that makes sense only for organizations that build a specific kind of software all the time because there is an investment needed in building these languages and the tooling around the languages, and there is a cost in adapting to use—adapting your organization to work with this. So I will not attempt this unless you think that you can get more productive by a factor of at least two, and it can be up to 20 times more productive in some cases. So if you think it can make you 20, even 50% more productive, we will say, “Okay, don’t build that.” But there are cases in which we think instead that it could make you five times more productive, 10 times more productive, and then it’s a no-brainer that you need that. Value this but it will do it interesting yes okay so if a company wanted to do this what would be the best way to approach it is it leadership that has to come and talk about how much value this is you know what what tier of the hierarchy is best to make sure that this actually results in success because it is such a transformational Endeavor?

Frederico Tomassetti: 

Yes, exactly. I think it’s very important that someone high in the hierarchy contacts us or that there is someone high up supporting this project. At the very beginning, you could run into issues. Let’s say you’re a project manager who wants to deliver a project using traditional techniques; you are familiar with the expected challenges and workarounds. However, the first time we incorporate domain-specific languages, it requires involvement from multiple team members and could initially slow down the process.

Using transpilation techniques and leveraging language translation for compatibility, we may discover that there are missing components in the DSL, which could feel stressful. But once integrated, the software development adaptability gained can be significant. In fact, if the whole organization isn’t aligned with the approach, they might not fully understand the initial slowdown, overlooking that future projects will benefit. From the second project onward, this approach enables more efficient cross-platform development.

In our experience, success hinges on having the CTO or a department leader who is fully invested and ensuring everyone is committed to making this approach work.

‍

Host: 

Yeah yeah absolutely so what would you say and obviously this changes with company size but what was what was the shortest and longest integration cycle for the applications you've built and this is including the use of it and then the Perfection of it within the hierarchy and then you hit the point at the end where it actually causes acceleration so that end point would be the point where everybody understands the value now it causes acceleration so what is the what was the highest and lowest for in your experience depending on the company and how they did it and could you also talk about why it was faster for one versus the other?

Frederico Tomassetti: 

There are many variations because some domains are simpler, some companies are more reactive, and so there's a lot of variation. Within a few weeks, though, we can often have some prototypes ready so people can start to get the idea. Then, within a few months, we can deliver a basic domain-specific language (DSL) for a small application, which can keep evolving. Often, people are satisfied with the results and continue improving the DSL.

For example, as the application grows, we might explore transpilation techniques to enable cross-platform development, ensuring the software can run on different platforms without extensive rework. We may also integrate language translation tools to broaden accessibility for various regions and users. These incremental additions lead to substantial software development adaptability, allowing the product to meet evolving needs over time.

Projects like these tend to evolve continuously; when successful, they adapt and grow for years. To consider a unit of utility and a lifecycle for integration, if the domain is straightforward and the company highly responsive, we could see the integration process reaching an operational stage in about three months, in the best-case scenario.

‍

Host:
Yeah, one year. If it takes more than one year, I will start to wonder if the level of commitment is there.

Frederico Tomassetti:
Yes, and I understand it's difficult for companies to change. Personally, I’ve had great experiences with companies in the 30 to 500 employee range. They are big enough to have some resources for investment in new approaches but small enough to involve all necessary people directly. These companies often appreciate software development adaptability, allowing them to innovate while meeting their specific needs. Some companies recognize that domain-specific languages (DSLs) can offer a competitive advantage by tailoring their tools to niche needs.

For example, transpilation techniques enable them to modernize existing codebases efficiently, making legacy systems more accessible through cross-platform development. This is especially valuable for teams aiming to adapt systems originally built for outdated platforms. Additionally, language translation can be crucial for companies trying to expand into new markets or integrate with global technologies. While major corporations like Amazon have extensive resources to outpace competition through scale, smaller firms can use adaptable DSLs and other tools to streamline operations and empower their internal teams.

‍

Host:
But in terms of working with outside vendors and things of that nature, where you can really have a competitive advantage—first, you have to have competitors, and Amazon does not. So 30 to 500, it makes sense that they want to do some acceleration, and in order to do that, a DSL can really provide value there.

Frederico Tomassetti:
Yeah, maybe I phrased that poorly, but I want to say anything.

Host:
Of course.

Frederico Tomassetti:
It's just that if you are, if you have competitors that are much larger than you, maybe you can be more motivated in finding your secret weapon.

Host:
Yeah, so that you can actually forge ahead.

Frederico Tomassetti:
Yeah, absolutely.

Host:
Okay, so thank you so much for the information regarding the business side of it. I think this is really valuable. I think this is something that a lot of people should think about, really bringing in, because it's a very unique way of winning in the business world. But I now want to switch over to the more techy side of it, for people more like us, and see one piece for each group, if we can. And I think one side of me, I really wanted to know how this is possible, which we've talked about, but I also want another side of me to know how you build it. How do you actually, what is a language, what language do you use to create languages? What tools do you use to create tools? What is this Meta-Meta solution space that most people don't really know about?

Frederico Tomassetti:
There is an entire category of tools called language workbenches, and you can think of them as a specialized IDE intended for creating languages. These tools are ideal for building domain-specific languages rather than general-purpose ones. If you're Microsoft and want to create C# and perhaps integrate it with Visual Studio, the design of the language and supporting tools is customized and requires considerable investment. However, when creating a DSL, it’s impractical to match that level of investment, so you need tools that enable faster and more cost-effective solutions, especially as software development adaptability becomes essential.

Among the tools I frequently use are two language workbenches that I highly recommend: XText from Eclipse and The Meta Programming System by JetBrains. Both are open-source and free, making them accessible to a wide audience. XText is particularly effective for creating textual languages, while The Meta Programming System offers transpilation techniques that are useful for cross-platform development, allowing you to efficiently expand your language's reach. This versatility also supports language translation, broadening the potential application for multilingual environments.

The primary technical distinction between projectional and textual editors has significant implications. Textual editors save content exactly as you see it on the screen. In contrast, projectional editors are more like graphical editors; they save an interpretative format, such as XML or JSON, which the editor can then visualize as needed. For instance, if you use a projectional editor for a language with an if-statement, it saves the content in a structured format, detailing the conditions, body, and other clauses of the statement.

‍

Why is this important? This is important for a few reasons. First reason, it means that in your editor, you can have something that looks like text but also something that looks like a table or looks like some graphical notation, because you can write an editor that reads, I don't know, mathematical expressions, a division, and instead of writing some text on the screen, maybe show that as a fraction if it's more convenient for your user. So this is one thing.

The other thing is that—and this is very important when you design DSLs—they make much, much easier to change your language. Now consider what you need to do if you want to change a textual language. So let's say that you have created your language in the first version, you have, I don't know, a while statement, and then you realize that you don't want a while statement, you want to change how it looks and you want to change a little bit how it works and have a do-while instead of a while statement. Now, I'm not saying this is a smart idea, just an example.

The problem is that the people who have used your language—your users—have used the first version of the language, and now you have, I don't know, 1,000 files where people have used the while statement. So if you now change your language, you break all the code that has been written with this language. With a projectional editor instead, you have the possibility of doing a lot of changes in a way that is fully transparent for your user. So you can keep changing the language, and this just works for them because it's just a projection at the end of the day.

Host:
Exactly, so it's just many changes are just a matter of how things look like. So if I change, I don't know, suppose that your while statement and the do-while statement work in the same way, it's just a matter of where you write the condition and where you write "do" instead of "while." It's just, you update the editor, and the editor will just open the exact same file and just show it differently, and this just works, not a problem.

Frederico Tomassetti:
Yes, exactly.

Host:
Can you talk a little bit about how that affects cross-platform transfer for businesses or in terms of the projection editors? 

Frederico Tomassetti:

This is also, I think, an important aspect for DSLs in general, not only for projectional editors, but this is, we were also talking about this with a client yesterday. So let's suppose that you are writing some solution, I don't know, using .NET. Maybe you are taking advantage of some libraries that you have in .NET 4.5.

I guess I'm not a net expert indeed and now you want to change to a new version of the net or maybe to net core I hope I'm saying that and so now maybe you were using some feature of the previous platform that you don't have in the new one and now you have a problem, you need to adapt it. While if you are using an higher level language like a DSL, typically you work on the kind of concept that will remain valid 10 years from now, 20 years from now. Now if I'm defining in my language tax brackets this, the same thing will be true even if I immigrate to a new platform. Yeah, it's a non-business constraint or not specified by the business so it can't... it's hard for it to change and this knowledge can be valuable for a long time. While in that long time, you can have many platforms that change and an example that I like is from this client that I worked with many years ago while I was doing my PhD. They had a software for calculating taxes. It was a company that created their own DSL 30 years ago. They had this DSL to define the different taxes and then they would generate console applications. So it was a long time ago. They have this form in console applications where you could insert values, navigate with your keyboards and so on. Now, of course, after a while people didn’t want to use console applications, they wanted graphical applications at some point. Yes, of course. So they were able to change the code generator attached to their DSL, and instead of generating forms for a console application, they would generate for a graphical application. And by changing just the code generator, all the logic they’d written for the tax calculation was still valid and working on any platform. And ten years after that, people didn’t want graphical applications anymore, people wanted web applications. So again, it was just a matter of changing the code generator and you were able to use the new platform. And I think this is very important because it helps you preserve the investment that is very valuable in this very specific knowledge that you have and make it survive the technological changes.

Host:
Yeah, when you don’t do that, you get stuck in some old platform, that’s frequently the case, but it’s not ideal. Or often you need to rewrite everything in the new platform and this is a huge cost, but also, while you're rewriting everything, you’re not able to maybe deliver new features, you're not able to build new products, you just freeze your organization. And sometimes freezing your organization for two years because you’re doing this huge migration can be disastrous.

Frederico Tomassetti:
No, absolutely. And I think being agile is really important this day and age because, for obvious reasons, technology accelerates very quickly. Being able to remain competitive, all these things are going to be accelerated with you can move from platform to platform or even have a platform, just having anything that’s platform agnostic is going to be an advantage.

Host:
Yes, yeah. So I want to say thank you very much for being on the program. It’s been very interesting to hear what you do and what you're trying to do, and I would really like people to know where they can find you. So, do you have any sort of Twitter, your website, and talk about your company? Struma is the company name, so just for those who don’t know, please just talk about where you can be found.

Frederico Tomassetti:
Sure, I will answer that, but first of all, thank you for the invitation and thank you for the questions because please, it's not easy to talk about these topics and I think you asked me very good questions, gave me the possibility to explain this and you got the sense of what I was trying to communicate. So, thank you. And yes, my company, Instrumenta, by the way, means Tools in Latin because I like to think that we build tools for the mind. So, you can go to struma.com and find out about our company. We have a community that is free and you can join if you want to learn more about language engineering. It’s called Strument. Well, you can find it at strument.do/community, this new extension that we have. You can also find on Twitter by looking for... yes, I know, so we have not much fantasy, so the handle is @strument. Consistency has value, you have cross-platform in all kinds of ways, both in how to discover you and in how you help companies, so I think that’s logically consistent.

Host:
Yes, good. Alright, thank you so much, and thanks for being on our program. All the way from Italy, I’m in Canada, this... I think across the Atlantic, we’ll be able to trade knowledge, and I think that’s really amazing. That’s what computers have been able to do for us, so thank you so much. Living exciting times, exciting times.

Host:
Alright, take care.

Frederico Tomassetti:
Bye-bye.

‍