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

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…

* * *

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).

By [John Ohno](https://medium.com/@enkiv2) on [May 23,
2017](https://medium.com/p/8bb50b9d439f).

[Canonical link](https://medium.com/@enkiv2/if-you-can-solve-your-problems-
without-actually-changing-the-syntax-then-you-dont-need-to-
build-a-8bb50b9d439f)

Exported from [Medium](https://medium.com) on September 18, 2020.