Comment by boomlinde

Good time to urge people to comment on the article, not on a term you saw in the headline.

> 99% of the time, what you need is a good high level library/API to deal with the problem with your current technology.

TFA exactly describes a solution based on current technology available in Lua.

> First, you need to design it properly, and most devs are not good language designers.

A lot of languages are small and obvious, like the one described in TFA.

> Second, unless you are incredibly talented and have little constraints, you will not even remotely provide 1% of the tooling existing languages already have for free. I've seen so many DSL without basic syntax highlighting nor linter it's not even funny, but you need much more to be productive with a new language. Even if you are using macros and claim to be able to use the tooling for the main language you come from, stop a second and think about the last time you had fun debugging a complicated macro magic.

TFA addresses this not by macros or an entirely custom language, but by using Lua grammar for it entirely.

> Third you need to test it and document it. Do you even do it properly for your regular code? It takes time and resources. A lot of it. Which could be better spend on the project, or on the library/API you should be writing about.

"You need to test your code" is not a problem unique to DSLs

> Fourth, what about training? Because you can hire somebody for language X. But for your DSL, you'll need to train them.

I've skimmed the article for a total of maybe 45 seconds and I know the ins and outs of the DSL it describes. "You need to understand your code to work with it" is again not a DSL specific problem.

> Then of course, you plan to support it for as long as it's used. Right? Right?

Another code-in-general remark.