Domain-Specific Languages vs. Notation

I find DSLs (<i>especially</i> turing complete DSLs) which try to emulate written English to be grating.<p>This was what COBOL attempted to do, and far from having the intended effect (allowing non-specialists to program), it actually just created new breeds of specialists who could understand this new and really rather bad programming language.<p>Capybara&#x27;s isn&#x27;t that bad, although trying to make a more human readable DSL that uses XPath is a little ironic. The robot framework is probably the language that does this that I hate the most because it&#x27;s turing complete and, IMO, actually less readable and usable than the language it was built upon.

I strongly approve of this message. I think the reason why Ruby has such terrible DSLs is not due to its technological strengths or weaknesses but instead because the community promotes the idea that a good DSL is super human readable.<p>I&#x27;m not one to denigrate syntax or readability, but I think it must without any question be prioritized <i>below</i> good semantics. The &quot;Zen of Python&quot; has some (but hardly all) this hammered out well<p><pre><code> * Explicit is better than implicit. * Simple is better than complex. * Special cases aren&#x27;t special enough to break the rules. * In the face of ambiguity, refuse the temptation to guess. </code></pre> Working in DSLs—and really there&#x27;s no reason to think that we&#x27;re not always working in DSLs nearer or further from our actual domain—should simplify <i>concepts</i> first and syntax later.

Author hasn&#x27;t stated that what Ruby calls &quot;DSL&quot; is merely an API, not a language. It&#x27;s still valid Ruby, so by definition it&#x27;s not a domain-specific <i>language</i>.

Perhaps I missed something, but is the author conflating the idea of using english language from the domain as function&#x2F;variable names with having a real DSL?<p>DSLs are parsed&#x2F;compiled&#x2F;interpreted. If you&#x27;re doing one of those things, and the words represent concepts in the problem domain? You&#x27;ve got a DSL. Otherwise you just have a well-named API.<p>But I may have missed it. I failed to see the point of this article -- perhaps I am in violent agreement and do not realize it!

Having an API that matches a natural language is not a DSL per se, either internal or external. It may help creating an internal DSL though. An external DSL is parsed and compiled or interpreted into or by another general programming language, usually. An internal DSL, the way I see it, is a &#x27;language&#x27; that uses the language it is embedded in in such a way that it makes it easy to read and understand by those initiated with the DSL (ie. the domain experts). And may not look all that much like the embedding language.<p>The benefit of a DSL can be that you can do verification etc on the semantics of the domain. An API with handy naming may not be able to do this trick.<p>Note that the readers and writers of a DSL may be very different audiences: the readers can be domain experts who give feedback while the writers may be software engineers.

<i>&quot;Programming languages often advertise themselves as being well-suited for writing domain-specific languages (DSLs), [...]. Ruby is probably the most popular such language, but many others—such as Scala, CoffeeScript, and Io...&quot;</i><p>I got a bit cynical when the list stopped there. But maybe these languages are indeed as powerful and expressive as the Lisp of the day?

Several years ago there was a big DSL hype which - more or less - faded away. It is very hard to construct a DSL and once established it is cast in stone. In contrast, APIs are much simpler and more flexible.

lisp lisp lisp lisp lisp lisp