If you can solve your problems without actually changing the syntax, then you don’t need to build a…

If you can solve your problems without actually changing the syntax, then you don’t need to build a language.

All languages are domain-specific, so I sort of hate the use of the term DSL to refer to what amounts to a big library with specific idioms.

The point of learning a new language is that a different syntax changes the natural way to think about problems; if a DSL makes a big difference, then that’s fine, but it’s not really comparable to language design. Writing a DSL may also reduce pain points incrementally in a way that prevents you from making much greater strides with syntax changes (in the same way that Zizek suggests the existence of charity prevents people from being serious about reform).

If a DSL is really enough, then that’s fine. But, if you’re considering actually writing a language, think carefully about whether or not a vastly different syntax would be better. If a DSL reduces the problem by 20% and a new language reduces it by 80%, a new language is justifed.

I absolutely condone writing interpreted languages in other interpreted languages. Doing so saves a lot of early development effort. A well-designed language can always be reimplemented in a faster way later (while a poorly-designed language is going to be very difficult to make even small optimizations for).