I've created somewhere around 5-10 languages. Most are domain specific, some are new internally generated general purpose languages in "black box" use in clien

I've created somewhere around 5-10 languages. Most are domain specific, some are new internally generated general purpose languages in "black box" use in client software because we saw the need, some are from clients which needed languages built. Mostly we value declarative specification, however some domains do require in-order recipe style expressivity. The more problem-space the language can be, the easier it is to iterate, catch problems early & easily, report more meaningful errors, and optimize the compilation. It's a craft, but I honestly think it's not a hard one to pick up. The major thing is being able to step back and think about the problem humans are tackling, not grabbing your default C style (or whatever) and trying to bolt it into some solution space. As programmers, it's easy to give zero thought to all the boilerplate and machine-fiddling required for typical programming; you must set that aside when starting from scratch with a new problem. You must also realize when existing or in-progress solutions become boilerplaty and fiddly, and have the wherewithal to step back and notice that it's not expressing the correct level of abstraction for the problem. We've supported Bloomberg, ADP, nuclear power plants & other utilities, etc, so we need something truly viable, robust, maintainable, and worth the client's money. You have to think in their shoes, understanding the industry vocabulary of the user. You need to give them tools that closely match their natural expression of what they want the machine to do, not divert them into being programmers, yet still have all the power they need for their tasks at hand. It all starts with having a great business analyst.