Hacker News new | ask | show | jobs
by doug_durham 19 days ago
In commercial practice DSLs are an anti-pattern. Someone will create an under-documented DSL that only they understand and move on. The following programmers have to try to decipher this strange language. It is almost always a better idea to use standard language structures and features. Code is read more than it is written.
2 comments

In Lisp, those following programmers can simply macroexpand. With modern tools they can even do it inside their editor, co-located as replacement text in the same source file, connected to a live Lisp environment, if they wish.

A great example is Common Lisp's own LOOP macro - if someone's usage is difficult to understand, you simply ask Lisp to expand it into the more verbose non-LOOP fundamental calls, and you don't need to understand anything about LOOP. In fact you can replace the LOOP form with the expanded code.

That's a key difference from DSL's in most other languages where the DSL code is really data structures that are interpreted.

Hate to break it to you, but every time you create a function, you're creating your own language, specific to the domain.

I suspect what you're actually objecting to is a lack of referential transparency, which is a problem in many languages (including Lisp, to be fair).

I’m not referring to trivial functions nor classes. I talking about things like overloading operators, or changing the default idioms of the language. This means that a person can’t read the code without fully understanding the entire class structure. For the most part DSLs are highly personal. What one person thinks is a great formalism that make it easy to reason about the problem, to everyone else is spaghetti code.