Hacker News Reader

Comment by doug_durham | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com