Probably the biggest problem with the MUMPS language is the ELSE
statement.
The ELSE statement, as it is implemented in MUMPS is not a true
ELSE as
defined in modern, structured languages. Instead, ELSE could be best be
described as MAYBE. ELSE in MUMPS is not always associated with
IF.
In the transformed code, an ELSE statement is cause for manual
intervention
when it follows an IF. When ELSE does not follow an IF
expression, an error
is generated. I manually examine and repair these cases and insert warnings
to identify the code that I modified.
GOTO is a problem in any language. In modern languages it is not quite as much of a problem as it is in MUMPS, since the scope of a GOTO in C or C++ is bounded by a function or method. In MUMPS, GOTO has no bounds. The GOTO is the biggest cause of speghetti MUMPS code. Since a boundless GOTO statement is not allowed in structured languages, the transformed code simulates a GOTO, and marks it with a manual intervention error.
Even more dangerous than the GOTO, the (e)XECUTE statement allows a clever programmer to hide his/her code by concatinating strings of code together and executing the concatinated string. This gives rise to pachinko MUMPS code.
Unlike structured programming languages that enforce a one entrance one exit convention, MUMPS allows and even encourages multiple entrances and multiple exits.
Any label in MUMPS may be reached in many ways. A label may be reached sequentially, by an extrinsic function call, by a DO, by a GOTO, by an XECUTE, or it can be manipulated as data using $TEXT.
There are several ways to exit a block of code in MUMPS. If execution reaches the end of a routine, then control will return to the routine that executed the last DO, or extrinsic function call. A QUIT statement may be used to exit from a loop (much like a break in 'C'), or it may be used to return to a calling routine (similar to a return in 'C'). The QUIT statement will behave differently depending on where it is used.
The real problems are the ways in which the MUMPS constructs are used. If pachinko and speghetti code were avoided, then MUMPS would be just as testable and maintainable as any other language. Unfortunately, many of the MUMPS systems in existance today were implemented before we started to bring programming out of the dark ages.
I don't believe that programming will ever be a science, but at least it has transitioned from a black art to a visible art that can be examined. I know MUMPS programmers who are trying to turn MUMPS programming into a visible art. By a visible art I am speaking of an art such as mathmatics that is open to examination.
MUMPS code is easy to write, but difficult to read. At best, code written in MUMPS is cryptic. It does not have to be garbled, I have come across some code that is very easy to follow and understand, but for most code, I need my analysis tools to follow the code. Most MUMPS programmers that do maintenance programming do not bother to try to fix the code, but will simply rewrite the code, since "it is easier to re-write MUMPS than it is to fix it".
Any time code is written, there is a potential for the introduction of a bug. Re-writing a block of code may fix one problem, only to introduce new problems. Code also has an intended purpose, without having access to the design or requirements, the purpose is not known.