Stop Torturing Your Colleagues with DSLs | Hacker News Reader

Stop Torturing Your Colleagues with DSLs

medium.com

3 pointsacmerfight7 comments

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.

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.

Sorry, I couldn't read this beyond the AI slop image at the start.

Thank you for your feedback! I've removed the image to make the content clearer. Please let me know if there’s anything else I can improve.

TL;DR if you make a DSL, do it right.

Which probably requires making them in a language that is prone to extensibility to so you can just reuse existing tooling.

Instead a lot of DSLs happen the way IBM JCL happened - it was explicitly not supposed to be in any way a programming language, was to be fully declarative, but it quickly evolved beyond that creating the monster some of us know.

You're absolutely right that if someone decides to create a DSL, it needs to be done right. The issue, however, is that most DSLs fail to meet this standard. Extensibility and leveraging existing tooling, as you suggest, are indeed critical factors, but they are rarely prioritized in the ad-hoc creation of niche DSLs.

The IBM JCL example perfectly illustrates the pitfalls of poorly managed DSL evolution. What starts as a seemingly simple and declarative tool often spirals into unintended complexity, becoming a "monster" that burdens users instead of empowering them. This is precisely why the original argument advocates for extreme caution: many developers underestimate these risks and overestimate their ability to design robust, maintainable DSLs.

In most cases, a well-designed library or framework offers a far safer and more effective solution, achieving the desired goals without introducing the long-term costs and complexities of an ill-conceived DSL.

Using a language that is actually good at DSLs means you can "extend" the language, so all the tooling for it still works with your DSL, too.

Then your DSL is essentially just library.

Reply on news.ycombinator.com