Polyglot programming may also come into the picture when the application's code can be separated into business code and technology code. The business code contains the top-level business logic that we actually write the application for, and this is the code that contains the logic that the customer pays for. The technology code is to support the algorithms coded in the business DSL.

Most of the enterprise applications contain these two types of code but many do not separate them. This leads to a monolithic application that contains repetitive code. When you feel that you are writing the same type of code when you need persistence or networking, and again the same type of code while coding some business rules, then this is the code smell that suggests that the two code types are not separated. DSL and scripting are not a magic wand and do not solve all the problems that stem from a wrong application structure. In such a situation, the code has to be refactored first to separate the business logic and the infrastructure code, and it is only the second step to implement a DSL and a business API supporting it and to rewrite the business code into the DSL. Every step of such a project delivers value for the application and even if it never gets to DSL and scripting, the effort invested is not wasted.

The business DSL scripting is very similar to pluggable scripts, except that this time it is not the application that calls the scripts from time to time to execute some special extension functionality. Instead, the DSL code calls the application through the business API that it provides. The advantage of providing the API and using a DSL is that the code that implements the business logic gets rid of the technical details, can be very abstract, and, this way, be much closer to a business-level description of the problem rather than just program code. Even some businessperson can understand a business DSL, and though it is not a goal in real-life examples, they could even write code.