Control Table - Advantages

Advantages

• clarity - Information tables are ubiquitous and mostly inherently understood even by the general public (especially fault diagnostic tables in product guides)
• portability - can be designed to be 100% language independent (and platform independent - except for the interpreter)
• flexibility - ability to execute either primitives or subroutines transparently and be custom designed to suit the problem
• compactness - table usually shows condition/action pairing side-by-side (without the usual platform/language implementation dependencies), often also resulting in
  • binary file - reduced in size through less duplication of instructions
  • source file - reduced in size through elimination of multiple conditional statements
  • improved program load (or download) speeds
• maintainability - tables often reduce the number of source lines needed to be maintained v. multiple compares
• locality of reference - compact tables structures result in tables remaining in cache
• code re-use - the "interpreter" is usually reusable. Frequently it can be easily adapted to new programming tasks using precisely the same technique and can grow 'organically' becoming, in effect, a standard library of tried and tested subroutines, controlled by the table definitions.
• efficiency - systemwide optimization possible. Any performance improvement to the interpreter usually improves all applications using it (see examples in 'CT1' above).
• extensible - new 'instructions' can be added - simply by extending the interpreter
• interpreter can be written like an application program

Optionally:-

• the interpreter can be introspective and "self optimize" using runtime metrics collected within the table itself (see CT3 and CT4 - with entries that could be periodically sorted by descending count). The interpreter can also optionally choose the most efficient lookup technique dynamically from metrics gathered at run-time (e.g. size of array, range of values, sorted or unsorted)
• dynamic dispatch - common functions can be pre-loaded and less common functions fetched only on first encounter to reduce memory usage. In-table memoization can be employed to achieve this.
• The interpreter can have debugging, trace and monitor features built-in - that can then be switched on or off at will according to test or 'live' mode
• control tables can be built 'on-the-fly' (according to some user input or from parameters) and then executed by the interpreter (without building code literally).