[corinroyal]

DSLs are not a new or a bad thing. We use them everyday. SQL, HTML, CSS, JSON, Postscript, Markdown, YAML, Latex, and GNU make are all DSLs. The job of a programmer is to come up with thoughtful composable abstractions, a vocabulary of nouns and verbs, that match how experts tend to think about the problem domain. That's all I do all day. Imagine SQL as a library. Sorry, I meant don't.

Perhaps the difference is that my DSLs are hosted on Lisp, so inherit that syntax. The nouns and verbs I create extend the standard library transparently. There is nothing to learn but the vocabulary. So perhaps programmers who aren't confident about language design should avoid creating DSLs that aren't hosted on a good general purpose language. Everyone else should write DSLs on top of Lisp the way God and John McCarthy intended.

[acmerfight]

Thank you for sharing your thoughts. You’ve highlighted some great examples of DSLs that have become essential tools in software development, like SQL and Markdown. However, the success of these DSLs often lies in their universality, broad adoption, and well-thought-out design. These qualities make them more than just isolated islands—they are foundational tools backed by strong community support and decades of refinement.

The point of the original argument is not to dismiss DSLs entirely but to caution against the hasty creation of niche, poorly designed DSLs that solve narrow problems at the cost of maintainability, steep learning curves, and a lack of long-term viability. The challenge is that many developers underestimate the complexity of language design and overestimate the benefits of introducing a new DSL for a specific use case.

In conclusion, the advice is not to avoid DSLs altogether but to approach them with caution, ensuring they address real needs without creating undue burden on the team. Thoughtful design and a strong host language can certainly help, but they don’t eliminate the broader risks associated with creating domain-specific abstractions.