Looking at existing systems in CAD areas, it seems obvious that an interpreter is the classical solution for the task level environment ([2] [7] [12] [14] [23] [36] [82], and to some extent [27]) Both single interactive actions and more complex flow control can be executed in an interpreted environment.
A conceivable, more modern alternative is an entirely object-oriented concept where both CAD data and simulation tools are objects (as in [50]) and the task flow to be performed is deduced from their properties and relationships and by methods and rule inference from a design goal or inquiry. At a closer look, however, the two concepts are not mutually exclusive. In fact, the use of an interpreter is merely an implementation-oriented early architectural choice which does not at all preclude the latter introduction of object-oriented concepts.
Especially for Technology CAD, the immediately available programming language features offered by an interpreter are of great value for defining task level macros and arbitrarily complex control flows which involve the execution of several applications, without the need to construct complex object systems before any practical problems can be solved.