To me it is an issue of documentation mainly, smart programmers cannot read minds either. There are standard and effort-efficient ways to document function APIs

To me it is an issue of documentation mainly, smart programmers cannot read minds either. There are standard and effort-efficient ways to document function APIs, whereas DSLs need full user guides. They have complex rules about what are valid expressions and what they do, hard to guess without a thorough explanation, and incompatible with modern dev tooling that makes it easier to quickly to discover how to use an API without much reading or trial-and-error. I do agree there is room for such approaches and they can have 10x effects in some situations. But more often than not, smart programmers can get wrapped up in the logical beauty of it all, distracted away from the core problem, feeling extremely productive but barely getting anything real done (like Vim can make feel so much faster but you really aren’t when you measure and compare properly). Creating new languages is useful: config, markup, query… But it is hard and laborious to do well, and usually it is only successful if creating the language is your core goal, rather as a one-off auxiliary part of solving a problem, as languages like Forth or Lisp constantly encourage by their design. And, again, a non-trivial language without a manual is unusable (or it is trivial). Limits to flexibility can be very useful: they make you focus on solving the problem with the tools you have, rather than making the perfect tools to solve the problem, tools that you will probably never use again because they are too tailored to that one problem.