DSL as domain reference truth
I have always been a very visual thinker, I tend to think in images and feelings, and less in words. Therefore having just reread my Why Use Arrows and PowerPoint to Express Software Designs? blog, which is all about using visual props to help you design systems, and remembering how ineffective these visual representations were in helping me share my ideas, I find myself needing to accept that my carefully crafted "invariants as drawings" approach have really mostly only helped me, and definitely were unable to express enough to others to drive a software development! The bright side of this story, is as much as at Actant, as later a Elevence, we had the insights to center development around a DSL. The team then having the freedom to express the needed properties in the DSL, I having the freedom to ask for something non-obvious by describing the expected behaviors, not the invariants, and especially not as visual projections that lack reading instructions.
The bigger story is that code is the purest and most effective form of communication between developers. Strong team leverage code both as a delivery and as their team's knowledge glue, the team's purest expression of meaning that ensures team alignment, independence, and productivity. Therefore, because a DSL captures domain semantics in its interpretation, a DSL naturally become the purest and most effective form of communication to a broader team where product owns the domains semantics. And therefore this is the development methodology because an iteration over product -> DSL-> "code that by construction preserves the properties of the DSL", is very effective. That is the core of the The Engine of Approximated Certainty: An Introduction to High-Performance Software Engineering methodology I have been writing about.
The above observations somewhat bring the whole narrative back to earth: a team that leverages a DSL does not need to be an elite team, it just needs the right tools. And more importantly, there is high risk when the DSL is not pure enough, or the development approach is not DSL invariant property preserving enough. A consequence is that your DSL must build on the shoulders of giants! A pure lambda calculus, a pure closure on recursive sets, a clean tensor algebra basis for the DSL? Yes, you are in solid grounds. Something informal, half baked, heuristics? Beware! A weak DSL, a weak domain semantics model approach will bleed you to death!
(Note: my son said: please no more LLM generated text. All of the above is purely human! 🤠)
All original content copyright James Litsios, 2026.