Configuration is not the only application of polyglot programming. Configuration is executed at the program startup and the configuration data is used as static data afterwards. We can execute scripts during the application's execution any time and not only during its startup. This can be used to provide extra functionality to the program's user with installations that use the same application but are furnished with different scripts.

To get this kind of flexibility, applications, many times, provide plugin APIs, which a developer can use to extend the application. This, however, requires that the developer sets up coding tools, including IDE, build tool, continuous integration, and so on, that is, a professional programming environment. When the task to be solved by the plugin is simple, the overhead is simply too large. In such a case, a scripting solution is handier.

Scripting is not a solution for everything. When the scripts extending the application tend to become too complex, it means that the scripting possibility is just too much. It is difficult, however, to take back a toy from a child. If users get used to the scripting possibility, then they will not take it easy if the next version of the application we release does not provide that possibility. Thus, it is extremely important to assess the possible use of the scripting capability in our application. Scripting and, more generally, any feature of our program will not be used for what we intended them for. They will be used for whatever it is possible to use them for. Users can go beyond all imagination when it comes to abusing some feature. It may be a good idea to think about limiting the scripting possibility beforehand, limiting the running time of the scripts or the size of the script our program agrees to work with. If these limitations are set reasonably, and the users understand and accept these, a plugin structure in addition to the scripting capability has to be considered.

The security of an application, including plugin or scripting extension, is also very important. The scripts or plugins run on the same JVM as the core application. Some scripting languages provide some fence around the scripts that limits the access to the core application's objects and classes, but this is an exception. Usually, scripts run with the same privilege as the core application and that way they can do just anything. Thus, scripts should be trusted the same way as the core application. Script installation or modification should never be possible for an unprivileged user of the application. Such an action is almost always reserved for the system administrator.

If an unprivileged user can upload a script to the server and then have it executed, we just opened a security hole in our application. Since access restrictions are enforced by the application, it is easy to override these limitations using an uncontrolled script. The hacker can just access other users' data easily, which he is not entitled to, and read and modify our database.