Stop Torturing Your Colleagues with DSLs

2 min read Original article ↗

DSLs: Glamorous Yet Isolated Islands

DSLs often feel like magical tools that can solve all problems, making you feel like a god with the power to create worlds. In reality, they are more akin to isolated islands adorned with shiny decorations but riddled with traps, venomous snakes, and wild beasts. Only a select few “natives” — the developers who participated in their creation — can navigate these islands with ease.

Why is that? Because DSLs often address surface-level problems while introducing deeper challenges:

  • Steep learning curves
  • Maintenance headaches
  • Communication barriers
  • Lack of community support

Creating such an island may seem cool, but it ends up stranding your team in a maze of complexity.

When you decide to invent a DSL, what you’re essentially doing is forcing your team to learn a brand-new language designed to solve a very narrow set of problems. This is akin to telling your colleagues:
“Hey, I’ve invented a new language to solve problem X. Now you all have to learn it, or you’ll be too outdated.”
This approach is, frankly, selfish.

Even worse, many DSL creators aren’t experts in language design. This means the language is often riddled with flaws and limitations from the start. So, your team isn’t just learning a new language — they’re also battling a flawed system. And when the DSL’s original creators — the “natives” — leave the team, they often take with them the knowledge needed to maintain it. The remaining team members are left stranded, faced with cryptic symbols and unmaintainable code, like being abandoned on an unfamiliar island.