[efitz]

I am not a fan of DSLs. Perhaps there are use cases where they are the best tool, but in general they impose a significant learning burden on those who join a project that uses a DSL. I’ve seen several DSL projects wither and die because no one wanted to learn the DSL because the knowledge and time investment did not transfer forward to anything else they would do in the future. My personal opinion is that DSLs are vanity projects; one can usually come very close to DSL clarity and simplicity by adding appropriate methods or functions. You just don’t get fancy syntactic sugar.

Maybe DSLs are “write-only” languages for humans.

I don’t wish ill or sadness on anyone but it doesn’t bother me at all if LLMs drive DSLs into extinction.

[cogman10]

IMO, the best way to approach a DSL is simply using existing languages with a fairly flexible syntax. We've done this with groovy and it's worked quiet well. If I were to do it again I'd probably pick something like kotlin or ruby instead just because they both seem to have more industry relevance.

The beauty of picking an existing language as the base is you often get an expansive standard library from the get-go. That means your job as a "DSL" writer is more based on making sure you provide the value adds that make sense for the writers of that DSL.

It's worked particularly well for us because we have a data intake pipeline that has to parse and handle all sorts of random garbage (emails, excel docs, csv files, pdfs, etc).

A language like groovy, ruby, and kotlin all work well because it's trivial to add extensions to the syntax in a way that makes sense for your domain problem. Typescript also wouldn't be a bad choice for similar reasons, the only reason I wouldn't consider it is we run a JVM backend and parsing typescript for the JVM is somewhat of a PITA.