Evangelizing a Domain-Specific Language - Lessons Learned

Today, 10th Oct 2020, marked the completion of a 10-day training session of a fresh batch of trainees who graduated successfully to utilize Atomiton's Runtime - A-Stack 2.x where Thing Query Language (TQL) is an integral part of the stack. Version 2.x introduces a whole slew of new rich language features - Code and Data Markup (CDM), Behavior Modeling Language (BML) - a semi-compiled, homoiconic, multi-syntax programming language primarily intended for the development and subsequent evolution of scalable distributed Industrial IoT applications.

Incidentally, this training session was also the 10th session in the TQL101 series of training sessions which I had the honor of leading over the past several years. As Engineers, we never go back and put all our learnings into a single thought. Writing this article, I thought was the best way to summarize my learnings while evangelizing the language and thank my trainees for their everlasting support. Below is a brief description of my learnings.

Be prepared to answer the big question - Why learn your language?

The first question you will be asked right off the bat is - "why should we learn your language?" This is especially true if the language you are trying to put forward becomes the central part of developers' application stack which is about to capture your modeling, process business logic, and associated data access. In other words, you will be compared against the big guns of Java, SpringBoot, Node.js, and C#.

The answer to this question is much easier if the language you are about to teach helps developers achieve very specific tasks like integrating search in their application using Splunk syntax.

There isn't a simple answer to this question. The best answer is the one that eliminates the fear in the Developer's mind of getting stuck with your stack. Reinforce in the developer's mind that learning a language is just like acquiring another skillset. I always used the famous quote "design of special-purpose programming languages for educational use has a long history..." (Is programming obsolete?) from a now-retired professor of Berkeley and the creator of UCBLogo, Brian Harvey.

The main reason for introducing a special-purpose programming language is to solve the problem of managing things and data in a single pane of glass. We strongly believed that traditional data-centric application development can not be used to solve applications that are thing-oriented at scale.

Provide examples, examples and more examples

Introducing a new language without a rich set of examples and patterns is like showing developers all the glitter that doesn't shine. There has to be a rich set of examples and design patterns. It is nearly impossible to create all types of examples. Especially true for a startup where the resources spread thin. We need to create a continuous looping mechanism whereby examples are auto-created by the developer ecosystem.

Provide freedom of choice to integrate into the overall application stack

• Here honesty is the best policy. Never try to push developers to use the language feature when the feature can be easily be done via other available third-party or open-source libraries.
• Provide proper integration hooks to all the developer required tooling - CI / CD, DevOps
• The new language should feel like any other language general-purpose language.
• Provide freedom of choice to use editors of their choice Most of the developer's used Eclipse to edit and write TQL code, and it was perfectly acceptable.

Language (version 1.x) deficiencies and lack of developer tooling has to outweigh the benefits

Let's face it the new language version 1.0 is going to have a teething problem. But the initial language deficiencies and the lack of developer tooling (debugger for example) have to outweigh the benefits.

Luckily, TQL had Modeling, a core part of our language that was a saving grace on many occasions. Giving developers to capture Process, Things, and Data in a single unified Thing Modeling Language (TDL) was the language feature developers found hard to resist and were willing to forgo other 1.0 version language deficiencies.

Be prepared to cater to different learner groups

It is important to categorize the developers and never mix them into one setting. It does not do justice overall to the language and the teaching. We ended up created TQL101, TQL201, and TQL301 classes levels. Certainly, TQL101 was for all, and our content was kept general without going into details of a particular feature.

• Enthusiast - They are here for fun and make something, show them the fun part of the language. Creating IoTKit was fun and helped us in catering to the Enthusiast
• Beginners - Beginners will tell if you if your language is easy to learn and adopt.
• Evaluators - Showcase the language in-depth, especially for enterprise architects. A broad acceptance of evaluators is a good validation of your reason for a domain-specific language.
• Core Developers - Protect, nurture, and listen to your core developers. These are by far the most important category of developers who are going to be a flag bearer of your language. Draw parallels to the technology of language they are most familiar with.

Build in-house talent

Follow the simple rule - Use it before you teach it to others to use it. We benefited greatly by using the language internally for any and every purpose and build an Atomiton Engineering team where TQL101 became their first onboarding pre-requisite. We continue to reap the benefits of this rule.

Listen and incorporate feedback in the next version

We have over 1000 features in language and each of them can be attributed to our keen desire to learn from the usage and incorporate them in the next version. TQL iterated over 38 releases of 1.x over a period of 4 years i.e. almost 1 release per month before we blew it open with 2.0 features. A great example is moving away from XML as a markup to a more compact CDM format that looks and feels like python!

Respect and thank your pioneers 

Finally, remember to thank and respect your developers who help you reach version 2.x and beyond. We are indebted to our TQL pioneers without who version 2.x would never be possible and continue on our journey to redefine the application development paradigm.

Here is our vote of thanks to our TQL pioneers

1. Srinath - Without your feedback and contribution, TQL modeling would never reach the richness that it now has.
2. Pratham - You have defined and shown us the power and limitations by completing the first Enterprise-grade industrial application built on TQL
3. Rakesh Sharma - Largest code based on TQL is written by you. What else to thank for?
4. Sagar Gaikwad - From building our first protocol handler to creating yet another enterprise-grade application removing all the limitations and mistakes of earlier development.
5. Pramod Mali, Tushar Kadu - You led the creation of in-house talent. You created TQLStuduo proudly built on TQL!
6. Suchitra Nair - You led us through the critical phase of the largest enterprise deployment to be built on TQL. Thank you!
7. Vikrant Talponkar - You were a gem of a TQL Developer.
8. Sachin - You showed us how to do DevOps for an enterprise solution built on TQL. Your immense knowledge of crafting Queries to help debug production problem has become our guiding principle to create DevOps features in A-Stack.
9. Kislay Kishore - You showed us to build re-usable services on top of TQL.
10. All my trainees from TQL101 class5 in Hochiminh city. Thank you Anh Phi for the opportunity.