Shawn Hartsock

Where answers come from

Some pages can ask a language model questions. Set this up once; your choice is remembered in this browser for the whole site.

Model source
Use another source instead
You sign in on OpenRouter; it gives this page a key for your account.

When NOT to use a Domain Specific Language

By Shawn Hartsock (author)

Originally published .

Republished from Thoughts and Ideas. The original writing is preserved; topic and concept suggestions are generated metadata, not part of the original article.

There’s really one rule I can use to sum up why you would not use a domain specific language.

Do not use a Domain Specific Language when implementation specifics out weigh domain specifics.

This one rule covers numerous cases:

  1. when intimate knowledge of API are as important as function

  2. when performance is critical and requires expert knowledge

  3. when implementation details are nearly as important as semantic details

All these cases and numerous variations on this theme are summed up by acknowledging that the choice of using a Domain Specific Language (DSL) is a design trade off. You are deliberately adding a layer to your application stack. This layer intrinsically incurs a maintenance and/or performance cost. (Not all DSL cost additional clock cycles at run time it depends on your implementation.)

With these costs and benefits in mind you can make an intelligent choice about when and where to use this tool. It is far from a panacea but Domain Specific Languages do have the allure of potentially netting you accidental programmers and preserving folk knowledge about your system and its real world uses that few other techniques offer.

Explore the map · Browse by topic and date