4 ms·
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 toolin
by p_l 2y ago
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.
- acmerfight 2y agoYou'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.
- p_l 2y agoUsing 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.