Some software has two "levels" execution. A primary level, which is developed by the vendor, and secondary level which may be provided by the users to perform relatively complicated custom logic -- logic beyond that would be reasonable for simple configuration or a UI.<p>Is there a name for this?<p>Consider a software system that "delegates" execution points to some other language or runtime entirely. These are systems that have some level of "scripting."<p>For example, say I have a web application written in .NET which has a workflow engine. This engine can be configured, and might even have a UI to drag boxes and arrows around.<p>However, at the end of a workflow step, I also allow the option for my users to provide some JavaScript that is executed server-side that produces the next workflow recipient. It can execute whatever logic it wants -- all the engine cares about is the result it returns.<p>So, the PRIMARY execution engine delegates control to a SECONDARY execution engine, then incorporates the result that comes back into further execution.<p>I intuitively know about this architecture model, and I've used models like it many times, but I'd like to know if there's an accepted, general name for this model.<p>(Note: I am fully aware that I may have answered by own question in the title. If so, let me know.)
I work for a company that provides a custom software platform that enables the building of large, complex enterprise apps. The primary engine is written in Java running in a JVM but we also use Groovy as a secondary scripting language in a secondary execution context for extending the platform and writing complex business rules. In fact the JVM has fantastic capabilities to allow late, runtime compilation using JVM-compatible languages (groovy, scala).
We have historically called this 'configuration' to give our clients the impression that the software is easier to deliver an application with and our consultants were 'configuration developers'.
But more recently we noticed that clients don't care so much about this wording. On the other hand, the developers using the platform don't like to be called 'configurators' and so we've gone back to call it development (which it really is) and have 'developers'.
“Macros” - specifically the application kind: <a href="https://en.wikipedia.org/wiki/Macro_(computer_science)#Application_macros_and_scripting" rel="nofollow">https://en.wikipedia.org/wiki/Macro_(computer_science)#Appli...</a><p>Or “pluggable”: <a href="https://en.wikipedia.org/wiki/Plug-in_(computing)#Mechanism" rel="nofollow">https://en.wikipedia.org/wiki/Plug-in_(computing)#Mechanism</a><p>Both make the application’s internal functionality available to be called from scripting languages, and in that context they can look similar, but one difference is that plug-ins are distributed with the application or separately by its author or produced by 3rd parties, while macros are custom written by users.
You're describing a VM with multiple languages. You might like the Racket programming language(s). It provides a powerful macro interface that can define new languages, and sandboxed execution to safely execute user code server side.<p><a href="https://racket-lang.org/" rel="nofollow">https://racket-lang.org/</a>
The provided definition is a general high level abstraction/view.<p>"scripting"/"scriptable" short answer: way to modify/direct things at the software level without knowing all the underlying details; no need to translate "script" into different code (aka binary/bytecode). aka software provided way to "customize"<p>the "google searchable" other name? developement/runtime environment; Levels of abstractions (aka one level provides the constructs another level just uses the constructs provided per commands/instructions)
aka os; user using os; stand alone application (command line display date/time); integrated application (database vs. os)<p>all have environment variables, initializations, termination clean-up, and "acutal work" stuff that need to be done to setup the defined constructs that a given abstraction layer expects/requires.<p>The difference is what by default does the associated actions/where &
how the information is provided.<p>(command line interpreted shell vs. OO as a take on transactional glue/framework provided by a command line interpeted shell)<p>Defining an Itegrated development environment helps with this.<p>Environment/intended usage would help to define "scripting" areas:<p>* historically, automation ("job control")<p>* stringing series of small programs together to conserve resources aka memory<p>* rapid prototyping<p>* portability<p>some "scripting" areas:<p>a) command line vs. gui;<p><pre><code> although vm stuff such as java & eclipse kinda blur the "xwindows widgets callable from shell script
</code></pre>
b) presentaton (web-glue for multiple sources, printer aka postscript / pdf / etc)<p>c) OS level vs. application<p><pre><code> at os level the "linker" is the shell.
at os level that user used, "command line shell"
(automatethe setup of a vm instance when a user logs in)
at os application level, a database has "report/form scripts"
</code></pre>
d) (glue between different domaines)<p><pre><code> Script that pulls in names/addresses from database to fill in a
word processor form to print out each name/address on an envelope</code></pre>
Platform or Platform as a Service? Scriptable implies code, but platforms can be extended via config, no code UIs, code, or something else. It’s very popular in enterprise software where a base product can be sold but extended by customers to match their specific business processes. Salesforce is a prime example of this.
I just call it "configurable software".
Doing the setup is formally called 'configuration' in SAP, and the implementors document the changes done in a 'configuration guide'.<p>I personlly would also like simpler names for the two other kinds of software: Custom-Of-The-Shelf, and, Bespoke.