I've had the misfortune of working on "enterprise" software where avoidance of "hard-coding" went so far that the core system did almost nothing other than exist as a way to plug in mutable functionality. All in the name of not having to re-build, or to re-deploy, and being able to tell the customer that no code changes would be required, even though the "configuration" was practically code, and required many of the things that code might require, like qualified configuration developers, test suites, and detailed deployment plans. Truly madness. In the era of software as a service via internet, software is more "soft" than it has ever been. You can change it and deploy it to production any time you please.

I know one application that went full cycle from the get go: Emacs.

I made almost two full trips around this clock over the last decade on a single project.

One of the biggest takeaways for me is that if you choose to do the DSL, you need to think super hard about your target audience and how they think about the world.

For me, the whole point of DSL is to get the developers working on common modules that the business could string together without too much babysitting.

The first DSL we tried was python, interpreted by way of iron python / C#. This did not stick with the business people at all. It was pure ball-and-chain for the development team.

The second DSL we tried is SQL. The verdict is still out on that one, but the amount of traction so far is almost infinite in comparison to the prior attempts. You can get a non-developer to build SQL queries that express BL if you are patient with them and provide some examples. The tooling is also substantially better if you are using something like SQLite and can easily pass the DB around to play with.

If I was going to approach this fresh, I'd set the clock to noon and then remove the battery. The amount of overhead and risk required to support a DSL is substantial. Even if you use SQL and leverage mostly existing tools, you are forcing developers to build things in a very particular way that isn't necessarily ideal in terms of a pure code solution.

I think you can do a purely hard coded solution that is approachable by the business if it is structured well enough and made available in a friendly context like GitHub. Let the business use the web tool to propose PRs over well documented code they can mostly understand. Maybe there's an "internal" folder that only the neckbeards touch. You can draw your battle lines wherever you please.

For the hardcoded only approach wherein the business people are involved, the choice of language is very important, but I don't know how to have that conversation constructively in this forum.

[dead]