The way it would be used is that programmers writes some interface in their language, and then that interface becomes a compiler that can verify and compile a business logic script file. The script would run in a sandboxed environment with resource restrictions so it can't run too long or crash the server.
Such a language wouldn't just help people write code files for apps, but could also enable just having a textbox field where you could add programs to filter or sort results to your liking etc. I guess you could view it in the same way as the popular regular expression language that is embedded in so many apps and programs, but with enough power that it would cover most business logic needs.
Since it was designed from the start to be sandboxed like this it wont be hard to make it safe, and as it gets wider appeal more people would get interested in programming. That is the theory at least, is anyone aware of attempts to do this? The requirement that it can't depend on external code is absolutely necessary though, that is the main advantage of regular expressions and why you can easily embed those in API's.
To make this work well, you must put serious effort into creating a database schema (design) that meets the criteria for normalisation - up to third normal form. Do this even if you later decide to de-normalise.
Some developers are against the idea of placing business logic in a database. But I'd argue that business logic in your database minimises the code in the supporting programming codebase.
Of course, business logic can't always be clearly separated by database and code, but favour the database over the programming code for business logic when possible.
and Drools: https://www.drools.org
There are papers describing using OWL for biz rules, too: https://link.springer.com/chapter/10.1007%2F978-3-642-32689-....
One of the biggest problems (IMHO) in this space (which I've worked in CLIPS-based systems http://clipsrules.sourceforge.net) is that business rules are often not as "logical" as they seem and can cause real problems for novices without formal logic training. Sometimes the business rules aren't even "rules" as such, which makes it really hard to both create and explain.
What I have found with this approach is that sometimes it can be difficult to draw a clear line between business logic code and infrastructure code.
Traversing through a list of customers to make a report… do you call a dedicated function or do it on the scripting language? If you need a slightly different report format (including address + phone number) do you write a new function on the host lang or implement it as business logic?
I believe it used to be called ILOG. I’ve never used it.
Now, on a more serious note. Codebases are too big and complex precisely because business rules are a mess. Disabling composition, modularity won't help you in the slightest.
Also you're describing the architectural drivers that give rise to plugin systems or device drivers in OSes.
As a counterpoint check out the inner-platform anti-pattern.