Naturally the implemented solution to an industrial problem must be
delivered into the industrial computing environment.
It is sometimes argued that this is only possible if the solution is
implemented in a mainstream programming language such as C,
C++ or even Java.
There are two arguments supporting this view, firstly that of
embeddability (it is easier and more efficient to pass data and
control between modules written in the same programming language), and
secondly that of system support (mainstream language programmers are
much easier to find and replace than specialist programmers).
Whilst this argument only supports a mainstream programming language being used for implementation, and not conceptual modelling, it has consequence for the modelling language as well on the assumption, which we discussed above, that the conceptual model should be close to the design model. Thus if the design model is encoded in a mainstream programming language, then either the conceptual model must be compromised becoming more like a design model, or the gap between the conceptual model and design model grows very wide.
Sadly the attempt to tackle combinatorial problems with mainstream programming languages has too often foundered because the implemented solution has proved not to solve the actual industrial requirement (often because requirements change during application development). The solution cannot then be modified to meet the actual, or new, requirements within a reasonable cost and timescale.
Given that the core combinatorial optimisation problem is best solved by a specialised programming platform (either mathematical or constraint-based), the problem of embedding has to be solved.
One approach is to embed constraint solving in a mainstream programming language. As we shall see in section 5 below, search and constraint handling are closely interdependent. Even if the search is encoded in a mainstream programming language, the programmer is required to understand in detail not only the data structures used by the constraint handlers, but their operational behaviour.
In practice packages providing an embedding of constraints in mainstream programming languages also encapsulate search within the package. The application developer is required to control the search. To avoid any mismatch between the host programming language and search control within the package, a popular approach is to implement the package as a library of the host programming language.
The result is that the separation of conceptual modelling and design modelling is given up, in favour of staying within the confines of the expressive capabilities of the host programming language. This approach not only requires specialist programmers to develop and support the application, but it also sacrifices the modelling advantages of mathematical and constraint logic programming.
In fact the problem of embedding has been overcome, though first
generation constraint logic programming languages were deficient in
this area.
ECLiPSe is fully embeddable in C and C++, and indeed uses
an external solver, written in C to handle linear constraints,
since the runtime cost of such an interface is perfectly acceptable
even for a tightly integrated component such as a constraint handler!