Why Domain Specific Languages? A Collection of Anecdotes
1–6 of 6 posts
Re: Why Domain Specific Languages? A Collection of Anecdotes
#2The middle ground of DSLs is to consider that to realize a DSL one must have an AST, and an AST is the ultimate data representation for complex business logic, allowing for (almost literally) infinite degrees of introspection or analysis, as well as synthesis of artifacts to be consumed by other tools or individuals in the business (as in compiling reports, generating spreadsheets, and all sorts of intermediary data).
If you can't buy into a DSL, consider thinking about your data as an AST, and the usage of that data as compiling it for various targets.
Users can be hesitant to adopt DSLs. They aren't that hesitant to adopt the extreme amounts of automation that a DSL can give you, and having a structured representation in the form of an AST reduces a lot of friction when developing business automation as compiler passes over it.
Re: Why Domain Specific Languages? A Collection of Anecdotes
#3The middle ground of DSLs is to consider that to realize a DSL one must have an AST, and an AST is the ultimate data representation for complex business logic, allowing for (almost literally) infinite degrees of introspection or analysis, as well as synthesis of artifacts to be consumed by other tools or individuals in the business (as in compiling reports, generating spreadsheets, and all sorts of intermediary data)…
> to realize a DSL one must have an AST
Not necessarily. I think a parser combinator library counts as a DSL. Yet, the result from using that DSL is normally a function that you run to parse from sources. IOW, the DSL functions take functions and return functions built from them. You can't introspect that.
Re: Why Domain Specific Languages? A Collection of Anecdotes
#4The middle ground of DSLs is to consider that to realize a DSL one must have an AST, and an AST is the ultimate data representation for complex business logic, allowing for (almost literally) infinite degrees of introspection or analysis, as well as synthesis of artifacts to be consumed by other tools or individuals in the business (as in compiling reports, generating spreadsheets, and all sorts of intermediary data)…
My impression (strengthened by your argument) is that nearly anything we can say about a DSL we can say about data in general (as opposed to code). A DSL at the end of the day is just a specialized, idealized schema for data representation. Most of its advantages would also apply (in varying degrees) to storing business information as JSON, or in SQL tables, or as s-expressions for that matter. In any of these cases we get the same benefits of portability, introspectability, automation, etc.
That's not to say that DSLs are useless. In many cases they have advantages against the above formats in terms of both what they can, and (just as important) can't, express. I just think they're part of a bigger conversation.
Re: Why Domain Specific Languages? A Collection of Anecdotes
#5I'm wondering if DSL could be the next evolutionary step of nocode and lowcode movement.
The language could be provided by the platform provider (e.g a simple language for expressing website UI/UX), or it could be completely ad hoc, designed by a non technical user, with the help of a technical user or a graphical tool perhaps.
Armed with a newfound expressive language designed by themselves, a non technical user could go to town building whatever they wanted, instead of being bogged by the limitations and learning curve of a nocode tool.
Re: Why Domain Specific Languages? A Collection of Anecdotes
#6I've grown to dislike DSL's, especially when it comes to building software. The main problem is I don't spend much time in them so every time I need to make a change I'm back looking at unfamiliar code again. I'd much rather use the same language as the product and calling library functions or building an object model even if it is slightly more verbose.