Error reduction

There are several reasons why MM reduces errors during programming.

• Variables are referred to by name rather than by cell position. This means that positioning errors --- referencing a wrong cell in a formula, or putting a formula in a wrong cell --- are replaced by naming errors, e.g. typing income instead of profit. It seems reasonable that the latter will be less likely in the first place, and easier to spot once made (names have more inherent meaning than cell numbers). In particular, motor slips --- accidentally moving the cursor or mouse to the wrong cell --- will be eliminated.

• MM's type-checking also helps. Attributes are strongly-typed: each attribute must be declared and given a type, such as real, integer, or string. Whenever the MM compiler encounters an attribute name in an equation, it checks that the attribute has been declared and is of the correct type for the operation being performed on it: e.g. that the equation is not trying to add a number to a string, or put the sin of a number into an integer. This helps the compiler catch references to undeclared attributes, and similar errors, before the program is run.

  Errors could be reduced further by using dimensional analysis. For example, money and interest rate are both real numbers. However, if MM permitted the programmer to declare one as of type money and the other as type interest_rate, then the compiler could be equipped with the rules of dimensional analysis, enabling it to detect an attempt to add one to the other (it is a general rule in dimensional analysis that one does not add quantities that have different base units). In a similar way, the compiler could be given a rule that one does not multiply monetary units together, enabling it to catch the accidental use of * instead of +.

• MM and normal spreadsheets both allow the user to make errors in formulae, e.g. typing a plus instead of a minus, or transcribing a number incorrectly. However, it seems likely that because the formulae in an MM program are more easily visible than those in the spreadsheet, they are easier to check --- they're just there in front of you, and you need not do anything to make them appear. They're also easier to read, because they use names in place of cell references.

• The ability to refer to attributes by name would also eliminate some range errors, such as the one reported by [Ditlea 1987] where a company used @sum to sum a range, and forgot to update the range when adding a new item.

• The MM compiler could check for attributes that are defined but never used, and (conversely) references to attributes that are declared but never updated,, and warn the user about them.

• Errors will also be reduced because inheritance makes code reuse easier and because MM programs are more easily documented.