At Xatkit, we continue our quest to find the optimal language for bot and chatbot development. Some time ago we explained our decision to move to a DSL (Domain-Specific Language) based on state machine semantics to help you create more powerful bots.
This DSL was definitely an improvement over our first attempt at creating a chatbot DSL, but we quickly noticed some issues, nice-to-have features, or cumbersome things we still had to deal with. For instance, the execution language needed to integrate reusable functions/methods to support the complex bots we are working on. Dependency management was also a nightmare because of the multiple layers that needed to be configured. Most of these issues had nothing to do with the semantics of the language but with the syntax and infrastructure.
Therefore, we decided to keep the state machine semantics but change the language syntax by moving from an External DSL to an Internal DSL. An external DSL is an independent language (with its own grammar, parser, compiler,...). Internal DSLs are embedded in a general-purpose language, typically as a particular form of API, known as a Fluent API or fluent interface.
The move to an internal DSL brings several benefits that we hope you'll appreciate:
- No need to learn a new language, just use Java
- No need to use any specific tool to build Xatkit bots, any Java IDE will do
- Benefit from all existing Java tools when creating, debugging and testing bots
- Use the full power of the Java language (and all the libraries) to create complex bots (if needed).
All this while keeping well-defined and high-level semantics provided by our internal DSL / fluent interface. So, we are basically combining the benefits of having a specific chatbot DSL with the power of a general-purpose language.
We have now released a new version of Xatkit and its runtime engine so that you can start using this new syntax in the creation of your bots. We'll be adding more documentation on the new Fluent Interface / DSL constructs soon but let me present to you the key ones in this GreetingsBot example, a simple bot that just says replies when it detects you're greeting it. You can find the full source bot code here, in the following I'll just focus on a few core parts.
Intent definition
We can easily create the intents the bot should recognize (in this example, the greetings and how the user is feeling right now) and the training sentences to be used to teach the bot how to understand them (these sentences will be used, for instance, when configuring the bot to use DialogFlow as Intent Recognition Provider).
In a similar fashion, you can also define mapping entities and parameters to collect relevant data from the user utterance during the matching process (to be used later on in the response, e.g. getting the user name and using it to answer her in a more personal way later on in the bot workflow).
Platform definition
Xatkit supports a number of platforms (and you can build your own!) so the next step is to declare what combinations of platforms your bot is going to be using (either calling actions on the platform or getting events from it). It could be more than one (e.g. our bots that let you talk with GitHub from Slack). In this example, we use our web-based React chat platform as the only input/output of the bot.
Conversation flow and bot reactions definition
Finally for each intent we define the bot reply. As our chatbot language is based on state-machine semantics, we can define states, (conditional) transitions between states, default and local fallback states,... to create conversations as complex as needed.
As you can see, the design of the Fluent API relies heavily on method chaining to improve code legibility and reduce the need for intermediate variables. At the same time, the key concepts of bot design (intent, state, platform,...) are immediately available to the bot designer that doesn't need to get distracted by boilerplate or advanced Java code (unless s/he wants to).
By the way, we are aware that it's impossible to create a single language that caters to all types of chatbot creators. There is no such thing as a bot language to rule them all. The experiences we had with non-developers led to a conclusion: as abstract as our DSL was it was still too technical to use. So instead of keep pursuing this dream, we have focused on building a bot environment easy to use by developers, allowing them to reuse their preferred language, IDE, and tooling. We'll keep adding more docs and tutorials explaining the new syntax but some of the key methods are explained here.
We're confident technical people will enjoy this new proposal of using a fluent interface for defining bots. While for non-technical people will develop other interfaces (e.g. see our graphical bot representation or even more (semi)automatic ways to create a bot from whatever information they already have) on top of it. Expect some news on these other fronts as well! And as always, let us know what you think about this new way of defining bots in Xatkit.
Top comments (0)