Tell HN: Please stop making more DSLs

At some point we lost the original concept of DSLs. The “domain” here was supposed to be fairly far removed from the realms of software engineering. For example, if you work for a bank, a DSL couched in the needs of financial modeling for the problems of the bank. If you work in automotive, a DSL that is hand crafted for the purpose of running on the car you are building. In particular the idea was very much these would be used by non-programmers. Programmers would work with domain experts to organically evolve one or more, intermixable domain languages, in the interest of more precisely capturing their knowledge than written specs, and allow them to iterate on the software independently from engineers. The domain languages often were intentionally imprecise and ambiguous, with programmers tasked with providing generators and interpreters into a running system. I think the concept still has merit - that we still live in a world where domain experts are largely siloed from being able to actually adjust the behavior of the software systems they’re stakeholders in is sign enough there is still work to be done, even if DSLs aren’t the solution.

The concept kind of came and went, the two projects that really went all in on the idea were JetBrains MPS (still alive) and Intentional Software (now dead.)

Edit: MPS has some case studies on their site that nicely demonstrate the concept here - as you can tell, it’s very different than the way we typically use DSLs :)

Edit2: they have a pretty good video that explains the core concept above here: https://m.youtube.com/watch?v=eEUMAx3g6do

Please, at least once in your life, make a DSL for the sheer joy of creation:

https://craftinginterpreters.com/

Don't most DSLs sit atop an existing language, thus giving you easy access to the existing language's ecosystem as well as the syntactic or semantic advantages that led you to create the DSL in the first place?

It's not an either/or relationship, at least not in my experience.

I think of the awful battles over configuration languages and systems like YAML, TOML, and the Spring Framework. People eventually get the idea this is the road to ruin so they think “let’s write configuration as code” which is the highway to hell.

And to think that all the energy that went into creating so many new DSLs could have been directed to making even more linux distributions. Such shame.

I disagree; I think that for many purposes, DSL will be good. It is not for all purposes, but sometimes it is very helpful for specific uses. However, using and implementing existing programming languages can also be good.

Sometimes, it is helpful to use another programming language and to use the full capabilities of other programming languages. Sometimes, other programming languages are unsuitable for various purposes, including that you do not want the full capabilities, or they do things which are undesirable for this use, etc. It depends on the program that uses them, probably. (Note also that, some programming languages will work better for the purpose of embedded DSL, than other ones will be, although it also depends on the specific use, too.)

However, some programming languages can be usable for multiple uses, e.g. PostScript is both general purpose and special purpose, as well as both text and binary format, and some people have said, also both esoteric and non-esoteric at the same time, too. And, many DSLs can be embedded in other programming languages and can be helpful, but that is not always the case; sometimes it isn't helpful.

Some game programs such as ZZT, MegaZeux, PuzzleScript, MESH:Hero Hearts, and Free Hero Mesh have their own programming languages. I invented Free Hero Mesh, and had designed it for this purpose. I also have idea of a format for Magic: the Gathering cards which can be executed in computer (a special design for this purpose may have many advantages including that AST-based text-changing effects can work).

There can also be data formats. JSON has some disadvantages (including: lack of comments, using Unicode, no optional trailing commas, no 64-bit integers, no directly blobs (they must be encoded), and other problems), so other formats can be helpful to be an improvement for some uses. RDF has some problem so I made up DRDF. And then, other format again, can be useful for different purposes; they will not all need the same things.

Since everything turing complete any can any and so on… The main big difference between languages is the context in which your program text is placed. Readily available meanings of your words. Different problems beg for different contexts. Having documented DSL with tooling is so much easier than shoehorning generic language using boilerplate code.

Here is an example of a DSL program, with the output: https://www.contextfreeart.org/gallery/view.php?id=3779 Could you do it in Java? Yes! Could you so effortlesly experiment and arrive at this, simply by experimentin with your code? Hmm.

Maybe some examples would making this more convincing...

The only thing worse than a DSL is a poorly specified DSL built on top of a generic format like XML, JSON or YAML.

How else do I charge customers an annual licensing fee without exposing myself to open source, licensing-free alternatives?

I will invest time in mastering a tool like jq that does its needful thing and does it well.

I actually prefer DSLs over generic programming languages