IMHO author is missing the historical perspective of DSL approach. In the time when SQL was developed, users simply needed a much higher level of tech skills than today. One older colleague told me once how he wrote his PhD thesis using ed (unix line-editor), and it was more than 100 pages work. To us that seems crazy complicated and unfriendly, editing 100s of pages line by line using obscure single letter commands, but to them it was a huge improvement compared to typing it on a typewriter - and they all learned how to use it. Similarly, analyst in the days when SQL was invented had very different expectations and ideas about what "simple to use" means. Back then you expected that you need to type your commands as text, so developing specialized tools in form of DSLs was a perfectly logical step. Today DSLs make less sense as we can build spreadsheets, wizards, visual drag&drop UIs, AIs for speech commands and so on. Users' expectations and skills are completely different now, and it's less likely that they'll invest time into learning a new language, they want buttons to click. That's why DSLs are now more a middle step that simplifies life for programmers when dealing with specialized tasks - for those areas where visual tools are too limiting, but still you need a way to abstract the complexity - just the way the SQL does it.