Sufficiently Flexible Apps Resemble Interpreters

As I have tried to build and study change-friendly apps over the years, I have observed that apps that gain a fairly high degree of flexibility start to resemble domain-specific interpreters (DSI). Power-users and rookie programmers (or HTML/CSS coders) then enter and manage rules in "rule tables" or something similar to a BusinessRulesMetabase.

This has been reaffirmed lately as I have been evaluating web content management systems and techniques. In the more flexible CMS designs; controlling what, where, and when content is displayed almost becomes like an interpreter that processes lists and groupings of rules. It has tons of conditionals and "membership" rules. Only loops are limited or tightly controlled, being the only thing that keeps it from being TuringComplete (and perhaps is if a power-user hacks around enough to trigger loops).

Now it could be there are other ways make apps flexible such that DSI's are not the only game, but I have yet to see them.

Also note that this is mostly a different issue from GreencoddsTenthRuleOfProgramming. Greencodd's is mostly about how to manage tons of data and meta data, not whether to use meta-data or table-ized rules. It may be feasible to manage a BusinessRulesMetabase via EssExpressions, for example. But the selection of relational versus EssExpressions to represent the meta-base is a different topic.

--top

Some commercial apps like MS-Word and AutoCadd? come with a built-in scripting language to automate many aspects of them. However, this tends to differ from the above in that the "programming language" is domain-specific and tends to not be a textual language in Word and AutoCadd?, but rather via forms, tabular lists, and/or GUI-based "rule" wizards.

"... Tends to not be a textual language"? Microsoft Word comes with a full implementation of VisualBasic. It is a general-purpose textual language with Word-specific libraries available by default. AutoCAD (other than AutoCAD LT) comes with AutoLISP, which is certainly domain-specific but is also a textual language. Almost any significantly-recognised "power user"-oriented end-user application contains a built-in textual programming language.

The "rules tables" you describe above are obviously a poor cousin to full-blown programming languages. They sometimes appear in crude CMS systems and the like, perhaps as a conceptual precursor to highly-customisable, fully-programmable content management frameworks like Drupal.

I reworded the original to hopefully make it clearer. As far as "precursor", I agree a "full-blown" textual programming language (plus textual query languages) is the most powerful in general (although TableOrientedProgramming can simplify some programming). However, there often needs to be a middle-level "power user" to manage the more routine domain "programming". Sure, it's great job security and demand-increasing for us formal developers to serve that level, but it's often not realistic in a larger and/or geographically distributed organization from a business perspective. Do you disagree with the need for such a middle layer? It's not a good use of our time to micromanage the layout of most Drupal pages, for example. Power users are perfectly capable of setting up basic conditionals etc. via "guided" rule screens/lists/wizards. See CompilingVersusMetaDataAid for more about the middle layer.