Huh? SQL is just as DSL-y as anything else. It's so non-standardized that I can't take any program written for any RDBMS and run it against any other RDBMS, unl

Huh? SQL is just as DSL-y as anything else. It's so non-standardized that I can't take any program written for any RDBMS and run it against any other RDBMS, unless the author specifically extracted all the DSL into an interface layer and ported it to that other RDBMS already. There are lots of weird parallels between SQL and Smalltalk. For example, both SQL and Smalltalk are constructed with Douglas Hofstader's "strange loops." All Smalltalk object instances have a class, and the classes themselves are object instances. SQL tables are defined using metadata stored in SQL tables. Another parallel, is that the language variants are very similar, but ultimately incompatible to the point where translation is non-trivial. In Smalltalk, this is due to a toothless language standard, resulting from political maneuvering by various language vendors. Not sure what it is in the case of SQL. There is a problematic relationship between DSLs and libraries in languages of sufficient power. In programming languages with a certain level of expressive power, it's easy to write a DSL on top of a library, or on top of another DSL. https://xkcd.com/927/ https://xkcd.com/927/ I used to joke about "lady/gentleman computer scientists." What's the difference? A computer scientist knows how to implement another computer language. A lady/gentleman computer scientist knows when they should know better. A DSL should be used to super-charge your project's very idiosyncratic special context. The trick is knowing better when you shouldn't. Accessing a database isn't your project's very idiosyncratic special context.