Readers in the UK will be familiar with Alan Titchmarsh, a TV celebrity gardener whose shtick is to perform makeovers on unsuspecting victims' gardens while they are lured away from home by some suitable subterfuge. In the space of a couple of days, Alan's team transforms a wilderness into a show garden, constantly up against impossible deadlines and unexpected difficulties. When the victim returns, he/she is always delighted with the result (or at least pretends to be). It all makes great TV.
The thing is, though; if the owner had been a keen gardener it would never have been a wilderness in the first place. And if they had wanted a show garden and could afford a gardener they would surely have done so. So the question is: Who is going to look after this garden?
It is comparatively rare for the programme to revisit these gardens years later, but I fear that if they were to do so, in the majority of cases we would find them rapidly reverting to their original state.
I hope the parallel with software is obvious. Websites have long lives so when we build one it is for the long-term. Before we start we should consider who is going to maintain it. The golden rule is
"If you can't maintain it, don't build it."
As with TV garden makeovers, interactive websites are often built by very highly skilled teams. A small proportion of site owners have an in-house team that holds onto its expertise over a long period, but far more often maintenance will be entrusted to people who are untrained in the details of the software and the framework used. And in many cases there is no maintenance team at all; just the owner of the site, who will have to call in a team each time maintenance is needed.
After a couple of years, the maintainer will almost certainly not be the original developer(s). Whoever takes over, it takes a surprising amount of time to get to grips with a complex website and the temptation to cut corners is strong. Too often there is a steady degradation of the code and a rising cost of maintenance, until it is deemed beyond repair and a complete rewrite is needed.
The problem is made worse when frameworks are used. These have a short life compared to that of a major website and are constantly under threat from newer, more fashionable models. Even the same framework can undergo serious changes between versions (cf Zend and Angular) that require a complete mental reorientation on the part of the programmer asked to pick up an old version.
These problems should be anticipated at the outset and factored into the TCO (Total Cost of Ownership), but little thought is usually given to the maintenance of what is being built.
English-like DSLs are not hard to write. To start with you need to devise an unambiguous syntax that remains close enough to English to be understood by any intelligent person having a good knowledge of the domain. Lack of ambiguity is the first prerequisite for a computer language so here we have the meeting ground.
The effect of this strategy is to divide the programming effort into system programming, where any available technology will be fine because once built it will rarely be changed significantly, and user-level coding, done with a DSL whose vocabulary matches that of the domain. When the framework (if used) goes out of style it no longer matters because in a carefully designed system all changes will occur at the user level. So the product has a far more assured life-span, and because it is no longer dependent on high-level skills, mistakes are fewer and the cost of maintenance is lower.