Hacker News Reader

Comment by kpil | Hacker News Reader

I disagree that DSLs are the right choice unless it's an extension to the suitably flexible implementation language itself.

Actually, the perceived need for "dumb" DSLs is sprung from the same misconceptions as mentioned in the article and the end result is inevitably that simple problems are made somewhat simpler and complex problems turn into impossible problems.

A proper DSL extension in an unobtrusive host language is another thing but also hard to find. If a Lisp syntax is acceptable then that's the canonical example.

I don't want to get depressed overe all misconcieved excuses for test automation languages, process automation, configuration templating systems, etc, so I'll just stop here.

View on HN

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.

Reply on news.ycombinator.com