After having spent a couple of weeks with low code tooling for customer projects I feel finally comfortable commenting on the subject and comparing it with Domain Specific Languages / Subject Matter Languages (SML).
Both DSL/SML and low code aim to hide accidental (technical) complexity by the virtue of providing tooling that takes care of the implementation details. Both want to empower more people to directly contribute to a domain previously reserved for “software people”.This overarching goal can make it easy to think the two approaches are similar as a whole and you could archive the same goal with both of them. This is where similarities between the two approaches end and they solve very different use cases.
Low code wants to allow “everybody” with little training or prior knowledge to be able to build simple applications with little inherent complexity in the domain. For example, a simple CMS to manage customer data or event management and registration website.SML/DSL: Used for domains with a large inherent complexity. They expose this complexity to the expert user so that they can be absolutely precise in solving those problems. For example, describing the taxation system of a complete country or designing a distributed system for autonomous vehicles.
On the tooling side, SMLs and Low Code are quite different. Low code tools are off-the-shelf tools catering to a software engineering workflow with little customizability on the tooling side. They can disrupt an organization because they allow more people to contribute but not because they change the inner workings of an organization.
SMLs are tools specifically tailored to the organizations' needs, processes, and structure. They can disrupt organizations by allowing new ways of collaborations inside the organization and truly unlocking new value by doing so. SMLs typically don’t allow more people to participate, because it requires expert knowledge on the subject, but they empower the expert to contribute directly to the result. SMLs archive this by giving the experts tooling to express the subject matter and ideally making it executable. Rather than writing requirements that are put into an executable system by a software engineer the experts are enabled to experiment with their ideas directly.
Are these two approaches mutually exclusive? Absolutely not. I would argue in the future we will see both approaches used side by side in the same projects. Take as an example a tax calculation application, the actual tax calculation rules and formulas would get encoded with a SML. While the user-facing application to collect the data for the calculation is built with a low code tool.
