Obviously these are sweeping statements, but the problem with this generalization is that successful DSLs become invisible because we take them for granted. Regular expressions are a DSL. SQL is a DSL. LaTeX is a DSL. The Wikipedia page on domain-specific languages even lists HTML as an example: https://en.wikipedia.org/wiki/Domain-specific_language#Examp...

With regard to LaTeX or HTML, you could even argue that their goals could be better accomplished with some sort of graphical interface, which sounds a lot like… visual programming!

Geometric constraint solvers are essentially graphical, declarative domain-specific languages for mechanical/physical design. As an example: http://solvespace.com/index.pl

I would argue that perhaps with the exception of regex, the examples you mentioned are excellent ideas that are awsome despite their suboptimal DSLs, and they would have been even better if their DSLs had been implemented as extensions in a Lisp-like language.

I agree that it's good for a DSL to give not just unfiltered but well integrated access to the underlying implementation language, instead of trying to replace it with a dumbed down domain specific language.

It should be possible for implementation language programmers to create new primitives, that visual language programmers can easily use without learning the implementation language.

And that extension interface should be part of the visual programming language from day one, good enough for the visual language to use itself for most of its built-in primitives, not an afterthought nailed onto the side.

I think the future is General Purpose Languages that make DSL. Right now we have Racket and that is such a powerful thing to create DSL simply.