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.
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
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
* 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
- 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.
Sat Nov 28 17:42:14 GMT 1998